On Fri, Jun 27, 2014 at 6:00 PM, Mark Rousell <[log in to unmask]> wrote:
> Apologies for starting a new thread but this seems to warrant one.
>
> On another mail list where the issue of Scientific Linux versus RHEL7
> has been mentioned in passing, an employee of Red Hat has offered to
> seek clarification about the RHEL/CentOS source code
> identification/verification/tracing issue with git.centos.org.
>
> Here is the passage (written by me) that the Red Hat employee intends to
> pass on for clarification if I take up his offer:
>
>         The problem with the source available via Git is that, whilst
>         no one doubts it is all there, it is apparently not currently
>         clear to anyone outside of Red Hat or CentOS what is the
>         unadulterated Red Hat source and what is source altered by
>         CentOS for its own build. It is not for nothing that the
>         source is now only being made publicly available via
>         git.centos.org and not directly from Red Hat. Third parties
>         such as Scientific Linux (and of course Oracle...) need to know
>         what is the unadulterated Red Hat source to be able to build
>         properly.
>
>         I understand that discussions are continuing to which I am not
>         privy but if you can shed light on how to unmistakeably extract
>         guaranteed Red Hat (rather than possibly altered-for-CentOS-
>         distribution) source code from git.centos.org then I
>         am sure the Scientific Linux community would love to hear about
>         it.
>
> He says:
>         I am very happy to seek clarification.
>
>         May I quote or paraphrase the above?
>
> Should I ask him to go ahead and seek clarification or should I tell him
> to drop it? Is it worth taking up his offer, given the email from
> CentOS-Devel written by Karanbir Singh and posted here by Yasha Karant
> at 13:49:12 -0700, which seems to me to possibly address these source
> code identification issues if I understand it correctly?

I'll assume you've seen my concerns about the provenance of code at
git.centos.org, ranging from the lack of clarity of how the original
import was done, to the potential vulnerability of the HTTPS based git
access to a forged SSL certificate used for a man-in-the-middle
attack. It's a real risk, especially for something as critical as
building operating system software.

I've dug further into the approach they're espousing for deducing the
SRPM builds available from the git repo, and for obtaining binary
SOURCE files such as tarballs, in the "centos-git-common" tree. It's
entirely reliant on the metadata they're publishing at the main
git.centos.org website. It's really aimed at a single threaded build
system, not at keeping a separate thread for upstream published code.
It *could* be tweeked. but would essentially involving setting up
parallel branches or even a parallel repository for nothing but pure
vendor code.

If they can address provenance, it's theoretically possible to publish
a slightly different metadata  file that would differentiate from the
"vendor" releases. But I'm afraid that this would require some
architectural rethinking.

And do not get me *started* on the "we'll put the non-text files in a
separate git repo, which also lacks GPG signed tags". It's adding to
the provenance risks.

> Would anyone like to craft a better phrased question than my own one
> above (which is just a quote from an earlier message in the thread with
> him)?

Boy. That's hard, at least for me.