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.