On piping Curl to apt-key • Hacker News Board

Re: On piping Curl to apt-key

#41

Post by lysium » Tue, Aug 22, 2017, 11:21 AM UTC

digi_owl wrote: post #27

vbezhenar wrote: post #12

Earlier quoted context omitted.

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…

This oh so much include the upsurge in containerization and the quagmire that is Linux distro package dependencies. First of all, containerization allows for static linking via other means. Meaning that as the container holds everything a program needs to run in exactly the right versions, it produce what is practically the same as a static binary with the linked libs compiled in. Similarly, package dependencies are…

Containers are more than static linking. You can have multiple binaries, which is not really possible with static linking.

Your A and C package example are actually an argument for containers.

Re: On piping Curl to apt-key

#42

Post by lysium » Tue, Aug 22, 2017, 11:24 AM UTC

CJefferson wrote: post #24

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…

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…

Is checkinstall still available? I had great success with it.

Re: On piping Curl to apt-key

#43

Post by digi_owl » Tue, Aug 22, 2017, 11:24 AM UTC

lysium wrote: post #41

digi_owl wrote: post #27

Earlier quoted context omitted.

This oh so much include the upsurge in containerization and the quagmire that is Linux distro package dependencies. First of all, containerization allows for static linking via other means. Meaning that as the container holds everything a program needs to run in exactly the right versions, it produce what is practically the same as a static binary with the linked libs compiled in. Similarly, package dependencies are…

Containers are more than static linking. You can have multiple binaries, which is not really possible with static linking. Your A and C package example are actually an argument for containers.

It may be used, by developers, as an argument for containers. But that is just the same old lazy devs being their same old lazy self. Containers are not fixing the underlying problem.

Re: On piping Curl to apt-key

#44

Post by lorenzhs » Tue, Aug 22, 2017, 11:24 AM UTC

hsivonen wrote: post #32

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

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

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.

Re: On piping Curl to apt-key

#45

Post by lorenzhs » Tue, Aug 22, 2017, 11:27 AM UTC

orf wrote: post #19

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

hkp literally stands for HTTP keyserver protocol. Does your corporate proxy really mess up HTTP connections?

Why does it matter how apt-key is implemented? Its purpose is key management, and whether it uses bash for the job or perl or C is completely irrelevant. It's been in use for over a decade. Do you have any reason to suspect deficiencies in it just because it uses shell scripts?

Re: On piping Curl to apt-key

#46

Post by reacweb » Tue, Aug 22, 2017, 11:28 AM UTC

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…

I like very much this formalism to installation procedure description. Being curious and informed about the risks, I will not do a copy paste of curl ... | sudo .... I will do a curl to a temporary file, edit the file and if there is nothing fishy, I will copy the commands (from the file, not a browser) to a terminal.

If the content of the file is a very messy (or too long) script, I consider that the software will also be messy and does not deserve my time.

This formalism flatter my ego, proves transparency and makes me spare time. Full benefit. It is dangerous for noob, but is also a good opportunity to educate them.

Re: On piping Curl to apt-key

#47

Post by isodude » Tue, Aug 22, 2017, 4:25 PM UTC

anc84 wrote: post #39

isodude wrote: post #30

Earlier quoted context omitted.

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.

Seems that I can't do much about it now. Sorry!