[pacman-dev] pacman signing security vulnerabilities

[Michael Seiwald]

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.

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.

Best regards,

Michael