[pacman-dev] [ Package Signing ] Your signature please

18 Feb 2011

      Greetings - I was directed to this list as the place where stuff is getting done on package signing.  I would like to share some thoughts on this which I hope you'll give some serious consideration.  One, I would like to convince you to change your order of operations slightly to the benefit of both users and developers, and two I would like to share some thoughts on open security approaches.

First, thanks to Allan and the others who have put some real effort into making this a reality.

Nevertheless it is proceeding very slowly and from what I gather is not being given much priority.  Obviously that's because the devs don't feel it is worthy of priority.  So be it.  But if you're going to proceed this slowly with it, please consider changing your order of operations so we users can help ourselves.  Specifically, please put providing signatures first, even before your automated signature checking or your final design is complete.  If you need to later change how the signatures are stored or keys or other details, that's fine.  But get the packages signed and get the signatures onto the mirrors in some usable form.

You're currently having armchair debates about arcane replay attacks while the data on the servers is sitting there completely unprotected, and users have no way of verifying its authenticity.  Just getting the signatures out there will improve security by several orders of magnitude.  The threat is not just a matter of data integrity on the mirrors, but providing a way for users to verify data coming over their networks, from shared caches, stored locally, etc.  As one commenter on my blog expressed:

    "I think you’ve motivated me to try another Linux distribution after years
    with Ubuntu.  You’ve interested me in Arch too, but there is no way I’m
    going to install it on my desktop, let alone server before they implement
    package signing. Their mailing list suggests that this is a milestone of
    not so near future. Unsigned package installation is a security breach of
    cyclopic proportions, anyone who hacks your old wifi AP will be able to
    inject malicious Arch packages by repository proxying, this isn’t even
    possible with Windows updates."

And repository proxying is just one of a whole host of security issues unsigned packages create, which have nothing to do with the security of the mirrors.  It's a local thing.  Arch is depending on very flimsy security through obscurity at this point - hoping no one will go to the trouble - and providing no options to users.

If you require the packagers to routinely sign packages now with their keys, get their keys onto key servers, and get the package signatures on the mirrors, at least we have some way of verifying the data.  You don't need to rewrite GPG - it's there.  I for one would be happy to write a script that scans the pkg cache and checks the sigs.  This way when someone says "Arch doesn't have package signing" we can reply "Actually packages ARE signed - we're working on the automatic checking, until then check them yourself".  Archers are very good at this sort of thing.  But we can't do anything until the sigs are available, and that requires a minimum of effort on your part.  It's probably already implemented.  And the security precautions you need to take at this point are minimal - just publish the signatures somewhere - they are self-protecting.  You don't have to tell anyone what they should do with them or how they are best used - let us worry about that for now.

This will also give you the time to get pacman's automated signature checking available on your own timetable, while your servers have some minimal protection (actually quite a bit).  Plus instead of rolling out the whole system at once, you'll have the signing and distribution of signatures and keys already in use - perfect for you to test your checking on the real mirrors, and to be exposed to some of the issues that will arise.  And you'll have scripts by then which can double-check your checking, so you don't have to feel like everyone's security is on your shoulders alone.  As you've probably noticed by now, security development is a high stress endeavor.  Break up the load and let problems be found in a more gradual way.

Users who have higher security needs or who operate on questionable networks will then have a way to verify their packages.  Users who don't want to be bothered can wait until you finish your pacman adjustments.

In short, please make the signatures and keys available ASAP.  That's great you're working on your security design and automatic checking, taking your time and being careful, but at least give us some sigs for now so we can help ourselves.

On the subject of security formats and protocols, I wanted to throw a few ideas in there.  First, I think keeping it simple is very important, especially for Arch.  I believe any user with GPG should be able to verify a package, no other tools required, and no digging into databases for signatures.

Instead of placing signatures in a db file, I think serious thought should be given to using the built-in encapsulation features of GPG.  Why have a separate sig file or db mechanism?  Wrap the data in the signature - that way it begs to be checked.  It can be as simple as package.tar.gz.gpg   And checking it can be as simple as manually running the package through GPG.  This is very good for security - users can use GPG directly to examine signatures, keyrings, and anomalies.  (Pacman in the short term could be adjusted so it simply removes the signature layer without checking.)

Also, devs love to make code efficient, but in this area consider not making that your top priority.  There are many PGP/GPG libraries which are ill-maintained compared to the long-lived GPG, and they can introduce security problems.  They also further remove the user from control of security, which makes for bad security.  I suggest having pacman run gpg for its security needs, in a transparent way to the user.  No reliance on other libraries.  This will have a minor cost in efficiency, but it is a good KISS model and in the long run will improve security.  (Many of the PGP APIs were little more than attempts to weaken PGP.)  This also makes your job easier.  Why reinvent the wheel?  The command line does just fine, and gpg gets much more scrutiny in cryptographic circles than the many libraries that allege to duplicate it.  Use the real article.

When modifying pacman, don't make it overcomplicated.  I think users should have some way to specify a custom keyring to be used, and a way to disable or ignore signature checking.  Beyond that, keep it minimal and simple.  The more complex you make it, the less secure it will be in real world applications.

As for replay attacks, you may want to consider this an opportunity to change the way package management is handled more generally.  It has some weaknesses that are not based solely in package integrity.  If you try to address those weakness with the wrong tools (such as signatures), you're going to create an unnecessarily complex system with compromised security.  I suggest making package signatures available now, then working carefully on the overall management system.  Change is good.

Obviously Arch devs are new to some of these security models, which I believe is one reason you have shown so much reluctance to tackle it.  You don't want to mess it up and be embarrassed.  Everyone who works in security plays the fool sometimes - ask Phil.  Security is very tough and imperfect work compared to many areas of development, cryptographic security especially so.  But don't let this reluctance make you choose a total lack of security, which is the current status quo in Arch packaging.  Do your best with it, move on, and do your best some more.

The weakest link in your security BY FAR will be the key maintenance practices of the packagers, and the security of their personal systems.  They should be advised to self-sign their keys, have their keys signed by others, use strong passphrases, not use passphrase caching or convenience tools of any kind, have 6 month expiration dates on keys, and revoke keys routinely anytime local system security may have been compromised.  This issue completely blows away replay threat models in severity, and its an imperfect science.  You just do your best.  But some guidelines should be provided to packagers at some point, and should be enforced where possible.

Yet on these issues, please don't debate them before providing signatures to current packages.  Get it started, imperfect as it is.  If you change keys, file formats, or protocols later, than is not only fine, but such changes should be considered a routine part of the development of Arch's secure package management.  Let's get it started.

IgnorantGuru

Allan McRae

IgnorantGuru

Denis A. Altoé Falqueto

Allan McRae

Daniel Mendler

Allan McRae

Pierre Schmitz

Daniel Mendler

IgnorantGuru

Allan McRae

IgnorantGuru

Allan McRae

Allan McRae

Xavier Chantry

IgnorantGuru

IgnorantGuru

Allan McRae

Loui Chang

Alf Gaida

Jelle van der Waa

Alf Gaida

Daniel Mendler

Allan McRae

Alf Gaida

Dan McGee

Daniel Mendler

Allan McRae

Daniel Mendler

Allan McRae

tags

participants (10)