Of my first steps into the world of Linux this year, this sort of procedure has been one of the most glaringly disturbing. Another similar was packages being downloaded over HTTP.
On piping Curl to apt-key
31–40 of 47 posts
Re: On piping Curl to apt-key
#32Isn't the solution to publish the key on a keyserver and fetch it with apt-key? Something like apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys
Your example fetches the key from the keyserver without https. Fetching the key from the project's own site over https using curl is better.
Edited to add: Fetching from a keyserver is OKish if a) you use the long form of key id and b) your gpg is new enough that it checks that it got the key for the id it requested. Still, the Web page you copy the key id from is as vulnerable to an attack on the server as the server serving the key directly.
Re: On piping Curl to apt-key
#33Would it be possible to write a "confirm" tool that writes stdin to stderr then waits for the user to press enter before writing to stdout?
curl ... | confirm | apt-key ...
Re: On piping Curl to apt-key
#34I hate this practice, no idea how it became commonplace. Of course lots of times, installation procedures can be long and tedious, but it takes one popular project's script server to be compromised, and tons of people are suddenly running malicious commands. I would go through manually installing dependencies and setting up my system, adding repos, etc. over running some script any day. But then again some projects w…
> But then again some projects wouldn't be that popular if they were hard to install.
Slackware was my first distro back in 2007 and I still wish it had at the very least a decent installer and package manager, it is so well built but upgrading, and installing is just not as trivial when compared to Debian. I guess openSUSE (afaik) is the only remnant of Slackware that's usable - really loved openSUSE but just like every other distro in the world I have to dance to get my Wi-Fi working properly.
Re: On piping Curl to apt-key
#35Would it be possible to write a "confirm" tool that writes stdin to stderr then waits for the user to press enter before writing to stdout? curl ... | confirm | apt-key ... Of course there's no such thing as a stderr input stream, so I'm not sure this would even be possible.
That would only help if it were possible for a user to visually identify if a stream is not malicious.
Re: On piping Curl to apt-key
#36Would it be possible to write a "confirm" tool that writes stdin to stderr then waits for the user to press enter before writing to stdout? curl ... | confirm | apt-key ... Of course there's no such thing as a stderr input stream, so I'm not sure this would even be possible.
Yes, but the proper thing to do is never curl to your terminal, especially a privileged terminal. And really, you shouldn't paste either.
Re: On piping Curl to apt-key
#37I hate this practice, no idea how it became commonplace. Of course lots of times, installation procedures can be long and tedious, but it takes one popular project's script server to be compromised, and tons of people are suddenly running malicious commands. I would go through manually installing dependencies and setting up my system, adding repos, etc. over running some script any day. But then again some projects w…
I've wasted several days trying to get programs I write turned into debs and rpms, I gave up. It's a single executable you can download and put wherever you like, or download the source and './configure.py; make'. Also, I release new versions regularly, so now being in the official repositories is no good as they will get out of date, I have to run my own repositories, for several versions of ubuntu and redhat. No ch…
> I've wasted several days trying to get programs I write turned into debs and rpms, I gave up.
The formats themselves are pretty easy to create; for a .deb you just:
- Make the folder hierarchy you want to include, e.g. things like `myBuildFolder/usr/bin/myProgram`
- Make a `myBuildFolder/DEBIAN/debian-binary` file containing `2.0`
- Make a `myBuildFolder/DEBIAN/control` file which contains e.g. the name of the package and its dependencies
- Run `dpkg-deb --build myBuildFolder`
This gives a .deb package which will be tracked by dpkg/apt, allowing clean removals/upgrades/etc. unlike `sudo make install` which will spray cruft all over the system. When I used Debian, I would install all software like this.
I've never made a .deb that's compliant with Debian's packaging policies though, since that does take a lot of effort.
Re: On piping Curl to apt-key
#38Isn't the solution to publish the key on a keyserver and fetch it with apt-key? Something like apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys
In the past GnuPG didn't verify that the keys it receieved were the keys it asked for.
Is this bug fixed now?
Re: On piping Curl to apt-key
#39Earlier quoted context omitted.
Actually, ideally GPG public keys would be small enough that they could be inlined with the script. Why is it that a SSH public key are on a single line but GPG have to be a page-full?
Thinking about this I came up with the following. I tried getting the fingerprint in full but only got the short version. Not being a gpg-ninja it would suffice to make an offline version of the add command. key="$(echo "-----BEGIN PGP PUBLIC KEY BLOCK-----||mQINBFit2ioBEADhWpZ8/wvZ6hUTiXOwQHXMAlaFHcPH9hAtr4F1y2+OYdbtMuth|lqqwp028AqyY+PRfVMtSYMbjuQuu5byyKR01BbqYhuS3jtqQmljZ/bJvXqnmiVXh|38UuLa+z077PxyxQhu5BbqntTPQMfiy…
Please don't dump that much text in long lines to HN, you are breaking the layout of the page and make reading extremely annoying.
Please remove or edit your post.
Re: On piping Curl to apt-key
#40Of my first steps into the world of Linux this year, this sort of procedure has been one of the most glaringly disturbing. Another similar was packages being downloaded over HTTP.
Debian packages are signed, they are safe to transmit over http. See https://wiki.debian.org/SecureApt (which appears to have been written around the time of the transition, so it's out of date, e.g. SHA1 signatures are no longer trusted etc)