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<[email protected]> 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
