[CentOS-devel] Latest builds are now online 2014-06-25_build 4

[Nico Kadel-Garcia]

On Fri, Jul 4, 2014 at 11:59 AM, Karanbir Singh <mail-lists at karan.org> wrote:
> On 07/02/2014 08:01 PM, Les Mikesell wrote:
>> On Wed, Jul 2, 2014 at 1:31 PM, Manuel Wolfshant
>> <wolfy at nobugconsulting.ro> wrote:
>>>
>>>> On Wed, Jul 2, 2014 at 9:40 AM, Karanbir Singh <mail-lists at karan.org>
>>>> wrote:
>>>>>
>>>>> [1]: which we are not, since we always try and match 1:1 with
>>>> upstream
>>>>> release media
>>>>
>>>> If you aren't consuming upstream src rpms from their repositories any
>>>> more, will you still actually know that you have a 1:1 match?
>>>
>>> We consume the same sources as before. Just that instead of being pushed by RH to the world as src.rpm we have the content (still pushed by RH !)  already exploded. Incidentally this happens in a convenient git environment.
>>
>> I don't understand how that relates to the upstream release packaging,
>> though. Is there a way to distinguish something included in a future
>> 7.1 release and a subsequent 0-day update?  Or do you have to check
>> the package versioning against their release?
>>
>
> All the content went into a single directory earlier as well, now its
> git. and the distro is still '7'
>
> I think one issue that is clear is that lots of people were working
> under or just assuming context that never existed, because either its
> not something they interacted with -or- they didnt need to.
>
> nutshell: git.c.o has the same content, in an easier to consume manner
> and an easier to track and trace format.

I've been gone for a while, and am back for now. I've been going over
this, and no, it's not easier to manage or consume.

A full local build, or even maintaining a local mirror for content
review, requires tracking over 3,000 distinct git repositories,
without an automatic "grab the lastest version" or "mirror all this
content locally" as was available with "yum", "wget", or "rsync", or
"reposync" pointing to any of hundreds of public RedHat or CentOS
mirrors. It makes git.centos.org itself a single point of failure in
the build system, and the lack of verification of the individual
builds puts "consumers" at the risk of various man in the middle
attacks. And with each repository having a *separate* report of that
the available builds are, rather than an easily reviewed master list,
it's an extra layer of complexity.

I'm sure it's easier to track and trace git.centos.org if you wrote
the system and evolved your tools to cope with it. But it's not easier
then the formally workable 'yum list --disablerepo=*
--enablrepo=[sourcerepo" comman, or using "reposync" to keep a
relatively small repository of only the latest SRPM's. And *those*
packages had verifiable GPG checksums, so they could be verified even
if they came from a local mirror. Also, my working assumption is that
those SRPM's had all the source and patches that actually went into
the software build.

I don't believe that either RHEL nor CentOS do this, but I'm
encountering way too many SRPM's that *exclude* source material
depending on the local configuration options. I'm also encountering
way too many SRPM's that dynamically download source content as part
of the build process. Do not get me *started* on Perl packages that
run 'cpan' as part of their build process, to resolve their
dependencies at build time, and the steps needed to prevent that when
making clean SRPM's!!!! In such cases, and to deduce such cases, it's
very helpful to have the actual SRPM used at compilation. Not the git
repo, the git repo is also potentially cluttered with files that are
*not* in the SRPM, material such as the ".[package].metadata". That
file, for example, is a git.centos.org repository artifact and never
makes it into the SRPM, near as I can tell.

One solution to help with the security concerns is to use 'git tags',
GPG signed, to indicate the  available SRPM source trees, rather than
relying purely on reports generated from git logs. I've already
mentioned elsewhere that the "show_possible_srpms.sh" script is
vulnerable to the accidental use of the word "import" in other logs,
such as the word "important", and will produce spurious reports if it
does not sanitize its inputs better. Hey, point me to the relevant
bugzilla, I'll happily submit a patch for that!

Anyway: git tags would would ease the security concerns I've been
raising elsewhere and am now raising here:  with the verified theft of
signature authorities from "GlobalSign", and other unreported
certificate thefts and abuse of local proxies to manipulate local
signature authorities, SSL is simply not trustworthy enough. Red Hat
and CentOS can be completely rigorous and reliable in their own SSL
certificate handling, but there are too many man-in-the-middle ddle
risks to rely on just SSL for something as critical as production
source code.

That's actually an issue for the new CentOS 7 daily builds, as well,
but it's a sufficiently separate matter. That has, I hope, been
discussed elsewhere.