Re: State of the debian keyring
gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. (Also, my keyring update request has been waiting for 3 weeks now to be processed.) -- ciao, Marco -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lec9ll$hlh$1...@posted-at.bofh.it
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 06:35:06PM -0600, Gunnar Wolf wrote: Kurt Roeckx dijo [Sun, Feb 23, 2014 at 12:46:41AM +0100]: For those people who are not aware of this yet, this is really a problem. I agree. We should take security in Debian seriously. Getting weak keys replaced by strong ones in the keyring in time, keeping up with increasing computer power, is part of that. This provides less security than an 80 bit symmetric cipher. A brute force for this is possible. It's considered to have very short time protection against agencies, short time against medium organisations. That's still 61.5% that's at 1024 bit. CAs are doing better than this, with only 0.8% of the certificates that are still active being 1024 bit. Can I suggest that everyone that is still using a 1024 bit pgp key generates a new key *now*? Yes please, *now*. The recommended minimum size is at least 2048 bit, but I suggest you go for 4096 bit. ...And now hat you mention this here on the list, we have been discussing how to deal with this for keyring-maint¹. It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. In my opinion it would clearly be unacceptable for us to allow the weak keys in the keyring for a day longer. How about removing them now. Also, removing those keys would most probably make our WoT much more fragile. The WoT is already fragile due to the weak keys. Also, removing the weak keys from the keyring doesn't weaken the WoT because all keys still exist in public. I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? Contacting them can obviously be done via e-mail. Note that if they are still active DDs they should already be aware of the weakness of the keys. Let's get real on this, see the age of this message [0], a message all DDs should have read at the time. I understand however practical challenges for DDs living in remote areas for getting keys signed. [0] : https://lists.debian.org/debian-devel-announce/2010/09/msg3.html How can we incentivate them to change? As I wrote above, by removing the weak keys now. Remember that, in order to get a new key accepted, a big hurdle is sometimes the need for meeting two people with active keys. Several people have started the process to update their keys, but after months (and no real possibility to meet a DD in person) have let it stay as it is. This hurdle is, of course, very important to maintain in order to avoid loosening our identity requirements... So, what do you suggest? DDs with strong keys can help the locked out DDs with key signing [1] and with temporarily sponsoring important/urgent packages uploads [2]. I'm hereby offering this help myself now. [1] : https://wiki.debian.org/Keysigning/Offers [2] : http://mentors.debian.net/intro-maintainers Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223080943.ga11...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. No, because this would reduce the value of the new keys to the weakness of the 1024 bit keys. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223081228.ga1...@master.debian.org
Re: State of the debian keyring
Hi, Bart Martens: On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. No, because this would reduce the value of the new keys to the weakness of the 1024 bit keys. That's somewhat true for now given a sufficiently-motivated attacker, but if *afterwards* some nefarious $CENSORED gets the idea that $DD would be a nice target for hacking their key, they'd be out of luck. They'd also be out of luck if the DD's new key happens to already exist (which the DD who's asked to sign the new key should obviously check). Thus I would add the new key provisionally; if it doesn't get any new signatures from DDs with non-provisional strong keys during, say, the rest of this year, then delete it from the keyring. This would still be more secure than waiting a year before disabling the old keys, and come 2015 there would be no difference. However, I see another problem. http://keyring.debian.org/replacing_keys.html states that, if Alice wants to get her key X replaced with key Y, Alice must get a Debian developer […] to sign a message requesting the replacement of key X with key Y on behalf of Alice … which IMHO is an unnecessary burden if Alice's old and new key are valid and sufficiently DD-signed. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 10:23:47AM +0100, Matthias Urlichs wrote: Hi, Bart Martens: On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. No, because this would reduce the value of the new keys to the weakness of the 1024 bit keys. That's somewhat true for now given a sufficiently-motivated attacker, but if *afterwards* some nefarious $CENSORED gets the idea that $DD would be a nice target for hacking their key, they'd be out of luck. They'd also be out of luck if the DD's new key happens to already exist (which the DD who's asked to sign the new key should obviously check). We don't know which 1024 bit keys may already have been compromised, so you would not know which new keys would be compromised as well. Thus I would add the new key provisionally; I don't see the point in provisionally adding potentially compromised keys. if it doesn't get any new signatures from DDs with non-provisional strong keys during, say, the rest of this year, then delete it from the keyring. I see no reason to allow more time, since we have been talking about 4096 keys since 2010. This would still be more secure than waiting a year before disabling the old keys, and come 2015 there would be no difference. A 4096 bit key is cryptographically stronger than a 1024 bit key, but the point of key signing is about verifying who is holding the private key. However, I see another problem. http://keyring.debian.org/replacing_keys.html states that, if Alice wants to get her key X replaced with key Y, Alice must get a Debian developer […] to sign a message requesting the replacement of key X with key Y on behalf of Alice … which IMHO is an unnecessary burden if Alice's old and new key are valid and sufficiently DD-signed. I suggest to discuss that in a separate thread. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223095620.ga16...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm not sure what you're saying, but I think it's a bad idea. What I would find acceptable is that if you generate an new key you sign the same keys with the new key that you signed previously with the old key. I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. If they old key doesn't get revoked there is still a (weak) web of trust. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. I see no good reason to sign new keys without meeting the person to confirm that that is their new key. You seem to suggest that that is a good idea to keep the web of trust, but to me it seems you just create a web of trust that isn't really there. What we need is a way to confirm that you're talking to the same person you've met previously and confirm that that is his new key. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223112858.ga13...@roeckx.be
Re: debian as unix
On Sun, Feb 23, 2014 at 01:05:31PM +0700, tre mor wrote: Debian 7.2 is conform with the Posix.1-2008/SUSv.4? If not, when will be? If you mean will it be 100% conforming, my guess is never. It's a pretty broad standard and reasonably out-dated. Debian is also dependent on what upstreams do or don't do. The bits I've looked into are the utilites, because that's the space I play in. I can tell you that nothing is 100% compliant, but we don't go out of our way to not be either. As a guideline its ok, but for my area that's about it. That doesn't mean there are other parts of the standard that are completely awesome; I just don't read those parts. - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223114346.gb6...@enc.com.au
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 02:10:12PM +0800, Paul Wise wrote: On Sun, Feb 23, 2014 at 8:35 AM, Gunnar Wolf wrote: So, what do you suggest? Set a deadline (say 1 year?) for removal of all 1024 bit keys from the keyring. Notify all users of 1024 bit keys via all addresses listed in the MIA db and all UIDs on those keys. Remind people that coming to DebConf is a great way to get signatures. Talk to the DPL about spending Debian funds to help push this along. At the deadline, move all Debian members still using 1024 bit keys who responded to emeritus status and everyone else to disabled. I have been meaning to sit down a write a proposal for the removal of our weaker keys, and run it by Gunnar and Daniel before wider distribution. Part of my reticence is the knowledge that we're going to have to do 600 key replacements and it probably works out to at least 5 minutes per key change. Which is at least 50 hours of work, assuming the requests are all well formed and we don't need to go repeating ourselves about how to submit key change requests. In an attempt to try and reduce problems let me describe some of the problems we see (all of this is in the context of someone taking an existing key that is not believed to be compromised and replacing it with a stronger key): * Requests must be inline signed (gpg --clearsign). Unfortunately RT will mangle PGP/MIME signatures which means we can't verify them. (it will also decide to re-encode email in utf-8, which causes issues for people with non ASCII characters in their .sigs or names, but this is a much less frequent issue) * Requests need to include the full fingerprint of both the old and the new key. Not just the key IDs. Not just the new key. We want to be absolutely certain of what you're requesting replaced. I quite like seeing the actual gpg --fingerprint output for both keys because it tends to be quite easy to visually verify. * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. * The request must be signed by the old key. Signing the request with the new key alone is not helpful - requests must always be signed by a key that is currently in the active keyring. Signing it with both is fine, but not required. * You should specify *why* you want to replace your key. Knowing that it's because you're moving to a stronger key rather than because your old key is compromised / unavailable / on fire helps us prioritise things. The time frame I'd had in mind was 6 months until we disable 1024 bit keys in the keyring, then perhaps a 3 month grace where we'll allow change requests to be signed by those disabled keys, then treat them as completely untrusted. At this point that would mean that post DebConf we'd do the disabling, and then by the end of the year we'd be 1024 bit free. I know that there are various people who have held off on submitting updated keys until they get more signatures. I believe I've already said it elsewhere, but at this point if you have 2 signatures from other DD keys on your new key you should be sending a request for replacement to keyr...@rt.debian.org (with something like Debian RT - Key replacement request for debianusername in the subject) following the above guidelines. J. -- xmpp:nood...@earth.li Most people are descended from apes. Redheads are descended from cats. signature.asc Description: Digital signature
Re: State of the debian keyring
Jakub Wilk dijo [Sun, Feb 23, 2014 at 02:29:22AM +0100]: It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. Also, removing those keys would most probably make our WoT much more fragile. I'd like to ask the project as a whole for input on how we should push towards this migration. A few of 1024 keys have been expired for more than a year. I bet more of them are unused. Perhaps a WAT run would help a bit? Important data point we should not let go. I'm opening a RT ticket so we as keyring-maint look more into this and take action. Thanks! -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223144054.ga32...@gwolf.org
Re: State of the debian keyring
Marco d'Itri dijo [Sun, Feb 23, 2014 at 07:57:43AM +]: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm open to that if and only if the new keys have proper transition statements. And if the original signatures were *really* done carefully - Case in point, I took part of (too?) many massive key signing parties with my old 8BB527AF (1024D) key. Particularly, the DC5 to DC7 parties were mind-numbingly long, and the DC6 one was where Martin Krafft lit an interesting and important flame by *proving* most of use were not careful enough when checking identity papers. Since my key transition to 4096R, I only sign to people I can personally identify. And even so, I am certain several of the keys I signed in 2009/2010 were to people I would probably not recognize today (my face-to-name retention is quite deffective). So, no, I don't usually sign keys even where transition documents ask me to do so. (Also, my keyring update request has been waiting for 3 weeks now to be processed.) Right. We (keyring-maint) usually work by batching requests and spending some consecutive time on them. Our usual timeframe is once a month, and it is due this next week. So, don't feel forgotten, we will act on your request. signature.asc Description: Digital signature
Re: State of the debian keyring
Matthias Urlichs dijo [Sun, Feb 23, 2014 at 10:23:47AM +0100]: That's somewhat true for now given a sufficiently-motivated attacker, but if *afterwards* some nefarious $CENSORED gets the idea that $DD would be a nice target for hacking their key, they'd be out of luck. They'd also be out of luck if the DD's new key happens to already exist (which the DD who's asked to sign the new key should obviously check). Thus I would add the new key provisionally; if it doesn't get any new signatures from DDs with non-provisional strong keys during, say, the rest of this year, then delete it from the keyring. Our tools (and I don't only mean keyring-maint, but our projectwide tools) support only one key per person. And frankly, I do not see a case where adding a second one would increase security. Yes, it could make the transition a little bit easier, but I don't think it is a change we should push. (Or maybe I misunderstood your suggestion). However, I see another problem. http://keyring.debian.org/replacing_keys.html states that, if Alice wants to get her key X replaced with key Y, Alice must get a Debian developer […] to sign a message requesting the replacement of key X with key Y on behalf of Alice … which IMHO is an unnecessary burden if Alice's old and new key are valid and sufficiently DD-signed. Well, it is a hurdle, but not an insurmountable one. If you have an active, valid key, you can just sign with your own key and get a new one in the keyring, as long as it has at least two DD signatures. That assures us your computer was not h4x0red in order to steal your identity and lock you out. Say, in this (usual) case, you and Alice can be the same party. Now, if you lost control of your key (say, stolen computer), as soon as we get notice, we will retire your key (and that's not subject to our usual one month cycle as I told Marco for a *regular* key replacement). In order to get your key signed, we need an already-authenticated Alice (an Alice with her key in the keyring) to produce the request. The new key must, of course, meet our standards — Must have two DD signatures on it. Note that it does *not* require Alice's signature to be on it. signature.asc Description: Digital signature
Re: State of the debian keyring
Kurt Roeckx dijo [Sun, Feb 23, 2014 at 12:28:58PM +0100]: (...) I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. If they old key doesn't get revoked there is still a (weak) web of trust. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. We have done this as an exception at some particular cases. But clearly treating it as an exception, not as the usual way to work. signature.asc Description: Digital signature
Re: State of the debian keyring
On Sun, 23 Feb 2014, Jonathan McDowell wrote: * Requests need to include the full fingerprint of both the old and the new key. Not just the key IDs. Not just the new key. We want to be absolutely certain of what you're requesting replaced. I quite like seeing the actual gpg --fingerprint output for both keys because it tends to be quite easy to visually verify. * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. * The request must be signed by the old key. Signing the request with the new key alone is not helpful - requests must always be signed by a key that is currently in the active keyring. Signing it with both is fine, but not required. * You should specify *why* you want to replace your key. Knowing that it's because you're moving to a stronger key rather than because your old key is compromised / unavailable / on fire helps us prioritise things. This is not what is written here: http://keyring.debian.org/replacing_keys.html Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. -- 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 debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223154937.ga28...@khazad-dum.debian.net
Re: State of the debian keyring
On Sun, 23 Feb 2014, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. (Also, my keyring update request has been waiting for 3 weeks now to be processed.) No. But they should try to sign all[1] keys they had signed with their old key (VERY BIG difference) for which the reason of the signature still remains valid. Anyone has a script to find out the full keyid of all keys that have been signed by a specific [full] keyid? [1] well, I'd skip signing anything below 2048R or expired, *and* require e-mail address verification to weed out expired UIDs somewat. -- 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 debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223155409.gb28...@khazad-dum.debian.net
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 12:28:58PM +0100, Kurt Roeckx wrote: On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm not sure what you're saying, but I think it's a bad idea. I agree that it's a bad idea. What I would find acceptable is that if you generate an new key you sign the same keys with the new key that you signed previously with the old key. If this is cross signing your own old and new keys, then there is, unrelated to the debian keyring, obviously nothing wrong with that. I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. I would not find this acceptable. I'm surprised you write this. Maybe I'm misreading what you meant. If they old key doesn't get revoked there is still a (weak) web of trust. This is true. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. I think we should use the exact same rules for replacing old keys by new keys as for adding new keys from newcomers. We should not lower the value of new keys by cutting corners. I see no good reason to sign new keys without meeting the person to confirm that that is their new key. I strongly agree with that. You seem to suggest that that is a good idea to keep the web of trust, but to me it seems you just create a web of trust that isn't really there. If your point is that the web of trust with the 4096 bit keys shouldn't depend on the existing web of trust based on the old 1024 bit keys, then I agree. I don't object against keeping the existing web of trust based on the 1024 bit keys, but one should realize that it is already weakened, regardless of how we introduce 4096 bit keys. What we need is a way to confirm that you're talking to the same person you've met previously and confirm that that is his new key. Exactly. We should not cut corners when replacing the 1024 bit keys by 4096 ones. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223162929.ga32...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 08:56:46AM -0600, Gunnar Wolf wrote: Marco d'Itri dijo [Sun, Feb 23, 2014 at 07:57:43AM +]: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm open to that if and only if the new keys have proper transition statements. I would never sign new keys based on transition statements. And if the original signatures were *really* done carefully Still never. :-) Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223164726.gb32...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 12:49:37PM -0300, Henrique de Moraes Holschuh wrote: On Sun, 23 Feb 2014, Jonathan McDowell wrote: * Requests need to include the full fingerprint of both the old and the new key. Not just the key IDs. Not just the new key. We want to be absolutely certain of what you're requesting replaced. I quite like seeing the actual gpg --fingerprint output for both keys because it tends to be quite easy to visually verify. * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. * The request must be signed by the old key. Signing the request with the new key alone is not helpful - requests must always be signed by a key that is currently in the active keyring. Signing it with both is fine, but not required. * You should specify *why* you want to replace your key. Knowing that it's because you're moving to a stronger key rather than because your old key is compromised / unavailable / on fire helps us prioritise things. This is not what is written here: http://keyring.debian.org/replacing_keys.html Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. Paragraph 2 on that page states: | If key X is still valid then Alice may sign the request using that key, | but must ensure key Y is signed by key X as well as at least 2 other | active Debian developers whose keys are in the keyring. What would you suggest as alternative wording which is clearer? J. -- Replace repetitive expressions by calls to a common function. This .sig brought to you by the letter M and the number 35 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223172214.gy27...@earth.li
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 04:29:29PM +, Bart Martens wrote: I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. I would not find this acceptable. I'm surprised you write this. Maybe I'm misreading what you meant. So maybe this wasn't clear, but I think that should be the exception and clearly not the default. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223183736.ga23...@roeckx.be
Re: State of the debian keyring
On 2014-02-23 17:22, Jonathan McDowell wrote: On Sun, Feb 23, 2014 at 12:49:37PM -0300, Henrique de Moraes Holschuh wrote: This is not what is written here: http://keyring.debian.org/replacing_keys.html Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. Paragraph 2 on that page states: | If key X is still valid then Alice may sign the request using that key, | but must ensure key Y is signed by key X as well as at least 2 other | active Debian developers whose keys are in the keyring. What would you suggest as alternative wording which is clearer? 2. Alice must sign a message with key X, requesting its replacement with key Y. That statement should contain key fingerprints and Debian login details. Key Y must be signed by key X as well as at least 2 other active Debian developers whose keys are in the keyring. If key X is no longer trustworthy (for example, revoked because it was lost or compromised) she must get a Debian developer (ideally not Bob) to make the request on her behalf; this developer must also have performed the appropriate checks to enable them to be comfortable signing key Y. The last sentence still isn't clear to me (or rather, its starting point in the original document is not); should the non-Bob developer also sign the key Y? Is it acceptable for this developer to be the second signatory on the new key, or does a third DD need to be involved? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/61997270efb21e1b1bf9244df2dab...@hogwarts.powdarrmonkey.net
Re: State of the debian keyring
Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. This was also my understanding when I read through this page. It was only just recently that I realised that the exceptional case was first and that the first statement of instruction 2 did not apply: 2. Alice must get a Debian developer (ideally not Bob) to sign a message requesting the replacement of key X with key Y on behalf of Alice. I know I got to the point of doing step 2 ages ago and, having read that requirement, put the rest of the process in the too hard basket. (jmw's suggested reordering of this paragraph helps a lot here) Can I also make a concrete suggestion that the document include a couple of commands to be run to help people know what information to include? We already know that DDs aren't as good with gpg as everyone would like them to be, so including the precise command will help a lot here and save them fighting through gpg documentation again (which is just another barrier to people actually doing this): `gpg --list-sigs 0xNewKeyId` in step 1 `gpg --fingerprint 0xOldKeyId` `gpg --fingerprint 0xNewKeyId` as a step 0 (and perhaps move the paragraphs that are after the steps into numbered steps) The suggestion of automating generating the output with a short script would work too, although it only wants to be a few lines long so that anyone can look at it and trivially understand what it is going to do. cheers Stuart (who has finally mailed RT for the key rollover and will soon find out if he has actually understood the process properly) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lee55v$6co$1...@ger.gmane.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 12:54:09PM -0300, Henrique de Moraes Holschuh wrote: Anyone has a script to find out the full keyid of all keys that have been signed by a specific [full] keyid? You could look here[0] or use keyanalyze yourself. [0] http://pgp.cs.uu.nl/mk_path.cgi?STAT=EE25DE3F1CDB0FE3STATS=statistics -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224010413.ga17...@scru.org
Additional keyring data
I've received some requests for information about hash algorithms
used in signatures and the potential impact of dropping 1024-bit
keys on connectivity.
The software used is graphviz 2.26.3-16.2, hopenpgp-tools 0.7, and the
attached script. All info represents only verified, unexpired V4
non-self signatures from keys in a self-contained set (that set being
either /usr/share/keyrings/debian-keyring.gpg or the concatenation
of /usr/share/keyrings/debian-{keyring,maintainers,nonupload}.gpg).
Hash algorithms used by signatures in current-dds:
9836 SHA1
3279 SHA256
6 SHA384
1790 SHA512
.
Hash algorithms used by signatures in current-everybody:
10958 SHA1
3921 SHA256
7 SHA384
2115 SHA512
.
Hash algorithms used by signatures in postdrop-dds:
1895 SHA1
2677 SHA256
6 SHA384
1559 SHA512
.
Hash algorithms used by signatures in postdrop-everybody:
2542 SHA1
3225 SHA256
7 SHA384
1860 SHA512
.
Connectivity in current-dds:
994 14911 Keys (stdin)
926 14904 Keys_component_0
1 0 Keys_component_1
1 0 Keys_component_2
1 0 Keys_component_3
1 0 Keys_component_4
1 0 Keys_component_5
1 0 Keys_component_6
2 2 Keys_component_7
2 1 Keys_component_8
1 0 Keys_component_9
1 0 Keys_component_10
2 1 Keys_component_11
1 0 Keys_component_12
1 0 Keys_component_13
1 0 Keys_component_14
1 0 Keys_component_15
1 0 Keys_component_16
1 0 Keys_component_17
1 0 Keys_component_18
1 0 Keys_component_19
1 0 Keys_component_20
1 0 Keys_component_21
1 0 Keys_component_22
1 0 Keys_component_23
1 0 Keys_component_24
1 0 Keys_component_25
1 0 Keys_component_26
1 0 Keys_component_27
1 0 Keys_component_28
1 0 Keys_component_29
1 0 Keys_component_30
1 0 Keys_component_31
1 0 Keys_component_32
1 0 Keys_component_33
1 0 Keys_component_34
1 0 Keys_component_35
1 0 Keys_component_36
1 0 Keys_component_37
1 0 Keys_component_38
1 0 Keys_component_39
1 0 Keys_component_40
1 0 Keys_component_41
1 0 Keys_component_42
1 0 Keys_component_43
1 0 Keys_component_44
2 1 Keys_component_45
1 0 Keys_component_46
1 0 Keys_component_47
1 0 Keys_component_48
1 0 Keys_component_49
1 0 Keys_component_50
1 0 Keys_component_51
1 0 Keys_component_52
1 0 Keys_component_53
1 0 Keys_component_54
1 0 Keys_component_55
1 0 Keys_component_56
1 0 Keys_component_57
1 0 Keys_component_58
1 0 Keys_component_59
1 0 Keys_component_60
2 2 Keys_component_61
1 0 Keys_component_62
1 0 Keys_component_63
.
Connectivity in current-everybody:
1208 17001 Keys (stdin)
1129 16991 Keys_component_0
1 0 Keys_component_1
1 0 Keys_component_2
1 0 Keys_component_3
1 0 Keys_component_4
1 0 Keys_component_5
1 0 Keys_component_6
1 0 Keys_component_7
2 2 Keys_component_8
1 0 Keys_component_9
1 0 Keys_component_10
2 1 Keys_component_11
1 0 Keys_component_12
1 0 Keys_component_13
1 0 Keys_component_14
2 1 Keys_component_15
1 0 Keys_component_16
1 0 Keys_component_17
1 0 Keys_component_18
1 0 Keys_component_19
3 3 Keys_component_20
1 0 Keys_component_21
1 0 Keys_component_22
1 0 Keys_component_23
1 0 Keys_component_24
1 0 Keys_component_25
1 0 Keys_component_26
1 0 Keys_component_27
1 0 Keys_component_28
1 0 Keys_component_29
1 0 Keys_component_30
1 0 Keys_component_31
1 0 Keys_component_32
1 0 Keys_component_33
1 0 Keys_component_34
1 0 Keys_component_35
1 0 Keys_component_36
1 0 Keys_component_37
1 0 Keys_component_38
1 0 Keys_component_39
1 0 Keys_component_40
1 0 Keys_component_41
1
Re: State of the debian keyring
On Mon, 24 Feb 2014, Clint Adams wrote: On Sun, Feb 23, 2014 at 12:54:09PM -0300, Henrique de Moraes Holschuh wrote: Anyone has a script to find out the full keyid of all keys that have been signed by a specific [full] keyid? You could look here[0] or use keyanalyze yourself. [0] http://pgp.cs.uu.nl/mk_path.cgi?STAT=EE25DE3F1CDB0FE3STATS=statistics Thanks. -- 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 debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224014955.gb8...@khazad-dum.debian.net
