4 ms·

This still doesn't solve the problem of upstream security, since it requires clients trust the Quicklisp repository which is centralized rather than the individ

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.

deleted 9y ago
[deleted]
nerdponx 9y 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.
- armitron 9y 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-openssl.pdf https://trailofbits.files.wordpress.com/2008/07/hope-08-open... [2] https://www.youtube.com/watch?v=UFFTYRWB0Tk https://www.youtube.com/watch?v=UFFTYRWB0Tk
sigjuice 9y ago
Is there an example of solved upstream security? Perhaps CPAN, Homebrew, pip, OPAM, some Linux distribution, pkgsrc or some other BSD thing?
bandrami 9y 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.
- armitron 9y 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-with-alan-kay/240003442 http://www.drdobbs.com/architecture-and-design/interview-wit...
  - bandrami 9y ago
    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.
    - armitron 9y ago
      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 https://news.ycombinator.com/item?id=12938269
  - dreamcompiler 9y ago
    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.
aidenn0 9y 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:// http:// upstreams need to go away.

deleted 9y ago

[deleted]

nerdponx 9y 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.

armitron 9y 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-openssl.pdf https://trailofbits.files.wordpress.com/2008/07/hope-08-open... [2] https://www.youtube.com/watch?v=UFFTYRWB0Tk https://www.youtube.com/watch?v=UFFTYRWB0Tk

sigjuice 9y ago

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

bandrami 9y 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.

armitron 9y 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-with-alan-kay/240003442 http://www.drdobbs.com/architecture-and-design/interview-wit...
- bandrami 9y ago
  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.
  - armitron 9y ago
    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 https://news.ycombinator.com/item?id=12938269
- dreamcompiler 9y ago
  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.

aidenn0 9y 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:// http:// upstreams need to go away.