6 ms·

OpenPGP and SHA verification

89 points by sigjuice 9y ago

josteink 9y ago
That’s a really nice addition. Hope to see the same with Emacs lisp packages too.
- phoe-krk 9y 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 9y 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.
    - confounded 9y ago
      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).
armitron 9y 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.
- 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
rurban 9y 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?

89 points by sigjuice 9y ago

josteink 9y ago

That’s a really nice addition. Hope to see the same with Emacs lisp packages too.

phoe-krk 9y 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 9y 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.
  - confounded 9y ago
    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).

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

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

rurban 9y 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?