OpenPGP and SHA verification

http://blog.quicklisp.org/2017/09/something-to-try-out-quicklisp-with.html

by sigjuice • 9 years ago

89 16 9 years ago

blog.quicklisp.org

josteink• 9 years ago

That’s a really nice addition.

Hope to see the same with Emacs lisp packages too.

phoe-krk• 9 years ago

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.

txru• 9 years ago

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.

armitron4• 9 years ago

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.

nerdponx• 9 years ago

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.

armitron4• 9 years ago

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

sigjuice• 9 years ago

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

bandrami2• 9 years ago

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.

armitron4• 9 years ago

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

dang• 9 years ago

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.

aidenn0• 9 years ago

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.

rurban• 9 years ago

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

OpenPGP and SHA verification

Related Stories