zlacker

deb/rpm is better because it's usually signed by maintainer with GPG keys. I think that it's harder to steal keys from maintainer than to infiltrate web server.

>>vbezhe+(OP)
We came up with a way to do gpg verified curl | bash for ZeroTier. It still works without gpg too. Scroll down to Linux.

https://zerotier.com/download.shtml

>>vbezhe+(OP)
For the most part you receive the GPG keys over the same TLS connection, though.

>>cjbpri+21
Not sure what you mean. I don’t think apt-get install foo involves transferring GPG keys.

>>sigjui+L1
We're comparing the security properties of

`curl https://somesite.com/foo.sh | bash`

with

`curl https://somesite.com/foo.deb`

and

`curl https://somesite.com/apt.key | sudo apt-key add - && sudo apt-get update && sudo apt-get install some-software`

I don't think there are very meaningful differences in the security properties -- I don't think it's more difficult to become compromised by one than by one of the others.

>>cjbpri+21
That's an antipattern, should use keyservers.

>>fulafe+l4
Aren't keyserver lookups usually keyed off a 32-bit key ID though? (Whose space isn't big enough to avoid someone brute-force generating a key with a certain key ID s.t. you think you got the right key.) You're supposed to check the fingerprint, but you need to get the fingerprint, and for that you need a secure channel, and you're right back to square one.

For that matter, where did you get the key ID.

>>cjbpri+B2
No, you're deliberately choosing a bad way to get a key to try to prove your point. You shouldn't be fetching a key from the site that might be compromised.

>>cjbpri+B2
No, there's no effective difference between those examples, apart from maybe post mortem analysis. It's also a poor method of key discovery, as hueving said.

>>huevin+J8
> You shouldn't be fetching a key from the site that might be compromised.

You shouldn't, but people do, and are being directed to do so increasingly as Linux becomes more popular. Software developers want to be software publishers so bad that they're just going to keep pushing, and therein lies the risk: If people get the impression that packages are somehow more secure than shell scripts, then these kinds of attacks will simply become more prevalent.

To you it's obvious that packages aren't more secure, it's how you get them that makes their normal use more secure. That's apparently too subtle a point for even big companies like Microsoft.

https://pydio.com/en/docs/v8/ed-debianubuntu-systems

https://docs.docker.com/install/linux/docker-ce/ubuntu/#inst...

https://www.spotify.com/uk/download/linux/

https://www.elastic.co/guide/en/apm/server/current/setup-rep...

https://ring.cx/en/download/gnu-linux

http://docs.grafana.org/installation/debian/

https://support.plex.tv/articles/235974187-enable-repository...

https://stack-of-tasks.github.io/pinocchio/download.html

http://download.mantidproject.org/ubuntu.html

https://docs.microsoft.com/en-us/cli/azure/install-azure-cli... (!!!)

>>vbezhe+(OP)
They could be. dpkg and rpm will still install unsigned packages by default. That's one problem.

Another problem is that people are being trained to get software [directly] from software developers.

>>fulafe+l4
Where do you get the keyserver ID? From the website? You're back to square one, because anyone can upload anything to a keyserver. If they can modify the website (change files, etc) they can also change the keyserver ID they're telling people to use.

The "antipattern" is letting/expecting software developers also be software publishers.

>>cjbpri+21
GPG's trust model is outside the transport layer, via signatures.

Not foolproof, but it answers your objection.

>>fulafe+l4
Still not safe.

Verify key signatures.

And I really wish GPG had a negative trust signature.

>>dredmo+0e
Verify it against what?

>>dredmo+0e
Yeah, if there are signatures then it doesn't matter. But often both are a miss.

Eg the key from https://docs.docker.com/install/linux/docker-ce/ubuntu/#set-... doesn't have signatures, and isn't on the keyservers.

Of course an unsigned key missing from the keyservers still has the advantage that on subsequent installs/updates, the previously downloaded key persists. And you can keep the initially downloaded key in your CI configs.

