|
Message-ID: <20020807094042.GO17880@blue.alter.pl> Date: Wed, 7 Aug 2002 11:40:43 +0200 From: Radoslaw Stachowiak <radek@...er.pl> To: owl-users@...ts.openwall.com Subject: Re: gpg rpm signing - auto upgrade *** Solar Designer <solar@...nwall.com> [Tuesday, 06.August.2002, 20:53 +0400]: > Owl-current for i386 is constantly built on a network-connected box, > so signing it with the same key is probably not a good idea (it would > both risk leaking the private key that is also used for more secure > things and provide a false sense of security). > I should probably generate a separate key pair that could be used to > sign everything that gets to our FTP feeds and could thus be used to > check integrity of copies obtained via the mirrors. That'd be similar > to what is used for *.kernel.org. Thats reasonable. What I suggest is separate key pair for automated signing, which is signed by Your master key. Of course it should be also published on website/pgp servers. [..] > This is not to say that we'll never provide RPM embedded signatures. > We may do so just because the functionality is there. But their use > will remain deprecated, in favor of mtree. as for me, there is no problem if its mtree or rpm signatures, so Your arguments (rpm security) make sense and just go for mtree. what I see now at mirrors are mtree files but no signatures, so looks like that tool/scripts for mtree automated signing after builds is needed (?). (especially file: /pub/Owl/current/i386/i386.mtree) And while it needs some work, I think that also adding line 'rpm --sgin package' (and correct .rpmrc settings for key) is easy and wont do any harm, while it can be benefit at some point (rpm code reviewed and fixed) - besides rpms are much more recognized and also used. For example i use some rpms from Owl in other distributions. > > 1. fetch rpm files (e.g. use mirror command from lftp) > > 2. check signatures (rpm --checksig) > > 3. use rpm -F --test *rpm - to test for conflicts/broken deps > > 4. do upgrade -F (without --test) or just email admin list of (already > > fetched and verified) packages ready to upgrade. > This is reasonable, except that step 2 should use mtree and step 4 > should require manual approval. (The upgrade should preferably be > done at a time when the availability of the system isn't critical.) i can prepare this simple script for wider use (after mtree clarifications) - but rather every admin can create it in 5mins. -- radoslaw.stachowiak.........................................http://alter.pl/
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.