[pacman-dev] Finishing off the package signing issue -- Update

[Allan McRae]

On 01/06/11 15:56, Kerrick Staley wrote:
>>> 5) The existing packages and databases on the central repository need to be
>>> signed. A single developer can do this.
>>
>> There is absolutely no way I sign a package that I didn't build myself,
>> unless I feel personally linked to it. Moreover, a signed database is
>> sufficient to initiate the process. Signed packages are an additional and
>> independent security.
>
> They have to be signed somehow. If a db has packages with hashes but
> not signatures, and pacman accepts these packages as long as the db is
> signed, then whoever signs the db effectively is signing for all the
> unsigned packages.
>
> However, the method you suggest is equally acceptable, so we will add
> SHA256 hashes to the repos, and pacman will accept packages with valid
> hashes from a signed db, until all packages are signed, at which point
> pacman's behavior will be changed to not accept such packages.

Seem that somebody might have already thought about a transition period 
where only some packages are signed by allowing VerfiySug to take values 
Optional and Always...

>>> 4) The output of
>>> tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum
>>> as executed on an up-to-date system should be posted on an HTTPS page
>>> somewhere on archlinux.org and updated upon updates to the pacman-keyshas
>>> package.
>>
>> This doesn't seem necessary if the pacman-keys package is itself signed.
>
> You're right. The idea was that since pacman-keys will be initially
> installed without a signature check, taking this measure will make it
> more difficult for any currently compromised mirrors to tamper with
> the updates that add package signing. However, it will not make the
> system theoretically more secure, and in retrospect the practical
> benefits seem slim as well.

Why would it be installed without a signature check?  I'm assuming that 
any user can download the "pacman-keyring" package (because that is the 
more likely name than pacman-keys....) and its signature and do some 
manual verification.   In fact, I do not see the point of installing 
such a package at all without a signature check as that is a fail from 
the start.



> On Mon, May 30, 2011 at 10:27 AM, Dave Reisner<d at falconindy.com>  wrote:
>>> Non-blocking:
>>> 1) Package validation without root privileges must be implemented. Fixing
>>> this issue after the signing feature is introduced will not require more
>>> work than fixing it first. Omission of this feature will not decrease
>>> security but will cause inconvenience.
>>
>> I consider this a blocker. Also note that if this had a simple solution,
>> it would have been done by now. Ideas welcome.
>
> As I said, we can fix this after shipping the initial signing-related
> updates. Ship early/ship often, simplicity is far more important than
> completeness, and all that jazz. I'd argue further, but in the
> interest of saving your time and mine, let's let Dan decide.
>
>>> 2) pacman-key should be made production-ready. pacman-key is nonessential
>>> because users will typically not edit pacman's trustdb, and pacman-key's
>>> functionality is available via
>>> sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options
>>> although this usage is cumbersome since it is not tailored for pacman usage.
>>> pacman-key should be renamed to pacman-manage-keys to avoid confusion with
>>> the pacman-keys package.
>>
>> I consider this a blocker. To roll out a tool which implements a
>> standard procedure, but which is only half complete, is a waste.
>
> We won't ship pacman-key out at all until it is working well. In the
> meantime, end-users can get its functionality if needed by manually
> invoking gpg.


Hmm...  we can ship pacman early and often without full functionality 
but not pacman-key.  Good thing for consistent policies...

I'd say all the patches needed for pacman-key to be production ready are 
already on the mailing list.  And it is actually quite functional as it 
currently is in git.  I have been using it to manage my pacman keyring 
for months.


Allan