On Thu, Aug 28, 2014 at 7:09 AM, Johnny Hughes <johnny at centos.org> wrote: > On 08/27/2014 09:32 PM, Nico Kadel-Garcia wrote: >> On Wed, Aug 27, 2014 at 7:28 AM, Johnny Hughes <johnny at centos.org> wrote: >> >>>> Not when the metadata is poisoned by a trojaned merge. Git logs can be >>>> edited. Without the GPG sums, it's like a web mirror that has a pack >>>> of RPM's with a pack of checksums alongside them. The owner of the >>>> mirror, or a cracker attacking the host, can corrupt *both*, and >>>> without the GPG tag, it's hard to get provenance. >>>> >>>> And *that* is one of the points where having a GPG signed tag, >>>> especially one tied to the contents of the SRPM builds, becomes a a >>>> useful tool for verifying provenance of the tree. You can't rely on a >>>> binary comparison, there's likely to be frequent skew between the >>>> rsync mirrors and the main repo as a matter of course. >>> >>> Red Hat does not want to provide us a gpg signed tag, so therefore we >>> will not be getting one. No reason to keep bringing it up. Its not >>> happening ant time soon. >> >> I'm confused by this. What does Red Hat, at least the core business, >> have to do with this? You have a GPG key you use for making RPM's and >> SRPM's, why shouldn't or couldn't you use the same key to create git >> tags? This would be for tags for *your* work, and possibly for when >> you import Red Hat source. > > We don't IMPORT the Red Hat source code ... Red Hat Engineering provides > the Red Hat source code to the machine where git.centos.org lives. (they > throw it over the wall that exists between the Red Hat Engineering team > and the CentOS team). I'm referring to the git process of "importing" code, A git "import" is precisely what you just described. If it's not an import, then why is the word you use in your own logs "import" ? I'm staring at a typical sample at https://git.centos.org/commit/rpms!kernel.git/e7a209a421ed05cf6f96076363d7f0ed9b30e1cf, where the log message is "import kernel-3.10.0-123.1.2.el7". Nothing prevents you from tagging, and signing, those imports and build versions to show that the relevant git content is indeed straight from the CentOS workflow. It is work. > Things that come in with "CentOS Sources" user (or earlier the "CentOS > Buildsys" user) are not done by the CentOS team, they come from > upstream. There is a specific user who is allowed to connect from a > specific IP that has a specific key who can import code directly. I can > not do it. So he "imports" it directly into git? (See, there's that word again!!) Well and good. > When these things come in, I see them the same way that the Scientific > Linux team or anyone else who uses this source sees them, by checking > the site. I then use the same tools that anyone else who wants to build > the source code would use, the tools here: And you, or someone with write privileges to the git.centos.org repositories, can make tags and sign those when such "imports" occur. That would help ensure the provenance of code that is cloned, or rsynced, to secondary repositories. In theory, it could even be done automatically by the build process used for release RPM's. Use the same revision data and package name that is currently in the "import" log message to make a signed tag, and developers who clone from yours or from remote mirrors will be able to be confident that the code actually came from CentOS, not from some nefarioius weasel's trojaned repository. And unlike the current "import" log messages, the naming of tags can be made consistent. I've already noticed that the kernel log "import" messages sometimes list "kernel-number', and osmetimes "kernel-number.src.rpm". That makes processing the builds a bit confusing. You can always make a new, correctly named tag from an existing tag: that's very hard to fix in an already published log file. It's not free: it involves actual work by someone with access to CentOS GPG tags and with privileges to modify the workflow. But please don't reject the concept of tagging and ensuring provenance on the basis that what is in place is secure enough. The loss of the GPG tagged SRPM access is an underlying security concern for developers whose nearest mirrors, or cloned git repos, may wind up poisoned.