
OpenPGP and SHA verification - sigjuice
http://blog.quicklisp.org/2017/09/something-to-try-out-quicklisp-with.html
======
armitron
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.

~~~
bandrami
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
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...](http://www.drdobbs.com/architecture-and-design/interview-with-alan-
kay/240003442)

~~~
bandrami
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
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)

------
josteink
That’s a really nice addition.

Hope to see the same with Emacs lisp packages too.

~~~
phoe-krk
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
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
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).

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

