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.