Re: [pacman-dev] pacman signing security vulnerabilities

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 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