On Do Januar 3 2008, Michael E Brown wrote:
It looks to me like the goal of adding gpg key support is to add
some
stricter security guarantees around mock builds. It would be nice if you
could codify exactly what you think the security guarantee should look
like, and what are the possible attack vectors against this. This should
guide us in resolving this.
Using gpg support for mock builds makes the resulting rpm packages more
trustworthy, because then the rpms used to populate the chroot can be trusted
to be the official Fedora/CentOS ones. This is e.g. useful for uses that have
internet access via an untrusted network, e.g. on conferences or at
universities. There easily man in the middle attacks can occur, e.g. via arp
or dns cache poisining or on conferences via rogue dhcp servers. And it also
prevents against bad mirrors. Basically, using gpg for mock chroots has the
same advantages as using gpg for a normal system.
On the other hand, shipping the GPG keys with mock creates a
maintenance
overhead, but one that I dont think is very large. These keys dont ever
(afaik) change, so it should be just a one time thing to get them in and
the configs set up.
Even when only URLS are used that point to the keys, once the keys change, it
is very likely that the URL changes, too. But I guess this will not happen
for a specific release, so only when new config files for a new Fedora or
CentOS release are created, maybe the gpg keys need to be adjusted.
Regards,
Till