On Sat, 19 Feb 2011 11:21:47 +1000
Allan McRae
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?
I'm not up on the latest in gpg, what is being developed, or how well it has been cryptographically tested, and it sounds like you're not either to some extent. I was offering general suggestions - try to see the bigger picture and the details won't be so much work. I still think using command line gpg gives users better control over their own security solutions and provides better security. But you're obviously too deeply invested in the libraries now to even consider anything else (which is one reason why I advise against them). So be it.
Have you actually looked at the current implementation at all?
I read some discussions of it, but I have not looked at it. Frankly it interests me far less than having signatures available at this point. I trust that you can implement checking. I think you're putting the cart before the horse, which is why package signing is getting nowhere (no real usable results). But if you have kept it as simple as you describe, good work.
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...
Surely you have some mechanism in makepkg or elsewhere for generating the signatures used in your test repo for your pacman sig checking features. Why not push this through to the packaging or database tools now while you're still working on pacman? Or have you completely ignored the need to generate signatures (I know you haven't from what I've read, so that's rhetorical). It seems you or others are stalling on providing signatures because you want exclusive control of checking those signatures. It's trivial to implement providing them and surely you know that - man gpg for help. Like everything done by committee, I think you're making things more complicated than they need to be. It's okay, I didn't have high hopes for this communication. This issue is obviously too mired in politics and ego for anything to budge (not you personally).
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.
Agreed. FWIW, I think your pacman changes will see reality (as in popular use) much more quickly if signatures show up on mirrors sooner rather than later. Once the sigs are there, the appetite for your pacman work will be there, and the dev politics of Arch will sway. Simply put, there can be no logical or technical reason for not providing signatures for packages. At the minimum, they can only vastly improve the situation, which currently is a complete abdication of any form of responsible package security, and they are trivial to add. The only reason for not providing them is a human one - IOW irrational. I'm no diplomat - I just make things work. I'll leave you to your politics.