Re: GR proposal: code of conduct

2014-02-25 Thread Sune Vuorela
On 2014-02-24, Ian Jackson ijack...@chiark.greenend.org.uk wrote:
 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.

This is true for any electronic communication. People will probablybe
asked to leave the forum if they insist on making logs public. And by
asked, I mean forced.

 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) ?

Yes.

Would you want your chatter in the pub with friends recorded and
published?

/Sune


-- 
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/lehm34$e08$1...@ger.gmane.org



Re: GR proposal: code of conduct

2014-02-25 Thread Andrey Rahmatullin
On Mon, Feb 24, 2014 at 05:00:07PM +0800, Paul Wise 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.
One could argue that if there is information that is so useful it should
be available to the general public then it should be manually polished up
and published in designated places (documentation).

-- 
WBR, wRAR


--
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/20140225093420.ga21...@belkar.wrar.name



Re: State of the debian keyring

2014-02-25 Thread Enrico Zini
On Mon, Feb 24, 2014 at 06:51:37PM -0800, Russ Allbery wrote:

 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.

...which reminds me of http://www.enricozini.org/2008/tips/audit-uploads/
which was a prototype of creating an audit log of key usage in debian.

However, for the audit log to be usable as an audit log without giving a
false sense of security, it should be complete, and really cover all
instances of key usage in Debian.

This means hooking into any place where a signature verification or a
decryption actually happens in Debian: I can think of uploads,
db.debian.org, voting, keyring requests, RT tickets filed, emails
received by lists or the BTS: are there more?

I see the job as not so much technically complex[1] as socially complex:
since I would not trust auditing an incomplete audit log, I fear that a
missing or badly implemented data source could invalidate all the
system.

So I can't just open vim and write the code: auditing key usage in
package uploads requires someone who knows dak inside out, and can
commit to maintaining notification triggers in all obscure corners where
keys are used, now and in future updates of the ftp-master toolchain.
Same goes for any other bit of Debian.

The starting point for this work is probably this, then: is it just me,
feeling that we have a problem here, or am I actually in the good
company of people who can do their bit?


Ciao,

Enrico

[1] For realtime auditing, we now have a rabbitmq server. Or collection
could be decoupled in one audit log per team, which are then aggregated
by a separate project. Or they can be submitted to a central collection
point, like a new ad-hoc bit of contributors.debian.org. I don't see
anything technically difficult here.
-- 
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org


signature.asc
Description: Digital signature


Re: GR proposal: code of conduct

2014-02-25 Thread Matthias Urlichs
Hi,

Andrey Rahmatullin:
 One could argue that if there is information that is so useful it should
 be available to the general public then it should be manually polished up
 and published in designated places (documentation).
 
One could argue that the information / documentation is already readily
available at mulitple places, but the person who asks in the channel is
too inexperienced / lazy / stupid ^w clueless to actually find it.

We all have been guilty of all three of these, at one time or another.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature


Re: GR proposal: code of conduct

2014-02-25 Thread Paul Wise
On Tue, Feb 25, 2014 at 2:01 AM, Ian Jackson wrote:

 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) ?

Several of our derivatives (at least Maemo, Ubuntu) have public logs
of their IRC channels.

Personally I think it would bring some much needed transparency to
what is becoming one of the more essential Debian communication
channels to be on. Just like we archive mailing lists and record
DebConf talks/BoFs, we should publicly log IRC channels.

-- 
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: 
https://lists.debian.org/caktje6forwltdpj7z-wtzfarxqox0ojz7628kbwhqnwuqo3...@mail.gmail.com



Re: State of the debian keyring

2014-02-25 Thread Paul Wise
On Tue, Feb 25, 2014 at 5:47 PM, Enrico Zini wrote:

 This means hooking into any place where a signature verification or a
 decryption actually happens in Debian: I can think of uploads,
 db.debian.org, voting, keyring requests, RT tickets filed, emails
 received by lists or the BTS: are there more?

I didn't think the BTS cared about OpenPGP keys?

mentors.d.n does do signature verification of uploads.

-- 
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: 
https://lists.debian.org/CAKTje6HH4ZfhGyUX3BxuXx7f1w=f9qbrx9uo_enhslct5u0...@mail.gmail.com



Re: State of the debian keyring

2014-02-25 Thread Gunnar Wolf
Ian Jackson dijo [Mon, Feb 24, 2014 at 05:53:58PM +]:
 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.

Which we do anyway - All retired keys are still in our tree, in the
removed-keys-{pgp,gpg} directories (plus the
emeritys-keyring-{gpg,pgp}). Of course, they are not installed when
you get the generated package (you only get the active keyrings). But
they are all there.


-- 
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/20140225184458.gh40...@gwolf.org



Re: State of the debian keyring

2014-02-25 Thread Gunnar Wolf
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.

Debian tools don't care which key you use for email encryption. The
extent of actions you interact with debian is easily modeled with a
single key; for some time I used to upload with 1024D and sign mails
with 4096R because I had not yet pushed my 4096R into the keyring,
waiting to get more signatures (yes, also being keyring-maint it took
me some time to push it, even if I had all power to do so myself!)


-- 
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/20140225184724.gi40...@gwolf.org



