warning to list

Matias Féliciano feliciano.matias at free.fr
Mon Oct 25 08:46:55 UTC 2004


Le lundi 25 octobre 2004 à 03:37 -0300, Alexandre Oliva a écrit :
> On Oct 25, 2004, Ian Pilcher <i.pilcher at comcast.net> wrote:
> 
> > I must admit that I don't understand why its even *possible* for an
> > unsigned package to make its way into any official up2date repository.
> 
> rawhide isn't an up2date repository.

So ?
yum/apt repository <=> poor repository ?
Do you mean that RHEL does not have its owner Rawhide during beta
cycle ?

>   It's just a dump of the latest
> builds of every package in the Red Hat build system

To be honest, I am not surprised :-)

> , started by cron
> at a fixed time in very early morning when there's nobody around to
> sign packages that developers hacked on all night.  Sure enough, one
> could add an automated signature to such packages, but this only means
> such a signature would be worth nothing,

Signed rpm mean : You can verify the "origin" of the package.
Not more !
This signature is perfect :
pub  1024D/1CDDBCA9 2003-10-27 Fedora Project automated build signing key (2003) <rawhide at redhat.com>

>  for being generated with a
> key not protected by a passphrase, stored on a box not exactly secure.

Sorry, but it's Red Hat/Fedora concern.
I am surprise to learn that Red Hat is not able to set up a secure box
only to automatically sign package.
You can not say "signed rpm is not valuable" because "build server is
not secure".
Add to your TODO list :
- first : Secure build server
- second : Add an automated signature

Selinux without rpm signed isn't worth. Does this mean SeLinux is not
valuable ?

Without signed rpm, *each* mirror can content a trojan ...
Each mirror should be secure.
With signed rpm, _only_ the build system should be secure.

Arguing that a gpg key can be "steal" does not mean that the use of gpg
is not valuable.

AFAIK, all beta packages of RHEL are signed. Why it's valuable for RHEL
to have signed packages and not for Fedora ?
Why Red Hat take more security attention for RHEL testers than for
Fedora testers ?
gpg is not a QA. gpg is "only" for security and authentication propose.

> E.g., if the automated rawhide build procedure could get into it to
> sign packages, without any password-protected authentication, what is
> this signature worth?

Do you mean that when package are "manually" signed they are carefully
checked ?
Is there someone here requesting for signed rpm _only_ if they are
carefully checked ?
No.
I want rpm signed packages to use confidently mirrors. Not more.

> 
> > Common sense would seem to dictate the use of some type of simple script
> > to move packages from a "staging" directory into the repository; signing
> > the package should be part of this process, not something that Red Hat
> > developers have to do manually.
> 
> 'fraid your common sense is not in line with common sense in terms of
> good security practices.
> 
> 
> Sure enough, the rawhide build could refrain from using unsigned
> packages, but the point of rawhide is to provide people with the
> latest packages for testing.  The 24-hour turn-around time is
> sometimes too long already; adding the need for one of the few people
> who actually have access to the signing keys to be around to sign them
> would probably just increase the turn-around time.  You just can't
> have it both ways.  (ok, you could: there could be one repository with
> only signed packages, and one with the really latest stuff even if
> unsigned, but...  36GB/day is bad enough)
> 
> -- 
> Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
> Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
> Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20041025/4b0ea16b/attachment.sig>


More information about the fedora-test-list mailing list