[pacman-dev] Signature within repo databases?
I searched the archives, but I can not find why we stored the package PGP signatures base64'd in the repo database rather than downloading them as needed. Signatures are responsible for ~55% of the Arch repo database size, so I am guessing there must have been a tradeoff. Can anyone provide insight to this? It was 2008... Thanks, Allan
On Tue, Jul 21, 2015 at 8:54 PM, Allan McRae
I searched the archives, but I can not find why we stored the package PGP signatures base64'd in the repo database rather than downloading them as needed. Signatures are responsible for ~55% of the Arch repo database size, so I am guessing there must have been a tradeoff.
Can anyone provide insight to this? It was 2008...
2008 or 2011? I see this being read first in commit 39ce9b3afc6. The
commit to scripts is authored earlier, but committed much later.
Doesn't really matter I suppose. :)
I can't be certain what my thinking was, but I can think of a few
possible reasons. Not sure of their validity, but:
1) Fewer downloads necessary when installing/upgrading. FTP was still
a thing at the time, and it was super-slow by comparison to HTTP on
grabbing more files given the way the protocol works.
2) If/when signing databases is a thing, you want to sign the whole
database so you can have end-to-end tamper detection. Else anyone
could drop a different 'pacman-4.2.1-1' signed package in place, and
you wouldn't be able to tell the difference. If I feel confident
signing a database, I should feel confident you can't change what that
database refers to. With that said, there are checksums in here too,
so you couldn't really do this, but we don't currently run the
checksum verification if we do signature verification. This could
change.
3) When I started work on all this, I had it in my head that
signatures were relatively small, so it made sense to inline them.
Mine are only 72 bytes, for instance, while other packagers are much
longer. Modern keys generate 287 or 543 byte signatures, which are 8
times larger than I originally thought. [1]
More random stuff:
* https://wiki.debian.org/SecureApt looks like Debian only signs the
DB, and then from there, it uses the checksums to verify the packages.
Hope that helps.
-Dan
[1]
archweb=# select avg(length(signature_bytes)) as len, packager_str
from packages group by packager_str order by 1;
len | packager_str
-----------------------+----------------------------------------------------------
71.9500000000000000 | Juergen Hoetzel
72.0000000000000000 | Massimiliano Torromeo
3) When I started work on all this, I had it in my head that signatures were relatively small, so it made sense to inline them. Mine are only 72 bytes, for instance, while other packagers are much longer. Modern keys generate 287 or 543 byte signatures, which are 8 times larger than I originally thought. [1]
The signatures from ECC keys are significantly smaller, but it hasn't been supported by GnuPG for long enough to start adopting it for new keys. It would make sense to use Ed25519 for newly generated keys at some point in the near future though (like when GnuPG decides to remove it from --expert). https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc
Wed, 22 Jul 2015 11:54:22 +1000
Allan McRae
I searched the archives, but I can not find why we stored the package PGP signatures base64'd in the repo database rather than downloading them as needed. Signatures are responsible for ~55% of the Arch repo database size, so I am guessing there must have been a tradeoff.
Can anyone provide insight to this? It was 2008...
While I don't code anything, I'm an Archer since at least 2006 and had some time to kill, so here are some historic threads I found interesting/relevant: https://lists.archlinux.org/pipermail/pacman-dev/2008-December/007830.html
So do we download the signature file along with the package? Or use %PGPSIG% in the db? No answer.
https://lists.archlinux.org/pipermail/pacman-dev/2010-November/012014.html "Status of package signing work" https://lists.archlinux.org/pipermail/pacman-dev/2011-February/012410.html "pacman signing security vulnerabilities" --byte
participants (4)
-
Allan McRae
-
Dan McGee
-
Daniel Micay
-
Jens Adam