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.
