On Sat, Jul 5, 2014 at 8:23 AM, Karanbir Singh <mail-lists at karan.org> wrote: > On 07/05/2014 05:08 AM, Nico Kadel-Garcia wrote: >> On Fri, Jul 4, 2014 at 11:15 AM, Karanbir Singh <mail-lists at karan.org> wrote: >>> On 07/04/2014 02:46 PM, Nico Kadel-Garcia wrote: >>>> Please consider the use of signed GPG tags for actual >>>> SRPM updates, rather than merely relying on '[package].metadata, to >>>> help assure provenance for people who may test or rebuild security >>>> components. >>> >>> the content you get is pushed over https, the implementation on >>> git.centos.org seems fairly secure. the content into the machine is via >>> ssh, over a guranteed ( in as much as network can be guranteed ) link. >>> >>> we are also preventing anyone else from being able to commit with the >>> source importer username/email and or using the word 'import' as the >>> first chat in the commit. >> >> Thanks. But Karanbir, "commit" is not the problem I'm referring to. >> It's the ability to substitute a trojaned, fake repository in between >> you and the client, to commit a "man-in-the-m8iddle" attack Valid SSL > > what about git.centos.org's ssl cert looks invalid ? Also, if you are > doubting SSL as a transport, we've all got bigger problems. Today? *Nothing*. It's not git.centos.org, itself, that I'm worried about. The proper use of private/public key pairs, such as SSH and SSL private keys, can help protect the central repository from improper access, and I assume that you folks are also doing code review before pulls are accepted into the primary repositories. It's man-in-the-middle attacks for remote software downloaders. They'e vulnerable to trojaned repositories. placed *in between* their local client and git.centos.org. And SSL itself is vulnerable to forged keys using stolen signature authorities, whether local to a remote environment or such as the stolen "GlobalSign" keys. There are even environments that put proxies in front of *incoming* traffic, locally, to slap a new internal and internally signed SSL key on it, and *deliberately* do man-in-the-middle monitoring at the proxy. There are others that block most external HTTP/HTTPS and route only a few allowed external websites through an internal DNS address at the proxy: they've effectively insisted on being a man-in-the-middle for their own internal monitoring and traffic control reasons, and they can wind up using internally signed keys. They certainly can't use *your* keys for that!!!! There's also verification of the content in local working repositories. If I make a fork of https://github.com/rpms/kernel over to "https://github.com/nkadel/centos-kernel-test-usb/", and someone else works with me on it and makes their own clone, they have to have a chain of trust between their work, your work, and my work. I would find it much safer, and more useful, have something like a GPG signed git tag in the repo that cleanly defines your release. It helps profoundly to ensure that the tag, which can be tied to a specific SRPM number quite safely and easily, also ensures the full provenance of the code as being what you folks over at CentOS actually published. Otherwise, we enter a potentially pretty painful world of having to manage and verify git commit checksums, and that way lies unstable hackery scripting madness. The GPG keys on the SRPM's have been one of the very useful checks of veracity and provenance on varous projects, I'll save commentary on how much more useful I think consistent tag naming conventions are than doing 'grep' on string logs to deduce commits. But the security benefits of I realize that it's work, but at least in a technology sense, I do think that it could be integrated into the git.centos.org repository. Frankly, I was a more than a bit surprised to see that tags, especially GPG signed tags, weren't already in use. for defining the SRPM numbers. I do think that it would be much cleaner than trying to derive build numbers from "git log" analysis.