On 06/14/2014 12:58 AM, Patrick J. LoPresti wrote:
The reason to release them at all is to comply with the GPL. Such encumbrances would thwart that compliance.
Red Hat only has to directly distribute source to the people to whom they have distributed binaries to meet the letter of the GPL, and they don't have to distribute sources for packages whose license does not require such (such as PostgreSQL, which is BSD-licensed); of course, they don't have to distribute the next version of the binary to you if you break their subscription agreement, either. But all of that has been hashed to death over the years, no?
Of course, Red Hat could make everything simple just by tagging the git repository for each release and update. I estimate the probability of that event as zero. - Pat
The source is coming through git, which is very good (even as it is different).
The git commit ID is a crypto signature in effect, and prevents side-channel modification in-repo without it being instantly noticed. The various spec files include the release numbers, and you can track the spec files with their commit IDs. The bugzilla entry Akemi references ends with a statement from Red Hat that they are the ones populating the incoming sources, and so seeing a git commit with a particular ID coming from Red Hat, due to the nature of git itself, you can rest that that is the source from Red Hat and that any side-channel modification will be instantly noticed by anyone with a clone of the repo. This is what git was designed to do from the ground up, after all.
This gives a great history as well, and it's more secure than an ftp site, since someone compromising the package-signing key could modify an arbitrary package and resign without being noticed, but this is not possible with git. (See news from August 22, 2008 for a bit of a reminder of history.) See the recent goings-on with TrueCrypt and the change of signing key, etc, for a bit of context.
So, somewhat paradoxically, I would have a greater confidence in source from git than source from a signed source RPM, again due to git's design. Yeah, I know, it's not what we're used to, and there is a bit of information that a package.src.rpm has that the git repo won't have, but it's possible to produce binary compatibility without that bit of info. It may seem to be more work, but time will tell.
