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
signature.asc
Description: This is a digitally signed message part.
-- Fedora-buildsys-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-buildsys-list
