Re: Updated Debian Developers Keyring
The keyring part isn't as easy. The problem is that the keyring isn't maintained collaboratively. jetring has been developed for exactly this use case, but I've heard (discussion on #debian-devel) that some people considered jetring a mess (I don't have details about specific problems though). jetring has some useful and interesting ideas, but the main complaint I'd have about it as a method of managing keyrings is that it takes on various roles that are already provided by the underlying VCS and this duplication makes it more complex than necessary. It also stores keys as their ASCII armoured versions, which I can see little benefit to. If you store keys as individual binary blobs then the process of assembling the complete keyring can be achieve with cat. jetring obviously works for the people managing the Debian Maintainer's keyring, but that doesn't mean that it'll work for everyone. J. -- Web [ Sorry for the inconvenience. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.23 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainers Keyring changes
On Fri, Nov 19, 2010 at 01:09:29PM +0100, Alexander Reichle-Schmehl wrote: Hi! For the New Debian Contributors section of the Debian Project News I usually look at the keyring change mails you send. However in the last report I noticed the following: abou.almonta...@sfr.fr Full name: Abou Al Montacir Linked key: E1870B62BFAB87447FEDE31A8F7274F307062A38 (formerly belonging to ma...@freepascal.org) (And several similar changes.) What are these changes about? As I see keys getting added and removed, maybe this is about Key being ex-changed? This is the first set of updates since keyring.debian.org started supporting updates to Debian Maintainer keys via HKP, so various DM keys have had sigs/subkeys/uids added to them as a result. http://bzr.debian.org/scm/loggerhead/keyring/debian-keyring/annotate/head:/debian/changelog is probably a better way of seeing what keys have been added/removed in each update. J. -- Don't hit the keys so hard, it hurts. -- 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/20101119172938.gr...@earth.li
Re: Moving to stronger keys than 1024D
On Sat, Oct 05, 2013 at 10:37:40AM +0200, Stefano Zacchiroli wrote: What worries me is that by revoking my old key I'll make the situation for the WoT worse. Given the current state and evolution trends of WoT, is it actually the case, as Gunnar hints at above, or not? OTOH by not retiring my old 1024D key I feel increasingly more irresponsible, as impersonating me via the old key (and possibly sign other keys with it...) is becoming increasingly easier. Oh mighty Debian keyring maintainers and WoT gurus, what do you suggest to do in this respect? When is the right moment to retire old keys after migration to stronger ones? Now. If you have a 2048 bit or larger key that has been signed by at least 2 other DDs but still have a 1024D key in our keyring you should be filing a request for replacement. When we first started requiring larger keys for new DDs/replacements it was felt that we didn't want to risk our WoT and could take things gradually. I think we're at the point where we should be proactively moving to larger keys now. Your older key might be well linked and have a low MSD, but that includes all of the 1024D keys we're trying to move away from. The more useful question is how many of the signatures on your new key come from strong keys, and how many strong keys have you signed with that new key? J. -- ] http://www.earth.li/~noodles/ [] Mistakes aren't always regrets. [ ] PGP/GPG Key @ the.earth.li [] [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985[] [ signature.asc Description: Digital signature
Re: Moving to stronger keys than 1024D
On Sat, Oct 05, 2013 at 05:32:18PM +0200, Stefano Zacchiroli wrote: On Sat, Oct 05, 2013 at 08:17:48AM -0700, Jonathan McDowell wrote: Now. If you have a 2048 bit or larger key that has been signed by at least 2 other DDs but still have a 1024D key in our keyring you should be filing a request for replacement. I'm sorry, I realize only now I wasn't clear on this point. I was talking about the WoT at large, not only the Debian keyring. I've indeed replaced my 1024D key wih my 4096R key in the Debian keyring a long time ago. What I haven't yet done is _revoking_ the old key. Doing that now should have no bad effect on the Debian keyring, as any potentially bad effect there has already happened when I did the replacement. If we assume that 1024D keys have questionable security then at some point you stop trusting them entirely whether they're revoked or not. I finally revoked my 1024D about a year ago and should really have done so sooner. The more useful question is how many of the signatures on your new key come from strong keys, and how many strong keys have you signed with that new key? Right. If you happen to have a oneliner to verify that I'll be happy to answer these questions :) I don't having anything to convenient answer that unfortunately. J. -- ] http://www.earth.li/~noodles/ [] Aunt Em: Hate Kansas. Hate you. [ ] PGP/GPG Key @ the.earth.li [] Taking dog. Bye. Dorothy. [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985[] [ -- 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/20131005183113.gb8...@earth.li
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
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 Mon, Feb 24, 2014 at 05:53:58PM +, Ian Jackson wrote: Jonathan McDowell writes (Re: State of the debian keyring): On Sun, Feb 23, 2014 at 02:10:12PM +0800, Paul Wise wrote: * 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. Are we now at the stage where it is more important to retire these shortish keys, than to insist on this cross-signatures ? I.e., perhaps it would be better to invite key rollover from a short key to a long one despite the lack of 2 other DD signatures; or perhaps even despite the lack of _any_ other DD signatures. Instead, the keyholder could perhaps present a signed key transition document. I'd rather avoid this if possible, but it's something I'd be prepared to consider for those who really can't manage to any another signature. There's also the halfway house of allowing keys which are in the global strong set, even if they're not signed by other keys within the Debian strong set. At present I don't think we're yet at the stage we have to allow this though. A downside is that we would probably have to keep the rolled-over short keys somewhere, at least to maintain the integrity of our records of why a key is in the keyring. One of the useful things about the fact the keyring is managed in bzr[0] these days is that the changelog can record why something is the way it is. J. [0] At some point it will probably move to git, it's in bzr for historical reasons. -- Web [ 101 things you can't have too much of : 21 - Uptime. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- 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/20140224204048.gf27...@earth.li
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 10:51:56AM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. ... For email signatures, don't quite a few more things care? All votes, db.debian.org operations, etc. More relevantly an email signature isn't any different to a signature for a package upload, so DDs would have to specify what the use for each key was, keyring-maint would have to maintain appropriate keyrings indicating what the expected use of a key was, and all the project facilities that make use of signatures would have to make decisions about which keyring they were using. (Yes, for encryption that's a different situation but the only example I can think of where the project uses encryption to a key in the keyring at present is the initial account password / a password reset. And for an encryption/signing split subkeys should be able to handle the desired outcome, I think.) J. -- xmpp:nood...@earth.li Time is an illusion. Lunchtime doubly so. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225201243.go27...@earth.li
Re: keybase.io
On Fri, Apr 04, 2014 at 05:26:40PM -0400, Paul Tagliamonte wrote: On Fri, Apr 04, 2014 at 03:24:27PM -0600, Gunnar Wolf wrote: Right, I strongly agree with Luca here. I do too Likewise. To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. No, sorry. Don't do that. My key is on keybase, but *not the private half* Likewise. I have signed up to keybase.io largely to kick the tires and see what I make of it. I will absolutely not be trusting any third party with the private half of my key on their servers, even if it's passphrase protected and the crypto carried out at the client side. J. -- Revd Jonathan McDowell, ULC | You non-conformists are all alike. signature.asc Description: Digital signature
Re: keybase.io
[I trimmed the To down to -project because I think everyone on the CC is reading that; I certainly am so no need to explicitly CC me.] On Fri, Apr 04, 2014 at 05:18:13PM -0600, Gunnar Wolf wrote: Jonathan McDowell dijo [Fri, Apr 04, 2014 at 10:35:41PM +0100]: To be clear, if I spot any key that's both in any of the Debian keyrings and in keybase.io, I will proceed as if the key had been lost or compromised and immediately remove it from our keyring. No, sorry. Don't do that. My key is on keybase, but *not the private half* Likewise. I have signed up to keybase.io largely to kick the tires and see what I make of it. I will absolutely not be trusting any third party with the private half of my key on their servers, even if it's passphrase protected and the crypto carried out at the client side. Urgh... Well, please enlighten me here: Without fully auditing the Javascript code you are using to do the crypto client-side, can you *really* be certain your private half has not travelled to Keybase? 2 separate points to make here (as well as the general point Russ and Paul have followed up with about what do we trust in general running on the same machine as your GPG key). Firstly, there are 2 parts to the client side code from keybase.io, as far as I'm aware[0]. The first is they have an in browser implementation which requires your GPG private key to be stored on their server, but has it passphrase encrypted and all of the actual use of the key is through client side browser Javascript. The second is they have a node.js based CLI tool which runs on your personal machine and uses a key stored locally. This actually calls out to GPG to do the crypto. The former I think is a bad idea (because it definitely involves giving keybase the private part of the key). The latter on the face of it sounds acceptable (as long as there's no part of the code that is directly manipulating the key or potentially sending it off machine) and doesn't seem to have any greater issue than anything else that might use a GPG installation. With regards to my particularly situation I have not used the keybase website from any machine that also has my private GPG available to it. This is largely a factor of the way I treat my key rather than any special precaution I have taken around keybase. Once I get my head around the horror of the keybase CLI client being npm tentacles and pulling in a bunch of random stuff that I'm not sure I fully trust I will examine that set of code to convince myself that it's not going to leak my key anywhere and potentially try it out. J. [0] I may be wrong about these and welcome corrections; I have not yet delved into the details of the service and its implementation. -- Evil will always triumph over | .''`. Debian GNU/Linux Developer Good, because Good is dumb.| : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Re: keybase.io
On Fri, Apr 04, 2014 at 08:15:10PM -0400, Paul Tagliamonte wrote: On Sat, Apr 05, 2014 at 12:57:50AM +0100, Jonathan McDowell wrote: 2 separate points to make here (as well as the general point Russ and Paul have followed up with about what do we trust in general running on the same machine as your GPG key). Sorry, I wrote that from my phone. My point was this attack vector (nonfree code running on the same machine as your OpenPGP key) taken to it's absolute extreme (wine, dropboxd) is still *not* grounds for automated removal from the keyring. I'm not disagreeing with that; I was agreeing that if you're going to argue about one piece of non-free code then where do you draw the line. What about my network interface firmware? My hard drive firmware? My BIOS? With my keyring-maint hat on I back Gunnar and Luca's statements that people should not be uploading the private part of their keys used for Debian work to the keybase website, and if I am made aware of any private keys in the Debian keyring that are on the site I will treat them as potentially compromised. I am not saying you shouldn't try the keybase website on the same machine as the key lives on, or examine the keybase CLI client, or run the GPG commands manually. At present I have no firm opinion about these actions. Furthermore, the way *I* set up Keybase was to run the GnuPG commands they requested (clearsigning and decrypting), since they looked safe and sane (and paste the results back in a form. I had not noticed that was an option. I've also examined these commands, decided they looked sane and pasted the output back into the form. Firstly, there are 2 parts to the client side code from keybase.io, as far as I'm aware[0]. The first is they have an in browser implementation which requires your GPG private key to be stored on their server, but has it passphrase encrypted and all of the actual use of the key is through client side browser Javascript. The second is they have a node.js based CLI tool which runs on your personal machine and uses a key stored locally. This actually calls out to GPG to do the crypto. Thirdly, you can run raw (sane and short) GnuPG commands by hand in the terminal, pasting results back. I hadn't noticed this was an option; thank you for making me aware of it. The former I think is a bad idea (because it definitely involves giving keybase the private part of the key). The latter on the face of it sounds acceptable (as long as there's no part of the code that is directly manipulating the key or potentially sending it off machine) and doesn't seem to have any greater issue than anything else that might use a GPG installation. With regards to my particularly situation I have not used the keybase website from any machine that also has my private GPG available to it. I have, and I seriously doubt my key has been taken. I agree, I don't think the code is going to maliciously try and steal my key, it just happens that the machines I run browsers on don't have access to my key by default. J. -- Web [ And you can't help my life. But you can hide the knives. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: Digital signature
Re: [Debconf-discuss] DebConf14: Last call for keys for keysigning in Portland, Oregon, USA
On Fri, Aug 15, 2014 at 01:27:28AM +0200, Aníbal Monsalve Salazar wrote: As part of the 15th Debian Conference in Portland, Oregon, USA there will be OpenPGP (pgp/gpg) keysignings. If you intend to participate in the DebConf14 keysignings, please send your ascii armored public key as explained at [0] no later than 23:59 UTC/Zulu on Monday 18th of August, 2014. We are a few days away from the deadline! Some statistics are below. · At this point in time, there are 79 keys in the DebConf14 keyring: 6 1024D I can think of no good reason to be including these keys in the DC14 keysigning and in fact believe that it is actively harmful for us to be encouraging people to continue propagating the use of 1024 bit keys. I hope that all 6 keys are from people who have also generated larger keys, but even if they're not I would like to request that they are removed from the DC14 keysigning keyring. People, move to larger keys. Yesterday. keyring-maint has been banging this drum for some time. DebConf is the perfect time to make sure your new key is well linked with the rest of Debian. J. -- /-\ | This screen intentionally left |@/ Debian GNU/Linux Developer | blank. \- | signature.asc Description: Digital signature
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On Sat, Nov 08, 2014 at 08:25:58PM +0100, Marco d'Itri wrote: On Nov 08, Jonathan McDowell nood...@earth.li wrote: Back in August I sent notification[0] about the fact that we will be removing all keys less than 2048 from our keyrings at the end of the year (31st December 2014). Sadly the response to this has been slower than expected, and we still have about 439 keys that require replacement. So the plan is that the beatings will continue until morale improves? I am sorry you and those developers who have emailed me privately to complain feel like I am engaging in some form of punishment or naming and shaming. I deliberately did not include the list of affected contributors in my August mail, despite being asked to be several people. At this point I'm now trying to make sure that absolutely no one can claim that they were not warned about the forthcoming key removals; I have also been criticised for having too soft an approach up to this point, such that several people have felt that the first warning they had that the project was phasing out shorter key lengths was the August mail. To reinforce Enrico's mail I'm well aware that there are people on the list who are valiantly trying to get the signatures they need on new keys, and have had legitimate issues with getting them. I ask the project to help them where possible. J. -- 101 things you can't have too much of : 19 - A Good Thing. signature.asc Description: Digital signature
Re: About language specific package management tools
On Fri, Jan 23, 2015 at 10:57:55AM +, Anthony Towns wrote: It takes a couple of minutes to download something using pip or npm; how long does it take to get a python or nodejs Debianized and installable? (eg: learning that npm2deb exists, how to use it, what else you have to do to have a package, building the package, and getting apt access to the package -- which in turn presumably includes setting up and distributing an archive key) In an ideal world, users would just be able to say apt-get install lib-whatever-perl and have it. At worst, they might have to modify their apt sources explicitly to say yes, I know there's a lot of crap on CPAN that doesn't necessarily receive good security updates, I know what I'm doing. There's two ways that could be achieved: - having automated scripts pull everything from CPAN (et al), package it as debs, and publish it - having about 14,000 new DDs each individally maintaining 10-20 library packages But if the answer is oh, you want to use some random nodejs package? just npm it into /opt. if you want there's some tools to help start you off in packaging it too (Yes, I really think Debian should have 300k+ packages, including If this is being done in an automated fashion is there not a third option? Teach apt and associated tools about the language specific repositories. They'd do the download from CPAN or wherever, do the conversion, and pass to dpkg. On the fly, no need to expand the archive and no need to wait for the latest and greatest if you're that way inclined. For extra bonus points teach cpan, gem etc to still work but register the package + files with dpkg. I think there are some issues with automated packaging which would mean that you'd still want hand crafted bits, and there's the question of how you pin to a stable version (though I think often the reason people are pulling in from external sources is because the version in stable simply isn't recent enough, rather than unavailable) but it'd be kinda cool to have: cpan http://cpan.etla.org/ cran http://mirrors.ebi.ac.uk/CRAN/ etc in /etc/apt/sources.list and have it just work. You could probably treat each different source as a different suite to aid with apt pinning (and by default preferring the Debian version rather than the external version). J. -- I reckon that me and you should rule the world. signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 09:26:27AM +0100, Jonathan McDowell wrote: On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - Kurt Roeckx wrote: Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | |--+--++---++-++---| This num DDs seems a bit higher than I'd expect; it looks more like the number of DDs with active keys + emeritus DDs, rather than the number of DDs with active keys + number of non-uploading DDs with active keys + number of DDs with removed 1024 bit keys. active DD keys: 751 active DN keys:12 1024 bit removed DD keys: 220 emeritus keys:283 So I think quorum is 983. It's possible the number might be one or two higher as that won't included anyone who is entirely missing a key at present but such situations are rare. As Phil has pointed out to me, I meant total voters here rather than quorum. J. -- This .sig brought to you by the letter F and the number 26 Product of the Republic of HuggieTag signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - Kurt Roeckx wrote: Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | |--+--++---++-++---| This num DDs seems a bit higher than I'd expect; it looks more like the number of DDs with active keys + emeritus DDs, rather than the number of DDs with active keys + number of non-uploading DDs with active keys + number of DDs with removed 1024 bit keys. active DD keys: 751 active DN keys: 12 1024 bit removed DD keys: 220 emeritus keys: 283 So I think quorum is 983. It's possible the number might be one or two higher as that won't included anyone who is entirely missing a key at present but such situations are rare. J. -- The more things change the more | .''`. Debian GNU/Linux Developer things suck.| : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers. signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 07:12:22PM +0200, Kurt Roeckx wrote: On Thu, Apr 16, 2015 at 09:26:27AM +0100, Jonathan McDowell wrote: On Wed, Apr 15, 2015 at 11:12:14PM +0200, Debian Project Secretary - Kurt Roeckx wrote: Stats for the DPL votes: |--+--++---++-++---| | | Num || Valid | Unique | Rejects | % | Multiple | | Year | DDs | Quorum | Votes | Voters | | Voting | of Quorum | |--+--++---++-++---| | 2015 | 1033 | 48.210 | 364 |353 | 39 | 34.172 | 7.32206 | |--+--++---++-++---| This num DDs seems a bit higher than I'd expect; it looks more like the number of DDs with active keys + emeritus DDs, rather than the number of DDs with active keys + number of non-uploading DDs with active keys + number of DDs with removed 1024 bit keys. active DD keys: 751 active DN keys: 12 1024 bit removed DD keys: 220 emeritus keys: 283 So I think quorum is 983. It's possible the number might be one or two higher as that won't included anyone who is entirely missing a key at present but such situations are rare. I get the numbers from nm.debian.org, both at https://nm.debian.org/api and https://nm.debian.org/public/findperson/ Sadly this list is trivially proved inaccurate; the list for Debian Developer, Uploading includes stew who was moved to emeritus back in January: https://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=b768c0a3506631ddeacf4c80ba8f3be6995e8a8f and finger s...@db.debian.org correctly returns no active fingerprint for the user. Copying Enrico who can no doubt comment more about the expected accuracy of nm.debian.org; AIUI it's still a work in progress in terms of being entirely up to date all the time. J. -- Don't just stand there, kill something. signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Fri, Apr 17, 2015 at 09:09:01AM +0200, Kurt Roeckx wrote: On Thu, Apr 16, 2015 at 09:28:34PM -0500, Gunnar Wolf wrote: Kurt Roeckx dijo [Fri, Apr 17, 2015 at 12:45:37AM +0200]: On Thu, Apr 16, 2015 at 10:41:52PM +0100, Jonathan McDowell wrote: Sadly this list is trivially proved inaccurate So I have no source at all that is can tell me the number of DDs? You can fetch the number of active DD keys [1,2], and add to it the number of removed 1024D keys [3]. When a person who had their key removed due to being too short presents a new key, we take the old one out of the removed-1024 tree as well. People with 1024D keys cannot vote, but don't lose their DD status. As far as I know relying on the keyring and ldap has always been incorrect. The number was always off by a few. I've never quite understood why LDAP isn't accurate, but I couldn't figure out a simple query and even '((gidNumber=800)(!(shadowExpire=1))(objeass=debianDeveloper))' gives 988 entries of which some are incorrect. 3 of these have no key: adeodato, flatmax + schizo. flatmax has a lost key. adeodato + schizo are account renames and I'm not sure why the old ones are still around as active. 2 of those with fingerprints are keys that have been moved to emeritus but don't seem to have been cleaned up; they did not have RT tickets so I suspect they got missed and I have already filed an RT ticket for DSA to sort them out. 2 others of those with fingerprints are DDs with lost or revoked keys. The astute will notice that this leaves 981 keys, whereas I counted 983 keys in the keyrings. It turns out there are 2 DDs who have removed 1024 bit keys but who have locked LDAP accounts (issue with SSH key on one, DSA locked on the other as comments). Anyway. The 2 things to take away are a) yes, it's depressingly hard to work out how many voting members Debian has and b) the answer is 986 at present. Of course, the only authoritative number should be in the hands of DAM. But we have something, uh, quite close to it. It's was my understanding that DAM says that nm.debian.org is authoritative. That is the eventual goal but at present various pieces of information are manually updated. Enrico and keyring-maint have been working on making it easier for nm.d.o to track keyring changes but there's still more to be done before this is complete. There's a vague plan to get this done during DebConf if not before. J. -- Revd Jonathan McDowell, ULC | Interesting concept. signature.asc Description: Digital signature
Re: concerning debian.nl domain
On Thu, Mar 31, 2016 at 01:50:03PM +0200, Paul Slootman wrote: > My former employer registered the debian.nl domain when the previous > holder wasn't interested any more, mostly to prevent it falling into the > wrong hands. > > That was some time ago; since some time that former employer is busy > taking down the company, so debian.nl needs to find a new holder. > > As I have no idea who to contact about this, I'm sending this message to > debian-project. I would like to transfer debian.nl to the project so > that it's in safe hands. This seems like something that should be in the hands of SPI, with Debian's other domains. J. -- Web [ "A true friend knows who you are...but likes you anyway." ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 signature.asc Description: Digital signature
Re: Proposed GR: Acknowledge that the debian-private list will remain private
On Thu, Jul 07, 2016 at 03:37:08PM +0200, Nicolas Dandrimont wrote: > In 2005, the body of Debian Developers passed a General Resolution[1] > requiring the creation of a declassification team for the > debian-private mailing list. For the past ten years, the > implementation of this GR has never materialized, despite an explicit > call for volunteers[2] by the DPL in 2010. > > [1] https://www.debian.org/vote/2005/vote_002 > [2] https://lists.debian.org/debian-project/2010/05/msg00105.html > > Over the years, several important discussions have happened on the > debian-private mailing list that needed to stay private. Oftentimes, when a > discussion has carried on for a while, some participants have reminded others > that the discussion should be summarized in a public thread on either the > debian-devel or the debian-project mailing lists. > > While we agree with the intentions behind the original GR, we believe it is > now > time to acknowledge that the declassification of debian-private will never > happen, and that we should instead strongly encourage developers to move > discussions to public channels as soon as the sensitivity of the discussion > subsides. > > We therefore propose the following General Resolution: > > === BEGIN GR TEXT === > > Title: Acknowledge that the debian-private list will remain private. > > 1. The 2005 General Resolution titled "Declassification of debian-private >list archives" is repealed. > 2. In keeping with paragraph 3 of the Debian Social Contract, Debian >Developers are strongly encouraged to use the debian-private mailing >list only for discussions that should not be disclosed. > > === END GR TEXT === > > Thanks for your consideration, Seconded. J. -- signature.asc Description: Digital signature
Re: wanted: educate us please on key dongles
On Fri, Aug 11, 2017 at 10:08:16AM -0700, Sean Whitton wrote: > Thank you for the explanation. > > On Fri, Aug 11 2017, Jonathan McDowell wrote: > > > * If you don't want to buy hardware, use an offline master > > key. Create > >a certification only master key using something like PGP Clean Room > >on a non-networked host [...] > > By default, GnuPG creates a signing+certification master key. Could you > explain why it's a good idea to override that? I'm not sure what it > achieves. I see no reason why the master key should ever be used for signatures in such a scenario, so it seems sensible to indicate that it is purely for certification. J. -- /-\ |"Could I have an 'E', please, |@/ Debian GNU/Linux Developer |Bob?" (Blockbusters) \- | signature.asc Description: Digital signature
Re: wanted: educate us please on key dongles
On Wed, Aug 02, 2017 at 10:16:29PM +0200, Adam Borowski wrote:
> It would be nice if someone knowledgeable could educate the rest of us
> about physical key dongles -- a number of DDs/DMs/contributors still
> keep their secret keys on a regular disk, and could use a primer. Me
> included. I do have a backup key with plenty of sigs that's stored
> securely, but my regular key is on the same physical machine I test
> random software on.
...
> There's GNUK ("out of stock"), Nitrokey and others -- but how do they
> differ? Actually, at this point it would be easier to skip the
> details and say "if you don't know any better, buy X".
>
> Thus: can I has "key dongles for dummies", plz?
The need for such a document has been brought up several times, but
it's never actually been created (and indeed a general "what's my best
approach to managing keys"). It's on the todo list, but I think there
are a bunch of software pieces that need to also happen in order to make
it a smooth process that people can actually easily engage in.
Here, at a very high level without instructions of how to do any of it,
is what I think might be a suitable base:
* If you don't want to buy hardware, use an offline master key. Create
a certification only master key using something like PGP Clean Room
on a non-networked host, and store that on a USB key you only ever put
into your machine when running your clean, non-networked,
environment. Create at least 2 subkeys - signing + encryption - and
use those in your day to day work. You then only need the master key
when dealing with signing other keys, or updating your subkeys. In
the event of your subkeys being compromised or lost or whatever you
can just regenerate; because your master key is offline it should
remain secure meaning you don't have to go through the pain of
getting cross signatures again.
(All of this needs a nice easy work flow, including a set of scripts
or something to shuffle keys to sign off your network connected
machine onto a USB stick and then into the clean room to be signed
and then back to the USB stick to be shuffled onto the networked
host to be emailed out and this is why I haven't written the doc
because without tooling it's going to be 100 pages of the most
boring screenshots you've ever read.)
* If you want to buy hardware then one of the self contained USB
tokens that look like a smartcard + reader to the OS is probably
easiest. Part of the problem is that everything I've seen only
supports 3 keys on the device and those are one each of signing,
encryption + authentication. Which means you can't have a master
certification key and a signing subkey on the same device.
If you can manage it, have 2 devices; one with the master and the
other with your day-to-day keys. Otherwise I guess having a master
key that is signing enabled might be the best option? (Opinions,
anyone else?)
* For hardware I'm aware of the following:
* GnuK: My favourite choice. It's slow with RSA4096, but does
support it. The hardware is open. The software is open (you can
compile and flash it using tools available in main). Upstream is
responsive (and a DD). However it's physically not quite as
polished and there are availability issues.
* Nitrokey Start: This is based on the GnuK (note their other
devices are not) and seems like it might be a good alternative
that is more physically robust will still being reasonably Free.
I've not actually had my hands on one however so this is guesswork
- but they do pop up on the GnuK dev list occasionally.
* Yubikey. I'm not sure about this; it's entirely closed these days
I believe. However they're easily available and I understand
they're pretty robust in terms of living on a keyring all the
time.
I appreciate this is not the "key dongles for dummies" asked for, but
hopefully it's more helpful than continued silence. I personally would
like us to get to the point where the "offline master" is our base line
for how contributors to Debian manage their key - it provides a useful
measure of extra security without the extra expense that a USB token
involves. That said a USB token is definitely a better option.
J.
--
Life is a bitch, but some of the | .''`. Debian GNU/Linux Developer
puppies are cute. | : :' : Happy to accept PGP signed
| `. `' or encrypted mail - RSA
| `-key on the keyservers.
signature.asc
Description: Digital signature
Re: wanted: educate us please on key dongles
On Fri, Aug 11, 2017 at 04:52:36PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 11 Aug 2017, Jonathan McDowell wrote: > > I see no reason why the master key should ever be used for > > signatures in such a scenario, so it seems sensible to indicate that > > it is purely for certification. > > Well, it can be useful. A SC master key (Sign and Certify) can be > used to sign messages explaining to someone else the need for a new > subkey when you had to revoke every subkey, when just adding the > subkey itself is not enough, or when adding subkeys is subject to a > delay. > > Suppose you forget to renew/upload a new subkey in your Debian key > set, and the current subkeys expire: it takes time for a new subkey > upload to clear keyring maint. During that time, an SC master key can > be used in an emergency to sign a vote or an upload. I see this as a failure to manage the signing subkey correctly, and a certification only master key as helping to prevent the temptation to just make use of the master for signing (and potentially avoid jumping through all of the hoops required to use it securely). (That said, I'm very conscious that a lot of crypto comes down to a set of tradeoffs and I'm all in favour of people who have strong informed opinions about how to do things differently doing those things if they want. But if you ask me for a base line set of advice to J. Random DD I'd still go with the certification only master.) J. -- ... And you can't help my life. But you can hide the knives.
Re: Security advisory for YubiKey 4: RSA generation broken
On Mon, Oct 16, 2017 at 09:13:19PM +0200, Yves-Alexis Perez wrote: > On Mon, 2017-10-16 at 21:06 +0200, Christian Seiler wrote: > > Unfortunately, as far as I understand it, there's no easy method for > > detecting these kinds of broken keys without actually attempting to > > factorize them - and while that's feasible (hence the vulnerability) > > it is still quite expensive - so there is currently no easy method of > > scanning through the Debian keyring for affected keys. > > Actually that's wrong, the generation process leaves “fingerprints” which can > be used to identify keys. See for example: > > https://keychest.net/roca > https://github.com/crocs-muni/roca > > These tools have been used to identify three vulnerable (sub)keys in the > Debian keyring (this is already been taken care of). It's been quite frustrating to deal with all the well-meaning individuals who have been making keyring-maint aware of this today. I haven't had time to prepare a canned statement that would present, our understanding of the issues, and there were a couple of things I wanted to run by the rest of the team once I'd assessed the impact to the keyring. That's meant multiple people trying to get into a conversation about the issue on IRC, and several emails as well. There are 3 Debian Developers with 6 subkeys in the current keyring working tree that are flagged by the roca tool. These belong to jelmer, olasd & siretart[0]. Firstly, none of the flagged keys is a master key, so there is a simple resolution of revoking the broken subkeys and securely generating new ones. The users in question can then send the updated keys via HKP to keyring.debian.org (i.e. using "gpg --keyserver keyring.debian.org --send-key") and they'll be picked up in the next keyring update. Secondly, all of the flagged keys are 4096-bit. My reading of the situation is that there is still a significant amount of effort required to factorise these keys and that a knee-jerk removal from the keyring is therefore overkill. After sending this mail I intend to contact the affected developers directly and propose that they revoke their subkeys within the next week, and that we'll do a keyring update at that point, or sooner if we receive confirmation all have already done so. J. [0] I debated listing them here but it's easy enough to work it out and I know at least one individual not associated with keyring-maint has already emailed them. -- "Why? - because it's f***ing there!" -- Edmund Hilary signature.asc Description: PGP signature
Re: wanted: educate us please on key dongles
On Tue, Aug 29, 2017 at 07:34:35PM +0200, Marc Haber wrote: > On Fri, Aug 11, 2017 at 01:41:39PM +0100, Jonathan McDowell wrote: > > * GnuK: My favourite choice. It's slow with RSA4096, but does > > support it. The hardware is open. The software is open (you can > > compile and flash it using tools available in main). Upstream is > > responsive (and a DD). However it's physically not quite as > > polished and there are availability issues. > > Would that be this device: > > https://www.amazon.de/Fst-Without-Enclosure-32-Bit-Computer/dp/B01IOYSIBG ? > Is that a reasonable price? I think NIIBE was selling them for about €30 at DebConf, so that's a reasonable mark up. He said Seeed are currently changing business model to move away from low volume devices, but despite what their website says they do still have some in stock. > > * Nitrokey Start: This is based on the GnuK (note their other > > devices are not) and seems like it might be a good alternative > > that is more physically robust will still being reasonably Free. > > I've not actually had my hands on one however so this is guesswork > > - but they do pop up on the GnuK dev list occasionally. > > Their web page says that it will only suppor 2048 bit RSA keys, which is > the limitation of most USB crypto tokens on the market today. The > Nitrokey Pro will also do 3072 and 4096 bit, but it's considerably less > free? The Start is based on the GnuK and I think should be upgradable to do 4K keys. The Pro uses a non-free smartcard internally for the RSA operations. I believe the Start should also be capable of ECC, as per the GnuK. It's possible Nitrokey haven't updated their firmware to support this yet. > > I appreciate this is not the "key dongles for dummies" asked for, > > but hopefully it's more helpful than continued silence. I personally > > would like us to get to the point where the "offline master" is our > > base line for how contributors to Debian manage their key - it > > provides a useful measure of extra security without the extra > > expense that a USB token involves. That said a USB token is > > definitely a better option. > > I have been postponing the offline master stuff for years because of > the hassle connected. Would it be a stupid idea to have one hardware > token for the Master key (generated on the device, never having left > it) and a second token for the everyday signing and encryption keys? > Can I have a master certification key on one device and subkeys on > another one? Can I also have this when the private parts of master and > sub keys have been generated on different devices? Yes. I have a GnuK which holds my 0x21E278A66C28DBC0 master key, and then a separate device which has the 3 active subkeys (signing, encryption + authentication) for this key. J. -- 101 things you can't have too | .''`. Debian GNU/Linux Developer much of : 25 - email. | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers.
Re: wanted: educate us please on key dongles
On Wed, Aug 30, 2017 at 12:50:53PM +0200, Marc Haber wrote: > On Wed, Aug 30, 2017 at 12:42:13PM +0200, Adam Borowski wrote: > > * with Yubikey 4 (suspected): they send the secret handshake, get a > > copy of the key, and you don't even know anything happened > > That's a point, but I cannot validate whether the free hardware design > running the free software crypto app isn't backdoored anyway due to > lack of knowledge and expertise. If you're not interested in anything where you're not able to do all of the validation yourself, why are you asking us for advice only to then say you don't see the point of the recommendations given? At the risk of trying to teach my grandmother to suck eggs, the advantage of an open hardware + software design is that even if you yourself are unable to fully validate the security of the device there is the opportunity for others to do so and share their findings. (I do not claim to have done any security investigation of the GnuK code, but I have successfully built and installed it using only tools available in Debian.) J. -- /-\ | No thanks, I'm already having one. |@/ Debian GNU/Linux Developer | \- |
Re: Keysigning in times of COVID-19
Enrico Zini wrote: > we have people approaching Debian with a lack of GPG signatures, and we > generally cannot ask them to travel and meet other developers in person > to get their key signed. It's worthwhile stating the actual problem that is trying to be solved here. I believe that is: "Given difficulties with keysigning in the modern environment, what does the project believe is the appropriate verification of identification before we allow someone access to our systems, the ability to upload packages and/or the ability to vote within the project". For a long time our default approach has been that a sufficiently signed PGP key is our bar, with occasional exceptions when alternative verification has been performed (I know in the past DAM has phoned applicants when it has been impossible for them to obtain signatures). Key signing has been creaking for a while, and I'm conscious even before COVID-19 it was a bar that made things difficult for some applicants. Equally DAM phoning everyone does not scale (and I'm not even sure how it adds a significant extra level of assurance). I worry that by framing this discussion in terms of "what would be an acceptable weakening of our keysigning requirements" we are losing the benefit we gain from keysigning, and avoiding the actual problem we want to solve. J. -- ] https://www.earth.li/~noodles/ [] If a program is useless, it must [ ] PGP/GPG Key @ the.earth.li[] be documented. [ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][ signature.asc Description: PGP signature
