[pacman-dev] pacman signing security vulnerabilities

[Allan McRae]

On 16/02/11 04:57, Michael Seiwald wrote:
> On 02/15/2011 02:27 PM, Dan McGee wrote:
>> On Tue, Feb 15, 2011 at 7:18 AM, Michael Seiwald<michael at mseiwald.at>  wrote:
>>> On 02/08/2011 11:02 PM, Dan McGee wrote:
>>>>> (4) Signing keys
>>>>> Currently when adding a signed package to the repository with repo-add,
>>>>> the signature of the package itself (generated with the package
>>>>> maintainers’ key) is included into the sync db (as %PGPSIG% field in the
>>>>> desc file of the package). Afterwards, the updated sync db is also
>>>>> signed. Firstly, we are not sure how this should be handled in practice.
>>>>> Will the sync db be signed with a central repository key? Or with one of
>>>>> the developers’ keys? Either way, the package signature in the sync db
>>>>> (%PGPSIG%) adds no additional security value, because when pacman
>>>>> verifies both the package signature and the signature of the sync db, it
>>>>> uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the
>>>>> signatures.
>>>> But not one key, and how does one verify a package they got that was
>>>> not in a sync DB? Or in a sync DB managed by someone they may trust
>>>> less, but packaged by someone they may trust more?
>>>
>>> A package not in a sync DB cannot be verified - regardless of keeping
>>> the package signature in the sync db. If the sync DB is signed, the hash
>>> of the package file is sufficient to verify its integrity. The only way
>>> allowing for the verification of packages which are not part of the sync
>>> DB I can think of would be to somehow make the packages contain the
>>> signatures (like RPM packages).
>>
>> I am not following this point whatsoever.
>>
>> RPM package containing signature == zip of signature + package
>> contents in another zip. There is no added security benefit of this
>> that I can possibly see over package + detached signature- the only
>> thing they are doing is tying it up with some ugly rope and shipping
>> it to you as one file.
>>
>> And the hash of the package file is not at all enough to verify
>> integrity! For one, md5 is not secure, and we've never pretended this
>> is supposed to be anything more than a quick download check. Second,
>> you have continued to run around the issue I stated where not all
>> packages are in a sync repository- drop your "If" clause and your
>> whole point falls down.
>>
>> Your other point, "A package not in a sync DB cannot be verified", is
>> also unclear- can you please elaborate?
>>
>> -Dan
>>
>
> If the hash of the package file can be verified through the sync DB and
> a secure hash algorithm is used (e.g. SHA256, SHA512) then the hash _is_
> enough to verify the packages' integrity. In fact when using PGP you
> always sign the hash of the input data, not the whole data itself which
> would be slow and produces very large signatures.
>
> Of course if you want to verify packages which are not part of the sync
> DB you can only verify them if there is either a detached signature or
> if the signature is somehow part of the package. The problem that I see
> with a detached signature is that the user has to download two files
> manually to verify the packages' integrity. I think that especially
> inexperienced users might just download the tarball and install it anyway.

The current implementation attempts to locate a signature file from 
alongside a package when installing using pacman -U.  Note that pacman 
-U works with both local and remote packages.   So that is automated 
from a users perspective.

> What I meant by "A package not in a sync DB cannot be verified" is that
> the current implementation adds the base64-encoded signatures to the
> sync DB so if the packages is not part of the sync DB (e.g. because it's
> outdated) how can it be verified in the current scenario? Or maybe I am
> missing something.

That is correct.  But it is both a good and bad thing...  e.g. it means 
that packages replaced due to a major security flaw are no longer signed.

Allan