Re: GR proposal: code of conduct
On Thu, Feb 13, 2014 at 5:48 AM, Stefano Zacchiroli wrote: For IRC it's a bit more difficult, because we do not long our IRC channels by default (or at least I'm not aware we do), with the exception of meetings run with the help of meetbot. ... i.e. publicly log our IRC channels. That would be nice, the IRC channels are currently a big back-channel that hides a bunch of useful information from the wider public. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6g7vteheceuqw6oa+jxvdqnh8rjfwzm57ykncgctpa...@mail.gmail.com
Re: GR proposal: code of conduct
On 2014-02-24, Paul Wise p...@debian.org wrote: That would be nice, the IRC channels are currently a big back-channel that hides a bunch of useful information from the wider public. Much of irc are semiprivate chatter and socializing and not really something that should be available to the wider public. It is true that occasionally there is some useful information that the rest of the world could gain some technical knowledge from. It is also true that there is some information around that gives the world more knowledge about interactions between developers. But the latter part isn't actually meant for big public consumptions. In the socializing part could be people showing a picture of their kid to their debian friends. In the technical bit, there could be 'how to recover from broken RAID's'. In the last bit could be developers discussing wether or not to act when project members seems to have lost it. Given all of it happens in the 'same mess' and can't easily be separated, and two thirds of it shouldn't really be published, I think that public logging is a bad idea. /Sune -- 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/leficq$cs6$1...@ger.gmane.org
jessie doubt debian
Well I wonder, why in the Debian testing (jessie), I can not go back to previous page with Backspace, as it did previously. This happened after an upgrade, and the problem is that I can not also enroll in the debian forum. I thank you, and excuse my english. I'm Brazilian. Atenciosamente. - *Robson Laurindo Cachoeira.* bobycachoe...@gmail.com -
Re: State of the debian keyring
Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi A large number of people still using 1024 bit keys are very active DDs. Lucas -- 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/20140224163534.ga19...@xanadu.blop.info
Re: State of the debian keyring
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. 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. Ian. -- 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/21259.34614.519800.702...@chiark.greenend.org.uk
Re: State of the debian keyring
Gunnar Wolf writes (Re: State of the debian 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). 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. Ian. -- 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/21259.34853.289374.378...@chiark.greenend.org.uk
Re: GR proposal: code of conduct
Sune Vuorela writes (Re: GR proposal: code of conduct): Much of irc are semiprivate chatter and socializing and not really something that should be available to the wider public. I don't think this is realistic for channels which anyone in the world can join. There are no doubt many people who have private logs and there would be nothing stopping anyone making such a log public without our consent. If we objected we would have to engage in ridiculous and easily-defeated forensics (and perhaps disruptive interventions) to try to discover who the leaker was. Is it really the case that making the logs available as public text files produces too much search engine exposure etc. (which is I guess the real concern) ? Ian. -- 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/21259.35071.771629.665...@chiark.greenend.org.uk
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 11:35 AM, Lucas Nussbaum lu...@debian.org wrote: Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi A large number of people still using 1024 bit keys are very active DDs. I believe I have an idea that's better than the status quo, and is actionable now without potentially crippling the project. Please let me know if I am missing something significant. Perhaps we could create a new transition role GPG identity, that would be administered by the keyring maintainers and would sign any requests for changing to a strong key that are signed by the same DD's weak key. We would allow DDs to use the new strong key to do their work for a limited period of time, while they seek the required two DD signatures. (Say 12 months, but this is fungible.) I am proposing a role key, so it doesn't get confused with real sigs and we can easily track who still needs real sigs. Obviously as DDs switched to srong keys using this option, their old 1024 bit keys would be disabled, but to really make this better than the status quo, we would need to couple this with a policy to set a fairly aggressive date for disabling any 1024 bit keys. (Basically just enough time for keyring maintainers to absorb the influx of key change requests from active DDs.) This prevents us from having to wait for everyone to get their 2 sigs to move to stronger security. It also means we can as a project set a relatively aggressive date of turning off 1024-bit keys. The biggest drawback I foresee is that this does put a large burst of workload on the keyring maintainers. (I suspect however this shouldn't be a showstopper, as we could make approval contingent on having enough extra volunteers to implement it.) Thanks, Brian P.S. - We could even give a certain grace period, after disabling 1024 bit keys, to allow DDs to use the same process if they someone missed the announcements and get stuck being unable to upload. (This way we can be even more aggressive about turning off the 1024bit keys.) -- 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/CACFaiRzr6y5=9_pd+xngyhdrkrbyorprjgphf_-c6ody-x5...@mail.gmail.com
Re: GR proposal: code of conduct
On Mon, Feb 24, 2014 at 1:01 PM, Ian Jackson ijack...@chiark.greenend.org.uk wrote: Sune Vuorela writes (Re: GR proposal: code of conduct): Much of irc are semiprivate chatter and socializing and not really something that should be available to the wider public. I don't think this is realistic for channels which anyone in the world can join. There are no doubt many people who have private logs and there would be nothing stopping anyone making such a log public without our consent. If we objected we would have to engage in ridiculous and easily-defeated forensics (and perhaps disruptive interventions) to try to discover who the leaker was. Is it really the case that making the logs available as public text files produces too much search engine exposure etc. (which is I guess the real concern) ? Ian. I think we might be overthinking IRC bans. In my mind, IRC bans aren't a big deal, as even a faultily configured IRC client can (rightfully) trigger these bans. It's also fairly obvious to others in the channel why bans are instituted. Also, since IRC bans don't trigger a project-wide ban from mailing lists, bugtracker, etc, I don't believe we really have to worry about instituting new IRC based tracking processes. IE: IRC is a sometimes flaky, informal transient/dynamic communications medium, if it breaks or someone is banned for having a faulty client, they can always fall back to email or other more formal communications methods.. Thanks, Brian P.S. - I sidestepped the question about publicly logging IRC channels as I have mixed feelings on the topic, and don't feel it's required to agree to the CoC and implement it. -- 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/cacfairypzwf2ggqy+gp4mk-tlvbywav3ej_e_3r4t8wasta...@mail.gmail.com
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 05:46:53PM +0300, Cyril Brulebois wrote: (It took me like 4 years to switch to my current 4k key, partly because I didn't feel the urge to switch, and partly because I would have hated wasting your time with a malformed request.) It also took me a long while to switch because I didn't understand that it was already this urgent, so my mode of operation was let's collect sigs for the time being, and switch when I hear another call. I think it would be useful to see an update to debian-devel-announce, explaining what's the current vulnerability status of 1024bit keys, and asking to please switch NOW. As a potential follow-up plan, I propose this one: After a month or two, we can start mailing people directly, starting from the most active, asking why they haven't migrated yet, and asking them to please tell others to migrate if they see a 1024 key around. After another month or two, we can start taking keys off the keyring, starting from the less active people, and announcing each batch of removed keys to d-d-a. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: State of the debian keyring
On Mon, 24 Feb 2014, Ian Jackson wrote: 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. This is already possible with subkeys. That said subkeys of a 1024 bits master key can't really be trusted, even if they are bigger. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140224193700.ga15...@x230-buxy.home.ouaza.com
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 08:28:53PM +0100, Enrico Zini wrote: I think it would be useful to see an update to debian-devel-announce, explaining what's the current vulnerability status of 1024bit keys, and asking to please switch NOW. As a potential follow-up plan, I propose this one: Seconded. If I'm reading Clint's reports right, the aspect that worries me the most is that in 1 month (the delay between the two reports) we've only got 10 additional 4K keys, which is a very slow progress rate. I agree with Enrico that the next step is communicating clearly to project members the *urge* of switching, and I also agree that we should actively nag people to do the switch. Regarding the doc on the migration, I don't have clear proposals on how to make it better, but I AOL other comments in this thread: I've been misreading the text myself for quite a while (or maybe it did change and I didn't notice? no idea) as mandating a third-party to request the change. And I've been chatting with various DDs over time who were postponing the change due to that extra step --- yes, I agree that's a silly reason, but given the urge of migrating I think we should make the procedure as simple as possible and make sure that people *know* it is simple. Just my 0.02 EUR, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
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
Hi, Brian Gupta: weak key. We would allow DDs to use the new strong key to do their work for a limited period of time, while they seek the required two DD signatures. (Say 12 months, but this is fungible.) I am proposing a role key, so it doesn't get confused with real sigs and we can easily track who still needs real sigs. OK, so except for the use a role key for tracking part this is exactly what I proposed, or attempted to propose anyway, in my last email. I don't think we'd need a separate role key, that'd require two key transitions per DD and thus more work for the keyring maintainers. A list of strong keys in the keyring as of now should be sufficent. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: jessie doubt debian
On Mon, 2014-02-24 at 12:46 -0300, Robson LAURINDO CACHOEIRA wrote: Well I wonder, why in the Debian testing (jessie), I can not go back to previous page with Backspace, as it did previously. If you're using Iceweasel/Firefox, see: http://kb.mozillazine.org/Browser.backspace_action This happened after an upgrade, and the problem is that I can not also enroll in the debian forum. I think this must be a separate problem. I thank you, and excuse my english. I'm Brazilian. The correct list for questions like this would be debian-user or debian-user-portuguese. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth signature.asc Description: This is a digitally signed message part
Re: State of the debian keyring
Marco d'Itri m...@linux.it writes: If anybody disagrees then please describe a credible threat model in which: - an entity would want to have access to the key of a DD, and - would find brute forcing a 1024 bit key more practical than stealing it or coercing a developer to disclose it. Brute-forcing the key just requires compute cycles. There is essentially no chance of discovery and no risky activity at all until you start actually using the key. You can basically choose exactly how or when you want to use it, or use it only passively to decrypt data (although we don't really use our keys much for encryption, mostly). Stealing the key or coercing a developer is *far* riskier and runs a far higher chance of discovery, because both necessarily involve doing things out in the world that are visible and noticable and that would be of potential interest to the news media, etc. The reason why people tend to focus on passive risks like brute-force factoring is that they're only difficult in terms of necessary compute power (or breakthrough mathematics). They pose essentially zero operational difficulty and essentially zero risk; all the data that you need to make the attempt is completely public, and attempting it is not at all suspicious. There's no risk of getting caught. That makes the attack far more feasible. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87sir7lxae@windlord.stanford.edu
Re: State of the debian keyring
On Mon, 24 Feb 2014, Ian Jackson wrote: Gunnar Wolf writes (Re: State of the debian 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). I think this is a bug. I'm also not convinced it's actually correct. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- 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/20140225061442.gt24...@anguilla.noreply.org
