Re: Request for Help: apt 0.6
Martin Schulze <[EMAIL PROTECTED]> writes: > | - key management, > > - are able to review the key management part and > - design and discuss this with the release team > - (re-)design and discuss package updates and security updates > - take into account that the archive key is rotated yearly Hi, I just wanted to mention that the key management affects more than just apt. Some partial mirror scripts also do Release.gpg verification to guard against intrusion. To name two: reprepro maintained by Bernhard R. Link currently in queue/NEW and debmirror which I maintain. It would be nice if they could also get key updates from the same management system. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
* Martin Schulze: > Even though this will probably work well on a small scale, it won't on > a large scale. Just think about the installations of 500 or 1000 > Debian machines that also have security support. This is not > hypothetical. These installations do exist. You don't want to > install a new key manually on them. In this context, "manual" means "invoke apt-key to remove the old key and add the new one". This isn't much different from invoking apt-get (or pushing any other scripted change to the machines). Do you think it's still a problem, even if you take apt-key into account? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
Florian Weimer wrote: > * Henrique de Moraes Holschuh: > > You still need to deal with key revocation and a new key being needed, > > anyway. Yearly changes will not make it more difficult, it will make sure > > those codepaths are tested (and used at least once an year). > I can understand that in an ideal world, there would be a master key > stored off-line which would be used to sign (and revoke) the release > keys. In case of a compromise, the master key can be used to > introduce a new release key (without intervention by the system > administrator). > > But I doubt this is really necessary. If the release key is > compromised, a DSA would have to be released anyway. This advisory > would include the necessary steps to remove the compromised key from > the system. Do we really need to automate this? > > You could even argue that the scheme without a master key is more > secure because the number of trusted parties is smaller, and no one > can introduce a new release key in a covert manner. It boils down to > what we are trying to secure. AFAICS, the main risks are network > layer attacks on the user and mirror breaches. Easy recovery from a > compromised archive infrastructure shouldn't be a top priority, and it > might well be impossible if the attack was successful (the "single > point of ownership" problem). Even though this will probably work well on a small scale, it won't on a large scale. Just think about the installations of 500 or 1000 Debian machines that also have security support. This is not hypothetical. These installations do exist. You don't want to install a new key manually on them. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
martin f krafft wrote: > also sprach Martin Schulze <[EMAIL PROTECTED]> [2005.02.14.1851 +0100]: > > We need help by competent developers who work on apt 0.6 with the goal > > to get it supported properly and eventually enter sid and sarge. > > Thank you, Joey! > > For the record, I am too strung up right now to be any use in > coordinating this. However, I will help out. Thanks. > > - take into account that the archive key is rotated yearly > > Why? What argument is there against a per-release key, including > keys for security, testing, unstable, and experimental? It would > certainly make things a little easier... See what I wrote in the line above the one you quoted: | - design and discuss this with the release team I didn't make this decision. It has been common practice on the Debian archive for a number of years though. There are pros and cons for using a yearly key and a key that lasts for an entire release. However, - if anything should be changed from the current situation, the ftpmaster (and release team) need to be involved and - if not a solution needs to be established to distribute the key other than by aj sending a mail to debian-devel with the location of the new key. Regards, Joey -- Open source is important from a technical angle. -- Linus Torvalds Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
Quoting Martin Schulze ([EMAIL PROTECTED]): > Moin, > > We need help by competent developers who work on apt 0.6 with the goal > to get it supported properly and eventually enter sid and sarge. > > There is a good chance the release will happen before the issues with > apt 0.6 are resolved, so this may be a task that cannot address sarge > in time but only etch and following distributions. Contributors > should be aware of this. The effort on getting it as translated as 0.5 is (27 complete languages) is on its way, so PLEASE do not change messages which are outputted to users without saying so in the APT development list. I also have a patch for bringing some consistency in the way APT uses capitalization in its output. It Seems That Too Many German Developers Wären Involved In It...:-) (kidding you, people, no offense intended to people who indeed made great job). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
* Henrique de Moraes Holschuh: > You still need to deal with key revocation and a new key being needed, > anyway. Yearly changes will not make it more difficult, it will make sure > those codepaths are tested (and used at least once an year). Right now, it's not codepaths, but system administrators. 8-> I can understand that in an ideal world, there would be a master key stored off-line which would be used to sign (and revoke) the release keys. In case of a compromise, the master key can be used to introduce a new release key (without intervention by the system administrator). But I doubt this is really necessary. If the release key is compromised, a DSA would have to be released anyway. This advisory would include the necessary steps to remove the compromised key from the system. Do we really need to automate this? You could even argue that the scheme without a master key is more secure because the number of trusted parties is smaller, and no one can introduce a new release key in a covert manner. It boils down to what we are trying to secure. AFAICS, the main risks are network layer attacks on the user and mirror breaches. Easy recovery from a compromised archive infrastructure shouldn't be a top priority, and it might well be impossible if the attack was successful (the "single point of ownership" problem). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
On Mon, Feb 14, 2005 at 08:04:51PM +0100, Peter Palfrader wrote: > A similar 2 key system is probably a good idea for security, and maybe > also for the normal rotated keys (just ship 2005 and 2006 keys now). i think having two keys would make logistics a lot simpler for release upgrades, assuming we had a system that mandated valid gpg signatures. like you suggest, only use one of the two keys, and additionally have the backup key's secret stored offline in a safe place (does SPI have a lock box or safe deposit box we could use?). when it comes time for a new release, or if there is a serious security breach, et c, the new key could be brought out, used to sign a new backup key (which would be placed back in the lockbox), the package providing the key could be updated, and life could happily go on. sean -- signature.asc Description: Digital signature
Re: Request for Help: apt 0.6
also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2005.02.14.1933 +0100]: > You still need to deal with key revocation and a new key being > needed, anyway. Yearly changes will not make it more difficult, > it will make sure those codepaths are tested (and used at least > once an year). I am not sure a key needs to be revoked, it should just have an expiry that forces us to release in time. :) Do we have code paths for certificate management? In that case, I wonder why it took so long this year... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Request for Help: apt 0.6
On Mon, 14 Feb 2005, Henrique de Moraes Holschuh wrote: > > Why? What argument is there against a per-release key, including > > keys for security, testing, unstable, and experimental? It would > > certainly make things a little easier... > > You still need to deal with key revocation and a new key being needed, > anyway. Yearly changes will not make it more difficult, it will make sure > those codepaths are tested (and used at least once an year). It's probably a good idea to create 2 sarge release signing keys, and include them with the package. Use the first to do everything, and secret split the second key to n trustworthy developers (k of n split). Should key #1 get compromised somehow, the backup-key is assembled and used to sign the Release file from now on. One of the first updates would probably be the introduction of a new backup key, now that the old one has been promoted to primary. A similar 2 key system is probably a good idea for security, and maybe also for the normal rotated keys (just ship 2005 and 2006 keys now). -- PGP signed and encrypted | .''`. ** Debian GNU/Linux ** messages preferred.| : :' : The universal | `. `' Operating System http://www.palfrader.org/ | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
On Mon, 14 Feb 2005, martin f krafft wrote: > also sprach Martin Schulze <[EMAIL PROTECTED]> [2005.02.14.1851 +0100]: > > We need help by competent developers who work on apt 0.6 with the goal > > to get it supported properly and eventually enter sid and sarge. > > Thank you, Joey! > > For the record, I am too strung up right now to be any use in > coordinating this. However, I will help out. > > > - take into account that the archive key is rotated yearly > > Why? What argument is there against a per-release key, including > keys for security, testing, unstable, and experimental? It would > certainly make things a little easier... You still need to deal with key revocation and a new key being needed, anyway. Yearly changes will not make it more difficult, it will make sure those codepaths are tested (and used at least once an year). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Help: apt 0.6
also sprach Martin Schulze <[EMAIL PROTECTED]> [2005.02.14.1851 +0100]: > We need help by competent developers who work on apt 0.6 with the goal > to get it supported properly and eventually enter sid and sarge. Thank you, Joey! For the record, I am too strung up right now to be any use in coordinating this. However, I will help out. > - take into account that the archive key is rotated yearly Why? What argument is there against a per-release key, including keys for security, testing, unstable, and experimental? It would certainly make things a little easier... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Request for Help: apt 0.6
Moin, We need help by competent developers who work on apt 0.6 with the goal to get it supported properly and eventually enter sid and sarge. There is a good chance the release will happen before the issues with apt 0.6 are resolved, so this may be a task that cannot address sarge in time but only etch and following distributions. Contributors should be aware of this. Quoting Andreas Barth from the release team: | Actually, we discussed about apt 0.6 within the release team and | with the maintainers. IIRC, the two blocking issues are: | | 1. All the concepts | - default installation, | - key management, | - how do security updates work | - ... | need some review | | 2. There is noone who started working on 1. | | (One part of 2. is that nobody made a summary after discussion, as | there is 2.) Hence, there are developers needed who: - are able to review apt 0.6 - are able to review the key management part and - design and discuss this with the release team - (re-)design and discuss package updates and security updates - take into account that the archive key is rotated yearly It would be a large step forward if sarge could include apt 0.6, so here is a chance to help improve sarge a lot. Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