Re: State of the debian keyring

2014-02-25 Thread Russ Allbery
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.

 Debian tools don't care which key you use for email encryption.

Except for project DPL votes, no?

 The extent of actions you interact with debian is easily modeled with a
 single key; for some time I used to upload with 1024D and sign mails
 with 4096R because I had not yet pushed my 4096R into the keyring,
 waiting to get more signatures (yes, also being keyring-maint it took me
 some time to push it, even if I had all power to do so myself!)

For email signatures, don't quite a few more things care?  All votes,
db.debian.org operations, etc.

-- 
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: https://lists.debian.org/87ios3auur@windlord.stanford.edu



Re: GR proposal: code of conduct

2014-02-25 Thread Lars Wirzenius
On Tue, Feb 25, 2014 at 06:28:39PM +0800, Paul Wise wrote:
 On Tue, Feb 25, 2014 at 2:01 AM, Ian Jackson wrote:
 
  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) ?
 
 Several of our derivatives (at least Maemo, Ubuntu) have public logs
 of their IRC channels.
 
 Personally I think it would bring some much needed transparency to
 what is becoming one of the more essential Debian communication
 channels to be on. Just like we archive mailing lists and record
 DebConf talks/BoFs, we should publicly log IRC channels.

I am generally in favour of more transparency. Logging official
project IRC channels would fit well with that.

However, I find that it's very difficult to extract useful information
from voluminous IRC logs, and official channels are likely to be
voluminous. The logs are hard to read, and there's so much irrelevant
discussion mixed with the parts that one is looking for that it is
much harder to find what one wants. IRC has no threading, so finding
the related parts of a discussion is not easy. This is a stark
contrast with, say, mailing lists.

Thus I suspect that the logs won't be very useful.

I would prefer a culture where IRC discussions are ephemeral, and any
useful information should end up in debian/changelog, mailing lists,
git commit messages, wiki.debian.org, or any of the other places where
we already put information.

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20140225190249.GF4722@holywood



Re: State of the debian keyring

2014-02-25 Thread Don Armstrong
On Tue, 25 Feb 2014, Paul Wise wrote:
 I didn't think the BTS cared about OpenPGP keys?

We probably will eventually, but we only use[1] them now to help
whitelist mail.
 

1: By which I mean that if a message seems to have a PGP signature, we
think it's probably not spam; we currently don't even bother to check
it.
-- 
Don Armstrong  http://www.donarmstrong.com

Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from. 
 -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_


-- 
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/20140225190806.gc10...@teltox.donarmstrong.com



Re: GR proposal: code of conduct

2014-02-25 Thread Matthias Urlichs
Hi,

Lars Wirzenius:
 I would prefer a culture where IRC discussions are ephemeral, and any
 useful information should end up in debian/changelog, mailing lists,
 git commit messages, wiki.debian.org, or any of the other places where
 we already put information.
 
I agree.

The second problem I have with IRC logs is that Google is likely to show
them if you search for the solution to some problem, partticularly if that
problem is asked about often.
However, I suspect that most users would extracting a solution from IRC
logs, assuming it is buried in there at all, to be very tedious.

-- 
-- Matthias Urlichs


-- 
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/20140225200136.ga24...@smurf.noris.de



Re: State of the debian keyring

2014-02-25 Thread Kurt Roeckx
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.
 
  Debian tools don't care which key you use for email encryption.
 
 Except for project DPL votes, no?

I think the keys are used for voting and the email interfance for
db.debian.org.  I'm not sure if we have any other services
checking the gpg signatures of emails.


Kurt


-- 
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/20140225201000.ga5...@roeckx.be



Re: State of the debian keyring

2014-02-25 Thread Jonathan McDowell
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: State of the debian keyring

2014-02-25 Thread Luca Filipozzi
On Tue, Feb 25, 2014 at 09:10:00PM +0100, Kurt Roeckx wrote:
 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.
  
   Debian tools don't care which key you use for email encryption.
  
  Except for project DPL votes, no?
 
 I think the keys are used for voting and the email interfance for
 db.debian.org.  I'm not sure if we have any other services
 checking the gpg signatures of emails.

echelon checks the keyring, also.

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


signature.asc
Description: Digital signature


Re: GR proposal: code of conduct

2014-02-25 Thread Paul Wise
On Wed, Feb 26, 2014 at 3:02 AM, Lars Wirzenius wrote:

 Thus I suspect that the logs won't be very useful.

Due to Debian being focussed in the European timezones, most of my use
of IRC is reading backlog, which is pretty much the same has reading
public logs. I still find IRC useful and even essential to be reading.

I've also found the public IRC logs of other distributions useful in
the past when I wanted to find out what was going on.

I've also extracted useful information from public IRC logs I found
via search engines.

 useful information should end up in debian/changelog, mailing lists,
 git commit messages, wiki.debian.org, or any of the other places where
 we already put information.

I don't think that is happening right now. It might be possible to do
this but I expect any effort to do so will end like the debian-private
declassification GR; with no-one to doing it.

-- 
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: 
https://lists.debian.org/CAKTje6ER8Nvx2s++4DrdT7cRJWH3hNFmTn3sSV=nz0g7dtr...@mail.gmail.com