Remember with this kind of thing you're trusting the remote site with access to your terminal emulator. There have been various security problems with some more advanced terminals and escape sequences in the past[1][2].
Personally I think it's a cute thing and have implemented some similar little easter eggs to this via: curl ip.wtf/moo
This is true of anything that ever renders to your terminal. I'm not sure this class of issue is worth worrying about, generally. Sure, these are neat and scary examples. Have you seen some of the recent GPU driver ACEs? Better not render any graphics!
A generalization of this is "receiving information from third parties can lead to security issues" which is of course true. Untrusted inputs are always untrusted.
Piping curl into bash is one thing, but this is on the level of "are you sure you want to open this file downloaded off the internet?" prompts of yore -- it's not productive.
Completely agree, but also I remember that 'piping curl into bash' was always one of the biggest no-no's. I held onto this for so long, but then realized every time I run 'npm i' arbitrary commands can also run, and now it seems wild that I ever cared about curl | bash on websites that I trust
Coming from a Windows world, I've never worried about the `curl | bash` thing. If I would trust an opaque Windows executable from a site, why would I not trust an equally opaque `curl | bash`?
I've even seen people concerned about installing Homebrew that way. It is probably one of the most confusing concerns regarding `curl | bash` given that the it's a package manager designed to run arbitrary Ruby code and is often pulling down precompiled applications.
Windows executables can be signed, and Homebrew formulae are theoretically reviewed and check a hash when they download binaries. With curl | bash, maybe the download fails partway through, or a hacker has replaced the executable on the server or the URL in the copy/paste instructions with a homograph spoof, or the site serves malware when it detects a curl agent.
Part of the reason is that your connection could be interrupted … and then now what? Hope you like sifting through the script’s entirety and manually checking how much it’s done so far.
No, that's exactly how it works. Why would you write such a thing when you're clearly just guessing?
A shell script is interpreted one line at the time.
Very simple proof:
$ while true; do printf 'date\n' && sleep 5; done | sh
Mon 16 May 2022 07:19:21 AM CEST
Mon 16 May 2022 07:19:26 AM CEST
Mon 16 May 2022 07:19:31 AM CEST
In either case, if the network connection is interrupted, the download is finished. How would sh know it's not the whole script as the author intended it? Remember that in a pipeline the receiving end only sees the pipe, and won't know about the exit status of the process upstream (which may for all we know be zero anyway).
Unironically a good idea. Graphics have always been a mistake - most engineers would agree that if we stuck with very basic output, our software would be in a much better place than today (and more usable, too!)
once you become an engineer you cant unsee it very easily, your user vision is now tainted by a higher understanding of problems, rather than feeling frustrated at {FOO = FAIL} bugs and submitting a complaint comment.
It may be worth evaluating why we need to explore this space through computing in the first place? Pen and paper have never failed us before, nor has actually traveling to the space in question.
generally speaking, computers are faster at performing calculations than humans. this can be beneficial for humans, as if they are able to convert a problem (for example, mapping the densities of functions over a 2D space) into a purely mathematical one, humans are able to save significant time and effort.
i both agree and disagree with this. on one hand, it’s true that having everything run in CLI mode would probably make programs truly cross platform. for example, recently I had to use namebenchmark to find the best DNS for my needs. on the M1 mac, the program cannot be run since it’s 32 bit. but i managed to simply run it in a terminal instead by calling its python script (used version 2.7). now i get to run this app on any platform since python is also cross platform. but the GUI version would not be easily ported to linux, windows, etc.
on the other hand, most users are not like me. they want something they can interact with using a mouse, and they often use keyboard only to enter words, not commands or shortcuts. so GUI has definitely a place in today’s world.
Curl isn't the problem they're describing. The remote can assume you're running it in a terminal (especially since the user agent string indicates you're using curl) and can send malicious escape sequences in the body, which will be interpreted by your terminal emulator in most cases.
This is true of any program that prints output directly from a remote host / untrusted source.
In the event your terminal emulator has a vulnerability or allows you to run arbitrary commands (this is a feature of some emulators), the site can target that functionality for users of that emulator and wreak havoc.
I maintain a lot of ANSI escape related code. These exploits have always been theorized, but I've not once heard about this being exploited in the wild. It's certainly possible. Not very probable. Refer to your threat model, as always.
is there way to “sanitize” the curl output such that escaping is disabled?
another commenter mentioned the threats of graphics, but this seems more concerning, esp. in an elevated shell. maybe pipe curl to a text file and inspect before running?
Don't use a terminal emulator, or yes redirect to a file. But that means you'll need to know what the escapes do, and they look cryptic to the layperson. Also, inspect with an editor that replaces non-printing with some other character (like vim, unlike cat) otherwise it's just as bad as letting curl output.
And even then, this is probably not a threat you need to worry about.
No it isn't, or it's at least not the problematic part. curl is just the messenger, and on outputting things to a terminal you can use escape codes, and other things, to do some funky stuff like changing colors or making text blink.
If the terminal has a bug w.r.t. something it processes one could leverage that, but they'd probably need to know which terminal and maybe even which shell you're using; so maybe don't let curl/wget but also `cat` of a downloaded file output directly to the terminal if it isn't a trusted origin or if it looks/feels shady.
To be fair, `sudo curl | sh` is completely different than `sudo curl`.
In one command you pipe the output to `sh` which will run whatever instruction it receives. In another command you just ask for an output from `curl`, doing so should not cause any side effect than the output action itself.
The terminal (or rather terminal emulation) is a mistake, people should stop glorifying it. It has no inherent value, beyond being able to run historical software that was bound to a terminal. Most of all one should stop confusing the terminal and the shell, which remains an interesting concept.
Hard disagree, it has a lot of value and there's a reason it still exists and lots of tooling is still developed for running in terminals and shells, sometimes as exclusive target.
Problems with untrusted, unknown input from any source affects *all* software that process it, internet browsers, document editors, archive extractors, even just opening a file can do lots of funky stuff depending on the file system.
Yes, and I use terminal emulators too, but I look at it the same way I look at browsers. Sure, there is a lot of useful stuff being made with heavy Javascript dependencies, weird Web frameworks, etc., but this doesn't mean that the technology is good in itself.
a terminal is the bare minimum you get when installing an OS (think Arch). is what gives you the power and speed to shape your workflow exactly the way you want it. running shell inside Emacs is not a bad idea, but you don’t get emacs when you install a new OS. you get a terminal that then lets you install emacs. at that point, you might as will just use the terminal.
I don't get what that has to do with my point. Arch leans into terminal enthusiasm, so it is natural that by default all they offer is a tty to install the distribution. But as most other distributions prove, this is not necessary.
Acme and Emacs give good examples of how a non-terminal shell session can look like. They also make clear how a good CLI application should behave like.
which begs the quotation: is there such a thing as a “firewall” for terminals?
my idea is to limit the terminal’s cpu usage so that any breach does not spread quickly in the system, and maybe limit the terminal’s network access, but leave the shell out of it. idk if the last part is possible.
And to be clear, your question is a good one. It's just that it's raised and not begged. That said, I see and hear this all the time, including by historians of philosophy who are strongly familiar with logical fallacies and their distinctions.
Begging the question isn't usually used like this these days, even if it did originate thus. The English language is used the way English speakers use it; yes, even that is quite circular, because there is no formal academy setting down rules that everyone agrees on. Institutions only teach stylistic choices. We use beg the question in exactly the way you say we shouldn't far more often than not to the point that its history is merely a bit of trivia, at least to most American English speakers; Oxford has yet to catch up, but I can't imagine the English situation is that much different than the American one.
I think that is probably excessive, a terminal is hardly as complex as a web browser.
screen or tmux (or even mosh) can essentially act as a terminal firewall, as they interpret escape sequences and maintain a virtual “screen”. Then you can sandbox their process in docker or similar.
Or if you want web browser style sandboxing maybe just using Xterm.js could work.
It's just cool but practically I never check weather until I'm about to leave home and then I'll just check a local weather app on my phone which should give more accurate and detailed info than a service that covers the entire world with presumably varying degree of accuracy.
but imagine if you're in a bunker hacking on your fav project, no artificial light and you wonder.. shall i go to the surface? you curl this website and, if tolerable weather conditions, you plan your ascent.
Than you need a webcam out there, with a thermometer in the field of view.
I live in a big city, it could be raining frogs in one part and a happy sunny day in the other and the best thing any weather report could say to me is 'expect rain'. And if I need to go it doesn't even matter what the report says or if I have/have not an umbrella with me.
Honestly for the last decade even if I look at the weather report I look not for the current conditions (I have eyes and windows) but what would be in a couple of hours, because temperature difference between 9PM and 3AM could be pretty significant.. and it doesn't even matter in winter and summer. *shrug_emoji*
> I live in a big city, it could be raining frogs in one part and a happy sunny day in the other and the best thing any weather report could say to me is 'expect rain'.
Just in case you haven't seen it: some services provide conditions and forecasts for particular locations with better resolution than ‘the city’, and can show the projected movement of rainclouds.
(You'll have to research the services for your country yourself, as I doubt it that my local one is useful for outsiders. But I'd guess that these days many big web services have these features.)
Well, I have such service, though it's a map with the current rainfall data.
Still, after I wrote the previous comment the rain has come. And in 15 minutes there was no rain and the sun shone brightly and in another 30 minutes even puddles all dried up. So the practical usability of such service is quite limited.
I occasionally amuse myself by gawking at the formations of rainclouds in my vicinity, which included stuff from thunderclouds thousands of kilometers across, to jagged clouds bringing alternate rain and sunshine, to again a massive cloud covering this whole region except a circle right around my house. So I definitely can recommend finding such a service with cloud movement and with projection of it into the future—if only for the curiosity value.
The one I use is https://yandex.ru/pogoda/maps/nowcast — but I'm not sure if it works in English, and these days perhaps one will prefer not to use Yandex anyway.
I have to scroll all they way down to the buttom to find the information source -- WorldWeatherOnline. Does people not care about where their whether data is sourced from?
Living in Japan, I have always been wary of these type of service, since I find a lot of them really inaccurate. And I just checked, Tokyo show 15C on that website, while high resolution current weather information from Japan Metrological Agency show 18C.
I'll admit I'm just speculating because I don't know much about weather and weather data collection, but is it not possible there's a 3 degree difference between 2 different places of measurement in Tokyo (i.e. both are correct to some degree?)
> while high resolution current weather information from Japan Metrological Agency
They are complaining about location precision. It might be very coarse (equivalent to US zip code size). It’s a valid complaint. I use Dark Sky on iOS because it’s accurate to 10 meters or so.
I agree. I always avoid these aggregators that offer world-wide coverage. The quality of the data is often questionable.
As a cyclist I'm mostly interested in rain. So I check the rain radar of the national weather service, which has excellent resolution.
Even when travelling I spend 5 minutes to dig out the relevant local pages of a national weather service and bookmark them. Not something I have to do so frequently that any kind of automation would be needed.
Weather apps and this client are a solutions in search of a real problem. Yes, it's a nice demo, I like working with the terminal. But I am not working with weather all day long.
This is why I like Windy.com. They give you the output directly from the various weather models and you can actually see them all in parallel or just pick whichever one works best for your location.
Living in the PNW where predicting snowfall can be problematic to say the least, I love looking at the various windy.com models. One particular storm, that lead to about an inch of sticking snow this past winter had ranges from 2-20 inches predicted by the various models. The worst part is the 2 inch prediction came from the model that is generally considered the least reliable for our area.
rate.sx is very good. much better than all of the desktop client trackers out there and the web ones with too much granularity. sometimes i don't want to see the candles i just want to see the price of a particular coin
This is a really nice service and I have used it for quite some time. Just a small reminder; to relieve the wttr servers, please cache the results on disk if you for example want to have a higher refresh rate on your tmux status bar.
See my dotfiles repo [1] if you're interested in such implementation
I'm going to add that if you live in Norway, YR has nice weather data available for free (required by law). Shameless plug for my little CLI tool when I was beginning to learn go:
A very fun way to have this, tmux status bar weather! `set -g status-left '#(curl "wttr.in/YourTown?u&format=3")'`. This way you can always see the latest :)
v3 does work, but you need to guess the appropriate region.
The Bayern.sxl example works, and is a good way to prove to yourself that your terminal is compatible, instead of your hoped-for region not being indexed.
In the USA, I like the National Weather Service direct APIs. I wish I could get more granular forecast data, both in time and space, but they forecast dewpoint/humidity, which is really nice.
Yes, I am using a handful of different APIs. My full terminal weather setup deserves its own blog post... but until then, here are some zsh snippets, scripts, and curls to get you started.
Rough weather information for next days and hours:
# Find zone with curl https://api.weather.gov/points/40.5878,-103.0694
ZONE=${ZONE:-CAZ508}
echo "Forecast for zone $ZONE"
curl -s -A MyWeather/1.0 https://api.weather.gov/zones/forecast/$ZONE/forecast \
| jq -r '.properties.periods[] | [.name, .detailedForecast] | join("\t")' \
| column -t -s $'\t'
# Find grid with same curl
GRID=${GRID:-MTR/93,131}
echo ""
echo "Next 24 hours for grid $GRID"
curl -s -A MyWeather/1.0 https://api.weather.gov/gridpoints/$GRID/forecast/hourly \
| jq --arg date $(date -Is) -r '.properties.periods[] | select(.startTime >= $date) | [(.startTime), ((.temperature|tostring) + " " + .temperatureUnit), (.windSpeed + " @ " + .windDirection), .shortForecast] | join("\t")' \
| column -t -s $'\t' \
| head -n 24
Weather discussion script (also using regexps to parse HTML):
Here's the script I use to access that API but it is still under active development and is pretty tailored for my situation. Please forgive jankiness. Give it LAT / LNG environment variables.
Where I live dew point gives a very strong indicator of our overnight low temperatures, especially in winter. Looking at dew point can tell me whether to expect frost or not and if black ice is likely to be an issue in the morning.
But yeah, treating those guidelines as anything other than a loose suggestion is meaningless.
It might just be me, but I never saw the usefulness in widgets that shows the current weather, at your current location. I mean can’t you just look out the window?
Stuffing a three days weather report into $PS1 might be to much information for a prompt.
I have to get up and walk to the window, so looking it up in the terminal is much faster. But I agree that it feels somewhat detached from nature. Also the thermometer at the window varies a lot with direct sunlight or wind, so i find these weather services give a better estimate to what i should be wearing when i go outside.
I’m reminded of the old discussion of which clock program for X11 consumed the least resources and screen size. It concluded with something like: “Of course, the clock which consumes no resources, and does not take any screen space, is the clock which hangs on your wall.”.
That's a great old-school idea. I used to run it that way but forgot.
I have also started adding a time stamp to the second, so that when I run long commands and come back later in a tmux session I can see when it finished.
Emojis? For the current weather, a single emoji could convey quite a lot; e.g. a snowflake for sub-60 weather (I have a low tolerance for cold), a sun for 60-80, fire emoji for 80+...
Now, I don't know if anyone truly needs the weather in their terminal prompt, but it is doable.
i know you’re referring to the shell prompt, but it reminded me that PowerShell file extension is also *.ps1 (which I find strange as I’m not used to seeing numbers in file extensions).
didn’t this really come up when MS was designing PowerShell?
So I do a basic `curl wttr.in` and I get back a line "Weather report: not found" followed however, by what appears to be a full weather report. Two things:
1. Either give me an error and exit, or warn me about something meaningful
2. Show me the location of the weather report, as it stands I'm left guessing
Otherwise, it's nice to see people making simple text interfaces for important data like this.
My little custom command (HN formatting break it all so need to be nicely formatted again).
alias weather=weather
function weather() {
if [ $# -le 2 ]; then
Command="wttr.in/$1"
if [ $# -eq 2 ]; then
Command="$Command,$2"
fi
fi
Command="curl ${Command// /%20}"
eval $Command
}
in ~ 2016 I built a plugin for on-my-fish to simplify the process of curling wttr.in https://github.com/oh-my-fish/plugin-wttr. From today I'm still using this plugin a lot. Checking out the weather on your terminal turns out to be faster than open a weather website or unlock my phone and check in out a weather app.
interop done the right way: this guy is going to be in trouble with the web javascript kiddies.
Yes, if this guy is a state-sponsored computer security hacker, he could pown the 3, maybe 4, ppl (and I am one of them) using its http services via curl and our terminals or image format parsers or etc. Is this worth for that many ppl?
Anyways, that's too sexy, I am willing to take the bait.
That said, I could use an official/trusted online source for the weather information and format it myself (I guess I would get a CSV or json or xml file).
alias weather="curl wttr.in && curl v2.wttr.in && curl v3.wttr.in"
so that it shows me the temperature chart and map as well. Well, v3's map isn't working so I commented that out for now but they say it should work in the future.
When writing these things, I prefer using the “sleep” command as the while condition. This way, the loop is easier to break out of. I.e. when I press Ctrl-C, the sleep command returns a non-zero exit code, and the while loop terminates gracefully:
while sleep 60; do clear; curl -s wttr.in; done
Otherwise, I very often get a loop which stubbornly refuses to abort, and I have to hammer both Ctrl-C and Ctrl-\ to make it stop. The downside is, of course, that I have to wait 60 seconds (in this case) the first time. When this is a problem, I just unroll the loop slightly and add an extra invocation to the beginning:
clear; curl -s wttr.in; while sleep 60; do clear; curl -s wttr.in; done
This could be generalized into a terminal watch function:
termwatch(){ delay="$1"; shift; clear; "$@"; while sleep "$delay"; do clear; "$@"; done; }
termwatch 60 curl -s wttr.in
> ^C breaks out of this loop just fine on my system.
It might be different when run as a script (with a separate shell process) to when run as an explicit loop in an interactive shell, or a shell function.
Personally I think it's a cute thing and have implemented some similar little easter eggs to this via: curl ip.wtf/moo
[1]: https://blog.mozilla.org/security/2019/10/09/iterm2-critical... [2]: https://packetstormsecurity.com/files/162621/rxvt-2.7.0-rxvt...