
On piping Curl to apt-key - gandalfar
https://www.tablix.org/~avian/blog/archives/2017/08/on_piping_curl_to_apt_key/
======
teolandon
I 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 wouldn't be that popular if they were hard to install.

Some of npm's installation instructions ask you to pipe curl into bash, to run
a lovely script [0] which makes things easier for you, but not by much. Is it
really necessary? Would developers give up trying to get npm and node just
because installing not as easy as "curl [https://some.script.com/that-
script.sh](https://some.script.com/that-script.sh) | sudo -E bash -; sudo apt-
get install npm"?

Other than building/installing programs, adding GPG/SSH keys like in the blog
post can be as dangerous, and while not simple, there could be some method
built to make things easier without having to run commands you don't even
check.

Anyways, hope projects grow out of this habit.

[0]
[https://deb.nodesource.com/setup_6.x](https://deb.nodesource.com/setup_6.x)

~~~
CJefferson
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 chance.

~~~
FooBarWidget
I have succeeded in turning my programs into DEBs and RPMs that also properly
comply with all the distribution packaging guidelines, but it took me _two
months_. I am now onboarding two other developers but they are struggling with
making changes to DEBs and RPMs. All because of the complexity, archaic
toolchain and poor documentation.

The only reason why we made DEBs and RPMs was to please users, but it's not an
experience I want to recommend anyone.

------
lorenzhs
Isn'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 <fingerprint>

~~~
hsivonen
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.

~~~
lorenzhs
Right, sorry, it should be using hkps as protocol and leave out the port.

Especially when copying and pasting things anyway, the long form should
_always_ be preferred. I think there was an article on here several months ago
on the dangers of using abbreviated fingerprints.

Manipulation of the fingerprint on the web page could be easier to detect
using the archive.org wayback machine, which might not index the keyfile.
Doesn't _prevent_ manipulation but might make it easier to detect if you're
suspicious.

------
leni536
> Consider the case where download.docker.com starts serving an evil key file

At that point I can't trust the key ID in the docker documentation either.
Since Docker doesn't use web of trust (who does honestly?) there is no way
that I can verify the key ID in any way in the provided key file. So I don't
know how it does any good inspecting the key file before adding it to the apt
keyring.

------
jwilk
On a related note, don't copy commands from web and paste it to your shell (or
any terminal program):

[http://thejh.net/misc/website-terminal-copy-
paste](http://thejh.net/misc/website-terminal-copy-paste)

------
mdekkers
On piping anything from the Internet directly to your system for execution:
Don't be lazy. Don't be an ass.

When I am working in a persona that responsible for managing a server or a
service, I insist on knowing everything I need to know about how to keep that
service and the environment in which it operates safe, alive, and providing
usable performance.

I require good, clean and coherent instructions for deploying something at
production level, where all required components and their preferred method of
interaction are clearly explained and documented by the developer, and can be
repeated in a predictable manner by me.

If all I have to work with is "pipe this to the shell, alternatively read the
code" I'm going to go with "nah, I'll find something professional".

Time spent installing a system should be only a minuscule fraction of time
spent actually operating the system. Spending a few extra hours doing it right
shouldn't make a difference.

 _[edit: added "...and another thing" argument]_

------
faho
Wouldn't it already help if apt-key printed the list of keys it imported
instead of the absolutely superfluous "OK"?

~~~
mdekkers
_Wouldn 't it already help if apt-key printed the list of keys it imported
instead of the absolutely superfluous "OK"?_

What would _really_ help: Publishers providing the key in a clear text copy-
paste format, and providing instructions on adding the key to apt-key.

~~~
tokenizerrr
How would this help? They're still pretty unreadable and as the post
describes:

> However, two public key blocks could easily have also been exported into a
> single ASCII-armor block.

------
Rjevski
Apt-key should just have a built-in way of importing keys from HTTP(s) URLs,
preferably in interactive mode so you can confirm the keys are legitimate
before adding them.

------
tlrobinson
Would 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.

~~~
adventureadmin
Yes, but the proper thing to do is never curl to your terminal, especially a
privileged terminal. And really, you shouldn't paste either.

------
proactivesvcs
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.

~~~
lorenzhs
Debian packages are signed, they are safe to transmit over http. See
[https://wiki.debian.org/SecureApt](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)

