Proposal: Discourage rpmbuild --sign

[Michael Schwendt]

On Wed, 31 Dec 2003 02:42:28 -1000, Warren Togami wrote:

> Proposal
> ========
> rpm-4.2.2 in rawhide and all future versions should discourage the use 
> of rpmbuild --sign.  Perhaps this can be done effectively by adding a 
> large and annoying warning message and 15 second delay.  Or disable it 
> completely.  I don't care how, just discouragement should be done.
> 
> Why?
> 
> By allowing rpmbuild --sign to be not annoying, then people tend to 
> think that it is the proper way to build and sign packages.  This is 
> totally not the case for one key reason: Safety.
> 
> It is possible, however unlikely, that trojans hiding within SRPMS that 
> you build could steal your GPG keys since they are running as the same 
> user as the GPG signing keys.  They have access to memory used by gnupg, 
> as well as access to the files in ~/.gnupg.  The passphrases can be 
> stolen, or the files themselves stolen and passphrase cracked.  (It is a 
> lot easier to crack a passphrase when you have both the private and 
> public key.)

This is an over-ambitious proposal. How do you want to prevent users from
test-driving a built binary rpm with their normal user account where the
malicious software has access to many other security relevant data?

People don't build src.rpms for fun. They build them to install the built
packages as root (!) and then to use them from within their normal user
account.

Instead of crippling rpmbuild, better educate the users and developers and
establish a good packaging practice for the Fedora Project, in particular
Fedora Extras/Alternatives and so on. Where you see mistakes in a spec
file, contact the packager. Where a Makefile requires root privileges to
install files, talk to the developers.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031231/ac5c1ffc/attachment.sig>