>>Dylan1+ii
See what keys have signed a given key. See Debian maintainer keys as an example.

This is ... not everything that it could be, and is approaching 30 years old, technology built for a vastly different world.

But this is the basis of the GPG / PGP Web of Trust.

https://en.wikipedia.org/wiki/Web_of_trust

http://www.pgpi.org/doc/pgpintro/

http://www.rubin.ch/pgp/weboftrust.en.html

(I've addressed this point ... a distressing number of times on HN: https://hn.algolia.com/?query=dredmorbius%20web%20of%20trust... 0

>>api+c
Quote(trying to fit it to narrow widt, for others on mobile):

  curl -s \
  'https://pgp.mit.edu/pks/lookup?op=get&search=0x1657198823E52A61'
  | gpg --import \
  && if z=$(curl -s 'https://install.zerotier.com/' | gpg);
  then echo "$z"
  | sudo bash;
  fi

It's interesting - it tries to import a given gpg key from keyserver, then grabs a gpg armored text file with a bash header - with the gpg header wrapped in a here-document:

  #!/bin/bash
  <<ENDOFSIGSTART=
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA256

  ENDOFSIGSTART=
  

I'm unsure, but I think you could just stick your malicious code before the signature?

  #!/bin/bash
  sudo much_evil
  <<ENDOFSIGSTART=
  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA256

  ENDOFSIGSTART=

So it really isn't any better, as far as I can tell. There's also a trade-off between scripts that can be typed (curl https://i.com.com) and need copy-pasting - as copy-pasting also isn't safe - even if that's a somewhat different attack vector (compromising the web site, altering js depending on visitor).

>>geocar+Bb
I've always said the same, but what's the solution here?

>>dredmo+cj
Have you contacted maintainers if they're willing to do this? Is there a way to configure apt to verify chain of trust?

>>geocar+Yb
This is a good point, which should be brought up more. Although you probably meant key id or key fingerprint, not keyserver ID, which would imply something else.

You're supposed to do additional verification of PGP keys, either through attending key signing parties (who does that in 2018?), checking the signatures of people you already trust, or comparing as much out-of-band information as you can.

It's not terribly hard to create a plausibly trusted keyring from scratch that depends on only 1 of 3 websites being legitimate. For example:

    kernel.org: ABAF11C65A2970B130ABE3C479BE3E4300411886 Linus Torvalds <torvalds@kernel.org>
    marc.info:  647F28654894E3BD457199BE38DBBDC86092693E Greg Kroah-Hartman <gregkh@kernel.org>
    thunk.org:  3AB057B7E78D945C8C5591FBD36F769BC11804F0 Theodore Ts'o <tytso@mit.edu>

All keys are cross signed as shown by gpg2 --list-signatures.

If this sounds like a pain in the ass, it's because it is, and GPG could be so much better.

Ironically, if you can't acquire the developer's public signing key, it might be best to install software directly from their website, if no trusted repositories are available. If you can acquire their signing key, it's probably best to not install software directly from their website, in order to avoid selective distribution attacks. Sort of unintuitive.

>>e12e+Nl
Putting malicious code before the signature doesn't work because gpg chops it out. It only outputs the verified part.

It is definitely a kludge though.

>>api+4B
So the shebang is redundant, except for testing during development? [ed: and for allowing the daring to just do curl|bash, I guess]

>>dcbada+Cm
There's three that I can see:

1. Walled Garden: Developers don't self-publish. Call it an app store, call it everything-in-apt.

2. Encapsulate everything so that developers can't do anything. Don't use anything unless it comes in a docker instance. Or a FreeBSD jail. Or something else. Qubes maybe.

3. Smarter users. Good luck with that one.

>>geocar+Yb
Public keyservers are well-known, and in a different security domain than the download server. Without breaking in, a rogue party can't delete or replace keys from the keyservers.

>>e12e+jU
It's not strictly necessary, no.