Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On piping Curl to apt-key

tablix.org

Post reply on HN
Print view View original

11–20 of 47 posts

Re: On piping Curl to apt-key

#11

Post by tokenizerrr »

mdekkers wrote: post #7
faho wrote: post #2

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

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.

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.

Re: On piping Curl to apt-key

#12

Post by vbezhenar »

teolandon wrote: post #6

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 w…

People are lazy, developers are people, most developers are not interested in process of system maintenance, so if something could be done fast and easy, they could care less about it. My colleague uses Windows 8 preinstalled on his laptop 5 years ago, it's slow as hell and ridden with all kinds of toolbars, but he doesn't want to make an effort of full reinstall. He would happily pipe curl to bash, actually I'm not even sure if he understands what curl or bash is, he knows some Java and JavaScript and that's enough to be paid.

I like tinkering with system, I reinstalled my home server may be 20 times, I'm always reinstalling macos from scratch when new version released, but honestly it's not very productive time spent, so I understand people who just want to get things done.

I think it's failure of current operating systems: installing software is still too hard and tedious. Opening terminal and copy-pasting strings is not a trivial activity. If one could install npm by pushing button in their website, they would do that instead.

Re: On piping Curl to apt-key

#13

Post by zimbatm »

faho wrote: post #2

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

Or even better yet: `--match-fingerprint "9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88"`

Re: On piping Curl to apt-key

#14

Post by zimbatm »

zimbatm wrote: post #13
faho wrote: post #2

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

Or even better yet: `--match-fingerprint "9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88"`

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?

Re: On piping Curl to apt-key

#15

Post by yakult »

teolandon wrote: post #6

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 w…

Look at it this way: whenever you are running a program you didn't write yourself, you're running a bunch of commands you never checked. This is no different to, say, downloading a precompiled executable and running it, with all the same problems and tradeoffs.

Re: On piping Curl to apt-key

#16

Post by rakoo »

faho wrote: post #2

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

... and then you have to check the fingerprints manually, and delete the ones you don't want manually.

No, what would really solve this specific issue is allowing apt-key to add only a single key, and give it the expected fingerprint (as zimbatm explains)

Re: On piping Curl to apt-key

#17

Post by ckastner »

yakult wrote: post #15
teolandon wrote: post #6

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 w…

Look at it this way: whenever you are running a program you didn't write yourself, you're running a bunch of commands you never checked. This is no different to, say, downloading a precompiled executable and running it, with all the same problems and tradeoffs.

It is different. While it is obviously true that I haven't checked all of the binaries I'm running, I at least can, through the various signatures involved, rely on the fact that it was created by a particular individual or group, whom I may trust.

Would you really assign the same level of trust to, eg, a sudo(8) binary downloaded somewhere of the internet as you would to the one provided by your distribution?

Re: On piping Curl to apt-key

#19

Post by orf »

lorenzhs wrote: post #10

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

Try doing that behind a corporate proxy. If `apt-key` just fails there is no way to enable logging.

It also apparently works by generating a bash script in /tmp/ and executing it...

Re: On piping Curl to apt-key

#20

Post by mseebach »

ckastner wrote: post #17
yakult wrote: post #15

Earlier quoted context omitted.

Look at it this way: whenever you are running a program you didn't write yourself, you're running a bunch of commands you never checked. This is no different to, say, downloading a precompiled executable and running it, with all the same problems and tradeoffs.

It is different. While it is obviously true that I haven't checked all of the binaries I'm running, I at least can, through the various signatures involved, rely on the fact that it was created by a particular individual or group, whom I may trust. Would you really assign the same level of trust to, eg, a sudo(8) binary downloaded somewhere of the internet as you would to the one provided by your distribution?

There are various levels of trust, of course. The packages in Debian or RedHat are more trustworthy (there is a process) than those in NPM or Maven (free-for-all, even if you have some assurance that the package you're downloading is the very same the developer uploaded).

But installing a random NPM package is no more dangerous than curl-piping a script from Github to bash over HTTPS (without -k). You're still sure that what you're downloading and running is what whoever is in control of that repo intended.

What IS more dangerous is training a generation of developers to solve problems by quickly copy-pasting random strangers' magic incantations from random blogs or Stackoverflow into their terminals. You could probably infect a large number of machines very quickly by stalking certain categories on Stackoverflow for "noob" questions and giving a good answer in the form of a GitHub gist curl-pipe to sudo that fixes the problem, but that also discreetly backdoors the target.

Post reply on HN