After cleaning up the tarbomb from extracting the .tar.gz on releases page I noticed this issue exercism CLI have its own directory and not install its top level directory in the ~/bin directory · Issue #879 · exercism/cli · GitHub which claims that the sudo snap install exercism is the preferred install route. However the Linux install guide at exercism.org still suggests using the tar.gz release.
The Exercism install guide is correct. The drive by suggestion on the issue about snap being preferred for the CLI is not correct.
1 Like
If snap is not the recommend install method the release should be packaged in a directory so as not to tarbomb.
2 Likes
I agree with you 
I agree with that, as well. It means that people do not need to know to avoid this, if they do not already know, while those that do already take measures without really thinking about it.
And that would be nicer.
But, there really is no need to change the archive, the instructions could be, well, more instructive.
Currently it states:
Extract from the archive
Once you have the archive downloaded you need to extract the executable from it.
- If you’re using a graphic interface (e.g., GNOME or Unity on Ubuntu): go to your downloads directory, right click on the downloaded file and select Extract Here.
- If you’re using the command line (use the right archive file name for your architecture):
tar -xf exercism-linux-64bit.tgz
But if it suggested creating a /tmp/exercism-cli-extract directory and extracting it there with something like:
cd /tmp/exercism-cli-extract
tar -xf ~/Downloads/exercism-linux-64.tgz
It will extract to the directory and then you decide where to establish the executable, and likely accomplish what would rather be done rather than extracting it at the root of a users download or wherever they chose (knowingly or unknowingly) to have it extract.
Why not offer offer a curl .. | bash script to handle extraction, install, and cleanup? If restructuring the package for some reason is not an option this would make setup and install much easier and won’t bomb the downloads folder.
What if I have a LICENSE file already in ~/downloads that I have been working on and I decide to extract exercism.tar.gz there?
Or you can skip the temp dir.
dest=<your destination path here>
tar -xz -C "${dest}" -f exercism-3.5.8-linux-x86_64.tar.gz exercism
curl | bash is a security nightmare in the making.
The extraction/install/cleanup can be a single tar command.
1 Like
+1 for Isaac’s suggestion
I don’t think it’s a “security nightmare”, a lot of projects use curl | bash, like rust for example. Most users don’t care and will run any command as long as it’s convenient and they trust the project.
I don’t think it’s a “security nightmare”, a lot of projects use
curl | bash, like rust for example.
I’m very aware.
Most users don’t care and will run any command as long as it’s convenient and they trust the project.
That’s the problem, though. People trust what they read online without necessarily critically evaluating if they should be trusting what they are reading!
I uusually don’t extract until I see the file listing, so I am aware that you can do that. So many options. But for those that don’t know, how do they know?
I only provided an idea. If we state ot use -C people will still potentially overwrite content, if they are not aware of what it is doing. I think for the least experienced uses extracting to a temporary directory provides at least some chance that they are looking at what they are doing.
But you can’t protect everyone. A lot of people will just do what they are told, without understanding. And that is probably especially true on sites that provide a learning experience (other than the fact that you learn when things are destroyed from being unaware.)
You don’t have to protect anyone from themselves if you just follow best practices for tar. You can discuss the best way to protect users from tarbombing their download folder but in the end the whole reason that is an issue is because of the release package structure.
It’s like having a sign that says “warning this sign has sharp edges”.
Making the user look before acting is a good idea, but your command only gets us half of the way. The binary still needs to get somewhere usable so that’s an extra step that might go awry. On the other hand, Isaac’s command does that while still prompting the student to stop and think. I don’t see why we can’t prominently feature both commands here as long as only one is the default recommendation to make it easier for students going through the docs.
I don’t see why we can’t prominently feature both commands
Presenting multiple choices tends to confuse people. Having one, simple path is a lot easier for people to follow.
Agreed that changing the structure is probably the best option, though it can be combined with a more sophisticated tar command.
I think we’re on the same page here. One command is presented as the default. There isn’t a “pick this or that” moment.
So we do something like
Extract straight to your chosen destination:
dest=<your destination path here> tar -xz -C "${dest}" -f exercism-3.5.8-linux-x86_64.tar.gz exercism
Then we add an exercism/note block documenting what to do if you want to see inside the archive first.
~~~exercism/note~~~
some text heremkdir /tmp/exercism-cli-extract cd /tmp/exercism-cli-extract tar -xf ~/Downloads/exercism-linux-64.tgz ls``` ~~~
If you’re extracting the entire archive, I can understand wanting to examine the files. I am less sure if there’s much value in extracting the entire archive to a temp file if you already know which file in the archive you want. tar -t lists the files without extracting them.
While we could make this a whole lesson on tar and examining downloads, we should bear in mind the purpose of this documentation: provide the simplest and most streamlined steps a user can follow to get the CLI running.
1 Like
Yeah, I’m in agreement here. It feels a bit tacked on. The task at hand is getting the binary downloaded and put in a location students can use for their own setups. We should show the command that best lets students do that. I’m also in favor of updating the packaging to avoid the tarbomb in the first place.
I think part of the problem here is that as engineers we tend to think logically about a problem we project that onto the user. They should check the files, they should extract to /tmp, they should this, that, and the other. But in reality users are impatient, irrational, and emotionally driven. My first thought when tarbombing my downloads directory wasn’t “yes! a learning experience!”.
Sure you can treat this as an exercise left up to the reader, but I think most people just want to copy and paste some commands into their terminal and be good to go.
I think we’re in agreement about that 