Two Guys Arguing

asdf-install and GPG signatures

Posted in common lisp by youngnh on 08.05.09

asdf-install is a very useful package manager for lisp code. like rubygems.

The idea is that you load up your lisp REPL, and then punch in (asdf-install:install 'some-package) to install whatever lisp library you might want. It’s then fetched from the internet, compiled and loaded into your running lisp. peachy.

I’m not sure about the specifics, but I think asdf-install looks for the software you’re trying to find on cliki, which is a public lisp wiki to which anyone can edit, or upload files.

asdf-install is smart about this sort of thing though, it expects any software you download from the internet to have an accompanying signature file. This means the author of the software package needs to sign it with his or her private key and put the signature in the same place as the package. asdf-install will then check that:

a) you have that author’s public key
b) you trust the key comes from who it says it does
c) you have given asdf-install permission to install software from that author

This is all well and good. Except it’s a bit of a headache in practice, and if the user so chooses, asdf-install will allow you to bypass these security checks.

My goal for this post was to run through an install without ever using the dubious 0: [SKIP-GPG-CHECK] Don't check GPG signature for this package restart.

Before I get in too deep, these following 3 links were a tremendous help in figuring what the hell was going on. I love Common Lisp, but the learning curve is very, very steep. I’ve been struggling off and on with these issues for 3 years and these pages go into a bit more depth than I do here:

First thing I do is create my own public/private keypair:

gpg --gen-key

and download and import the cliki developer keyring, which has the public keys of all developers publishing software on cliki:

gpg --import keyring.asc

Next, start up a fresh sbcl 1.0.30 image:

$ sbcl
* (require 'asdf-install)
* (asdf-install:install 'drakma)

and…we run into our first problem, GPG warns that the key id 0x595FF045057958C6 (Dr. Edmund Weitz ) is not fully trusted. Simple enough to fix:

gpg --edit
> lsign
> save

and…it blows up again, saying Dr. Edmund Weitz (key id 595FF045057958C6) is not on your package supplier list. This time, the restart is fine, as asdf-install doesn’t recommend editing the package suppliers list by hand, so choose the 0: [ADD-KEY ] Add to package supplier list restart.

Next up, cl+ssl, a dependency of drakma, doesn’t have a signature file to be found. You can sneak a peak at the project’s releases here: and see that although some of the older ones have signature files, there is, indeed, no signature for the latest release that asdf-install is trying to install. So download to your local machine, crack it open and take a quick look at the source, to be sure that it’s not malicious software. Then:

(asdf-install:install "cl+ssl.tar.gz")

Except even though you are now installing from a local file and asdf-install won’t check for a signature, the installation blows up again, because it depends on the trivial-gray-streams package, which it tries to fetch from the internet and is also missing a signature file. In fact, trivial-gray streams can be downloaded from the same directory as cl+ssl, and you can see for yourself that trivial-gray-streams doesn’t have a signature file either. So we download, peek inside and repeat the local asdf-install for trivial-gray-streams, then cl+ssl:

(asdf-install:install "trivial-gray-streams.tar.gz")
(asdf-install:install "cl+ssl.tar.gz")

This should result in stopping to alert you that the cffi and rt library authors are not trusted. Sign them with gpg, then hit the restarts to add them to the package suppliers list.

And things finally finish.

So that’s one kind of problem. Going through the process with cl-ppcre presents a somewhat different problem.

(asdf-install:install 'cl-ppcre)

When checking the signature of cl-unicode, you get the error No key found for key id 0x595FF045057958C6.

This is a misleading error message. We know it’s not true, since that’s Edi Weitz’s key and we’ve successfully installed software signed by him before. So, quit out of sbcl and let’s check that signature by hand:

gpg cl-unicode.tar.gz.asc

and we see:

gpg: Signature made Wed 23 Jul 2008 05:28:42 PM CDT using DSA key ID 057958C6
gpg: BAD signature from "Dr. Edmund Weitz <>"

Dun dun duunnn. Here’s an example of exactly why asdf-install does these security checks. The signature provided couldn’t have come from the file we were about to download, nevermind the fact that asdf-install does a terrible job of letting us know this.

However, I have trouble believing this is malicious code since it did come from Edi Weitz’s server (which could have been hacked). Since we’ve downloaded the tarball to check it’s signature anyway, we can take a look inside and see that it’s not terribly obviously malicious. So the source was probably modified and just wasn’t re-signed, so we go through the procedure to install from a local file.

So there you have a rather long-winded tour of just about everything that could go wrong when installing lisp code from wild west internet wikis. asdf-install needs some polish for sure and the packaging practices of the software on is lacking. I hear clbuild is a good alternative, but I don’t know much about it. I’d like to look into it and try this same excercise with it and post back.

Tagged with: , , , ,

8 Responses

Subscribe to comments with RSS.

  1. Luke J Crook said, on 08.05.09 at 8:47 pm

    Great post. A minor correction; it is the developer keyring, not the CLiki developer keyring.

  2. j_king said, on 08.06.09 at 10:34 am

    clbuild is rather handy. It must be built from source which you must use darcs to fetch. It’s also written in a combination of sh and lisp… so it will probably only work on machines where sh is available (ie: probably won’t run natively on Wind0wz).

    It’s the best so far, but a pure-lisp manager would be ideal, IMO. I tried lispy and was rather happy with the system but disappointed by the lack of tracked libraries… it needs some time and adoption to grow up me thinks.

    good post though. i was always too frustrated with bare asdf when I started learning lisp that I quickly moved on to the other managers like lispy and mudballs before settling on clbuild.

  3. Erik Winkels said, on 08.07.09 at 1:22 am

    Pffff, what a hassle.

    Unlike the poster above I actually prefer bare ASDF. Once you’ve got most packages installed the point is moot anyway.

  4. Philippe Sismondi said, on 01.08.10 at 6:09 pm

    Fantastic. I just spent about three hours struggling with asdf-install with clozure common lisp. This post got me over the last hump, which was the gpg stuff.


    – Phil –

  5. Alpheus said, on 05.08.10 at 10:15 am

    Thanks for the pointers! They helped me to install my first ASDF package (lispbuilder-sdl). It makes me wonder why ASDF doesn’t automatically detect when you don’t have your own public/private key pair, though, or why it doesn’t give you the option to create trusting relationships when a key isn’t in the list.

    I’ll have to hunt down the creators of ASDF and point this out to them!

  6. Elena said, on 10.28.10 at 1:17 pm

    Thank you very much for sharing.

    However, when you do:

    1 wget
    2 gpg –import keyring.asc

    aren’t you just importing a file which could have been tampered with? How can you trust it?

    • youngnh said, on 10.29.10 at 10:24 am

      I believe that keyring.asc, unlike the pages on cliki is controlled by a trusted human being. I don’t think that it’s a publicly modifiable file.

      Also, I haven’t dug into the gpg man page in a while, but I believe it has additional options that you can specify to manually check each key gpg adds when doing an –import.

      Ultimately, there is a lot of software on cliki, which is an untrusted platform. Most people just bypass all authenticity checks outright because its fast. The keyring provided an attempt to make verification just as fast.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s