On 19/02/11 09:40, IgnorantGuru wrote: <snip>
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.
Everything up until this point is not related to pacman development at all and should be taken up with whoever provides the repos you use. Pacman is not Arch Linux specific...
Note that the current implementation does not preclude having the signatures alongside packages in the repos. It just uses the version provided in the repo database. Also, if you use "pacman -U <url>" pacman will try downloading any signature alongside the package, so it is more than likely the signatures will end up there.
<snip>
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.
We are using gpgme which is maintained by gpg developers. So we are not reinventing any wheel. If that is an ill-maintained and contains security issues, then why trust gpg at all?
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.
Have you actually looked at the current implementation at all? I'm not sure how much simpler it could get. The package is downloaded and its signature - either in the repo or detached - is checked using gpg via gpgme. There is a way to disable signature check and select which keyring is being used. And that is about it...
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.
Umm... no... the *pacman* devs just feel the have better things to do with their lives, including things of higher interest to develop in pacman. Also, (almost) no-one who considers this super-critical to implement has done anything about it. And those that have obviously have not (yet?) seen it through to the finish.
In the end, the only way anything will get implemented is if patches are provided. (That includes the suggestion of providing signatures in repos on Arch Linux - look at that devtools/db-scripts projects). Dan and I have also mentioned our consulting rates in the past, which may or may not increase motivation to finish this...
Finally, *succinct* reports on where the current implementation in pacman can be improved are also appreciated. But that requires actually paying attention to what has already been done.
Allan
