SCIENTIFIC-LINUX-USERS Archives

June 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:
Lamar Owen <[log in to unmask]>
Reply To:
Lamar Owen <[log in to unmask]>
Date:
Thu, 19 Jun 2014 12:51:33 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
On 06/19/2014 10:37 AM, Dag Wieers wrote:
> On Wed, 18 Jun 2014, Lamar Owen wrote:
>
>> So, somewhat paradoxically, I would have a greater confidence in 
>> source from git than source from a signed source RPM, again due to 
>> git's design.  ...
>
> It depends of course who signs it.

First, Dag, it's good to hear from you again.  Glad to see you're still 
around, and glad to see some update activity of late.  You have a great 
perspective on all of this, having run a major third-party repo for 
years, and I appreciate your input in the discussion.

Secondly, I'll qualify your statement by doing a s/who/which signing 
key/g on it.  Any given entity may have multiple signing keys, and 
unless one has a subscription one cannot know that the public sources 
are signed with the same key that has signed the sources available with 
the subscription (to the best of my knowledge the public source RPM's 
are the same, but I have not personally checksummed all of the EL6 
source RPMS available publicly and compared against what's available by 
subscription).

> If the SRPM is signed by Red Hat, and the git commits are signed by 
> CentOS, you cannot really say that it is the same thing. One may claim 
> that it is the same thing, but only Red Hat can prove it for every 
> commit/SRPM.

Red Hat has confirmed in a public bugzilla comment ( 
https://bugzilla.redhat.com/show_bug.cgi?id=1109401#c13 ) that they are 
populating the git repos.  Yes, I would prefer it show as 'Red Hat 
Buildsys' and be signed as being from Red Hat, too.

>
> And that is a problem.

I agree that there is a problem, at least from one point of view. My 
take on it is that if you need the chain of trust to be that tight you 
need to pony up a subscription and get RHEL, because even with a good 
chain of trust for the source there are other problems. I won't speak 
for other points of view.  To date, the level of trust I have in both SL 
and in CentOS is pretty high and I use both; but if I had to pass a cert 
of some sort (PCI or similar), or I were to need to handle sensitive 
information (HIPAA or similar), I would budget for RHEL for that 
application.

>
> Your chain of trust becomes one piece longer, and we don't know what 
> that piece exactly entails.
>
No, we don't.  So I'm watching the process to see how things are going, 
and make my own decisions accordingly.  But I remember when rebuilding a 
Red Hat Linux from source required a really heavily modified system 
running something similar to beehive; we've come a long way.

It's always good to hear your perspective, Dag, and I hope you have a 
great day.

ATOM RSS1 RSS2