OpenPGP and SHA verification | Hacker News Reader

OpenPGP and SHA verification

blog.quicklisp.org

89 pointssigjuice16 comments

This still doesn't solve the problem of upstream security, since it requires clients trust the Quicklisp repository which is centralized rather than the individual package authors. The chain of trust is now bigger and more fragile.

Quicklisp works by periodically pulling packages from their official (or unofficial) repos into a centralized repository controlled by Xach. Xach then creates a Quicklisp "release" based on the set of pulled packages.

Quicklisp users end up pulling from Xach's repository rather than upstream directly.

This PGP verification update only applies to the second path: Quicklisp user to Xach's centralized repository.

In terms of actual security of Quicklisp, the situation is still not at all good, since Xach is using unsafe methods to pull code from upstream into his centralized repository:

  $ git clone https://github.com/quicklisp/quicklisp-projects
  Cloning into 'quicklisp-projects'...
  remote: Counting objects: 9495, done.
  remote: Total 9495 (delta 0), reused 0 (delta 0), pack reused 9495
  Receiving objects: 100% (9495/9495), 1.70 MiB | 1.22 MiB/s, done.
  Resolving deltas: 100% (1653/1653), done.

  $ egrep -R 'git://|http://' quicklisp-projects/ |wc -l
     125

There are ~125 projects in Quicklisp that are fetched over unencrypted and trivially man-in-the-middled protocols. Moreover, the centralized Quicklisp architecture is also vulnerable to hacking since it provides a single point of failure.

Suggestions that will provide actual security:

+ Scrap the centralized package distribution model.

+ Quicklisp acts as a metadata/added-value repository and keeps providing releases but the Quicklisp client ends up hitting upstream and not a central repository controlled by a middle man.

+ If upstream sources are insecure (git/http), flag and warn on install by default.

We had a lot of these (the important bits) with asdf-install. Unfortunately, when people started adopting Quicklisp because of the unimportant bits (convenience) they threw the baby out with the bathwater and ended up compromising on the things that truly matter.

It's not too late to recognize this and pull back from something that will never be secure. My suggestions add up to adding the convenience layer to a model that's basically asdf-install that can pull software from multiple sources.

Could this be added as an option to Quicklisp? (ql:quickload :upstream t)

Also consider the flipside. One point of failure means you only have to audit one point of failure. In theory this is how other package distributors work like Homebrew and Debian. The distributor/packager/maintainer worries about upstream. If any such maintainer gets hacked, it would ostensibly get noticed and resolved pretty fast.

Then again, Homebrew actually does use the "metadata only" model and it seems to work well.

Debian has a dedicated security team with vastly superior understanding of security issues -- and more resources -- which simply isn't the case with Quicklisp.

And even so, there have been Debian debacles [1] and allegations of compromise by nation states [2] to drive my points home.

[1] https://trailofbits.files.wordpress.com/2008/07/hope-08-open...

[2] https://www.youtube.com/watch?v=UFFTYRWB0Tk

Is there an example of solved upstream security? Perhaps CPAN, Homebrew, pip, OPAM, some Linux distribution, pkgsrc or some other BSD thing?

Ugh, no. For what you're worried about all you need is for the client to be able to securely retrieve a signed hash from upstream, which most of the upstream platforms provide as it is. I was going to charge that you wanted to take us back to the soup of irritation that was asdf-install, and then I saw that you say that in as many words, so I'll let your own statement stand.

asdf-install is absolutely the [vastly] more secure and more efficient model in terms of software distribution since it places the author in charge of his own software and not some arbitrary middle man.

You seem to think that convenience can not be added to the asdf-install model which is demonstrably false (I described how to do it). Paraphrasing Alan Kay [1], Quicklisp was done by amateurs so you shouldn't assume things can not be done better.

There is no technical barrier to something that's similarly easy to use and vastly more secure.

[1] http://www.drdobbs.com/architecture-and-design/interview-wit...

In fairness, I vastly dislike all of these solutions, and prefer to hand-manage any libraries I need per-project, which I've never found to be particularly onerous.

I do the same thing with some of the suggestions I described in my previous comments.

Here is an older relevant thread:

https://news.ycombinator.com/item?id=12938269

I don't disagree that Quicklisp needs a better distribution and security model. And maybe it was done by amateurs. But asdf is such a pig-brained overengineered impossible-to-debug, impossible-to-learn pile of impenetrable crap that Quicklisp seems downright elegant by comparison. ASDF is like git: It sucks and we are stuck with it. But FFS let's not talk about expanding its scope.

Could you please not vent irritation into comments here? You're making a good point (I agree with you—I prefer to manage dependencies myself rather than depend on complex software whose subtleties I can never remember) and then associating it with extraneous rudeness, which is bad for your point as well as for the container here.

You are wrong about what is important. The important bit if quicklisp is convenience. I can download packages from upstream and verify signatures by hand if I like. With the new asdf registry format, just dropping it in a directory tree works.

asdf-install was not convenient and was insecure by default since it didn't solve the key distribution problem.

Having a single signer solves the key distribution problem, whatever its other flaws are.

You are right that all git:// and http:// upstreams need to go away.

That’s a really nice addition.

Hope to see the same with Emacs lisp packages too.

You'd need to modify ELPA/MELPA/Marmalade for that, which is more work. Three repositories instead of one, each with a different owner and a different political situation/set of beliefs.

I think you'd only need to target either MELPA or Marmalade. Elpa's repository is more limited and out of date.

An arguably more serious problem with those is that some people host packages on the EmacsWiki, which is freely editable by anyone.

This is getting fixed soon, there's a speedy effort underway to get maintainers and a real repo, or officially deprecate those packages.

(P.S. I think most configs would survive with MELPA alone).

What C extensions would we need for CLISP? As I remember GPG should be called as binary, just the SHA hash is needed, right?

Reply on news.ycombinator.com