On Thu, Dec 18, 2014 at 7:44 AM, Alain Péan <[log in to unmask]> wrote:
> Le 17/12/2014 23:27, Mark Stodola a écrit :
>>
>> I think the answer to that is no.  The SL team made a decision to continue
>> to spin their own independent set of packages and not become an add-on
>> repository to the CentOS build.
>>
>> Someone please correct me if I am wrong...
>
>
> Yes, but the RHEL source srpms packages are now (RHEL 7) on a CentOS git
> repository, where RedHat put them, but without any signature to authentify
> them...
> https://git.centos.org/project/rpms
>
> See :
> http://lwn.net/Articles/603865/
>
> So SL will rebuild the CentOS SRPMS (perhaps, certainly, not in the same
> way)...
>
> Alain

It's a problem. The new git structure at git.centos.org, rather than
directly using RHEL signed SRPM's, does create a provenance problem.
They seem to hve been good about it, and some of their core members
are now Red Hat employees, and this is now the official software
channel, and that's all re-assuring. But there's a notable difference
between "here is the source tree which someone labeled as using the
word 'import' in the git commit messages', and "this is the signed
SRPM that was built with mock or koji when I compiled the actual
software, and which is signed with the same key at the same time".

I've suggested using git tags, and GPG signatures on them instead, on
several occasions. This would help ensure that the repo, and copies of
the repo, are never edited and corrupted. Without that, the system is
vulnerable to a man-in-the-middle attack with a signed, though
fraudulent, SSL keys because SSL signature authorities have been
compromised at least once that we know of. And the "git.centos.org is
secure and has an SSL key" is irelevant if someone is cloning or
rsyncing parts of it for local development. Ensuring that that
particular part of the software is, in fact, what the main repository
has is quite awkward and expensive in time and network resources.

I'm actually fairly miffed at their insistence that "oh, we'll denote
which is the build version of the source code by interpreting git log
messages in a unique way that no one else in the world does" rather
than using the built-in and GPG signable git tags.