SCIENTIFIC-LINUX-USERS Archives

September 2014

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Wed, 3 Sep 2014 07:24:25 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
On Tue, Sep 2, 2014 at 5:21 PM, Patrick J. LoPresti <[log in to unmask]> wrote:
> On Tue, Sep 2, 2014 at 2:11 PM, Pat Riehecky <[log in to unmask]> wrote:
>>
>> The sources were taken from git.  They were then compared to the sources
>> from the public Release Candidate provided by upstream on April 22 2014.
>> There were very few changes from this Release Candidate to the official
>> release.
>
> Nice work.
>
>> All the Security/Enhancement/Bugfix code comes out of git as the source rpms
>> for these were never publicly released.
>
> Does this mean there is no way to correlate security/bugfix updates
> from Red Hat with the changes in git, and therefore no way to know how
> far SL is diverging from RHEL over time?

It can get messy, fast. One used to have to compare the SRPM's
directly. This was getting messier, and messier, especially as our
favorite upsteam vendor got weirder with kernel source packaging. So,
as long as we can be sure of the *provenance* of what is in
git.centos.org, and be sure that source there labeled as RHEL source
is, in fact, the original RHEL source, we should all be in good shape
for other distros.

What's scaring me is the lack of provenance there. There are no GPG
signed git tags for particular packager releases, and the 'let's
create git logs with the word 'import' to show with the revision that
shows our SRPM contents' is, well.... it's not stable. And 'git logs'
are easily added to a trojaned remote mirror, so you're forced to
manually ensure the provenance of your own repositories. If you do
development work, and work with modified code, you *need* your own
local git repos, and they will diverge from upstream.

> Is the git tree entirely RHEL + released updates, or are unreleased
> CentOS changes mixed in as well?

"Yes". More seriously, there's been no clear document I can find on
what the actual practices are. There *are* the various scripts in the
"centos-git-common" repository, used to interpret those 'git log'
entries I mentoned and derive what the maintainers at git.centos.org
think the relevant git revisions are for various SRPM builds.
Unfortunately, the correspondence is not one-to-one. There are
apparently already SRPM's that have no relevant 'git log' entries in
at least one package tree.

> Presumably, anyone with a RHEL subscription (and the right tools)
> could compare the git repository against the update SRPMs, at least to
> tell you whether they are the same. Would that be a violation of the
> subscription terms, I wonder?

It most certainly would be fine with anything "GPL" licensed, or with
any other sane license. And it was a subject of discussion when I
raised concerns about the security of the git.centos.org repositories,
and the possibility of trojaned man-in-the-middle attacks. (A secure
HTTPS server is not, in my opinion, enough. DNS can be and is poisoned
in attacks worldwide, proxies can be loaded with fake, signed SSL
keys, and now that they're discussing support for rsync mirrors, the
problem gets worse.)

The tools you might want for the local miror are at
https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel.sh.
And yes, you'd need a valid RHEL license, installed on a local host,
for each major release and/or architecture you want to mirror and
review.

> Just curious.
>
>  - Pat

ATOM RSS1 RSS2