On 2011-03-25 1:59 PM, Dane Smith wrote:
> Having said that, for those that just use "keys" for e-mails (most of
> us), it would make more sense to use full blow SSL certs in the long run.
Please no. PKI is a naive design and for all intents and purposes will
remain a pipe-dream. All security re
On Fri, Mar 25, 2011 at 10:38 PM, Alec Warner wrote:
> Coming back around to the earlier discussion of Alice who has her key
> signed by robbat2 (because he loves keysigning parties) and then Alice
> breaks into cvs.gentoo.org and commits evil code into the tree. If we
> cannot stop this attack be
On Fri, Mar 25, 2011 at 7:28 PM, Mike Frysinger wrote:
> On Fri, Mar 25, 2011 at 2:57 PM, Dane Smith wrote:
>> On 03/25/2011 02:46 PM, Mike Frysinger wrote:
>>> On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
Of course now we can add additional requirements:
* The key mus
On Fri, Mar 25, 2011 at 4:33 PM, Andreas K. Huettel wrote:
>> and no where do we require you to generate a gpg key bound to the
>> Gentoo e-mail address. we require you to provide a gpg key only.
>> like you said *right here*, we have 0 information to identify you, and
>> using a Gentoo e-mail add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/11 17:02, Mike Frysinger wrote:
> once we move to git, the workflow for proxy maintainers is going to be
> a lot smoother. the question is how to handle signing with proxy
> maintainers.
>
> it would be nice if said proxied maintainers would
once we move to git, the workflow for proxy maintainers is going to be
a lot smoother. the question is how to handle signing with proxy
maintainers.
it would be nice if said proxied maintainers would sign things and
that would be preserved all the way to the push to the common server.
pros:
- Ge
> > So what sort of identity do you want to verify? Seriously, at the moment
> > when I got my commit bit, noone from Gentoo had ever met me in person, and
> > for sure noone had ever had a look at my passport or any similar legal
> > document. The only established connection was my preexisting
# Thomas Beierlein (25 Mar 2011)
# Masked for removal.
# No longer required by sci-electronics/geda.
# Removal in 30 days.
sci-libs/libgeda
--
On Fri, Mar 25, 2011 at 3:57 PM, Andreas K. Huettel wrote:
> The @gentoo.org email addresses are advantageous because they provide a
> pre-existing identification. Which is as strong as we will ever get with this
> mechanism (I think).
no, it really doesnt. when we make someone a dev, they give
On Fri, Mar 25, 2011 at 3:50 PM, Andreas K. Huettel wrote:
>> > * The key must have an userid that refers to an official Gentoo e-mail
>> > address. E.g. dilfri...@gentoo.org
>>
>> no. there's no reason for this requirement, and it prevents proxy
>> maintenance long term. e-mail addresses do not
On Fri, Mar 25, 2011 at 12:35 PM, Robin H. Johnson wrote:
> Also, I propose we change the suggested validity time to 1 or 2 years,
sounds reasonable to me. ive been 1 year for a while anyways as the 6
month one got to be annoying.
-mike
> The SKS rotation seems to be much better, and kingtaco was looking at
> running an additional SKS instance within Gentoo as our offical key
> point (also useful for speeding up fetching keys in verification).
Good idea.
--
Andreas K. Huettel
Gentoo Linux developer - kde, sci, arm, tex
dilfri..
> > Do you want to reject signed commits if
> > - keys are not publicly available [1]
>
> no. e-mail warnings will be issued so that the dev can upload it
> after the fact.
Why? I'm pretty sure someone will forget. (Or try to trick the system.)
> > - keys are revoked [3]
>
> yes
Only if the s
> > * The key must have an userid that refers to an official Gentoo e-mail
> > address. E.g. dilfri...@gentoo.org
>
> no. there's no reason for this requirement, and it prevents proxy
> maintenance long term. e-mail addresses do not verify identity,
> verifying identify verifies identity. this
> i dont expect the rejection to go into effect $now, so people not
> signing have plenty of time to start doing so
Is the additional effort of implementing this for CVS with the current
two-stage commit even worth it?
I.e. would it not make more sense to wait _with the automated rejection_ unti
> > -) Extend expiry date and upload again?
>
> i wasnt aware you could extend the expiration date of a key. that
> sort of defeats the purpose of having an expiration date doesnt it ?
> then someone could steal your expired key, extend the date, and keep
> using it.
The expiration date is a pro
On Fri, Mar 25, 2011 at 2:57 PM, Dane Smith wrote:
> On 03/25/2011 02:46 PM, Mike Frysinger wrote:
>> On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
>>> Of course now we can add additional requirements:
>>>
>>> * The key must have an userid that refers to an official Gentoo e-mail
>>> a
On Fri, Mar 25, 2011 at 10:47:19AM +0100, Thomas Kahle wrote:
> Hi,
>
> it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
> the validity should be <6 month. What is the protocol when the expiry
> date is approaching?
>
> -) Extend expiry date and upload again?
Extend it and
On Fri, Mar 25, 2011 at 02:36:14PM -0400, Mike Frysinger wrote:
> > To facilitate this, should we pick a preferred keyserver or two? Devs
> > of course are welcome to use others also, but if we're going to check
> > for revocations, we should specify where devs should upload them to in
> > order t
On Fri, Mar 25, 2011 at 5:47 AM, Thomas Kahle wrote:
> it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
> the validity should be <6 month. What is the protocol when the expiry
> date is approaching?
>
> -) Extend expiry date and upload again?
i wasnt aware you could extend
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2011 02:46 PM, Mike Frysinger wrote:
> On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
>> Of course now we can add additional requirements:
>>
>> * The key must have an userid that refers to an official Gentoo e-mail
>> address. E.g
On Fri, Mar 25, 2011 at 10:53 AM, Andreas K. Huettel wrote:
>> > it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2
>> > that the validity should be <6 month. What is the protocol when the
>> > expiry date is approaching?
>>
>> I'd say that should be changed. With keys changing eve
On Fri, Mar 25, 2011 at 4:53 AM, Andreas K. Huettel wrote:
> Of course now we can add additional requirements:
>
> * The key must have an userid that refers to an official Gentoo e-mail
> address. E.g. dilfri...@gentoo.org
no. there's no reason for this requirement, and it prevents proxy
maintena
On Fri, Mar 25, 2011 at 6:11 AM, Peter Volkov wrote:
> В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
>> is there any reason we should allow people to commit unsigned
>> Manifest's anymore ?
>
> Why? Without policy on how we do that and more importantly how we check
> that signing makes no
On Fri, Mar 25, 2011 at 2:33 PM, Rich Freeman wrote:
> On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote:
>>> - keys are revoked [3]
>>
>> yes
>
> To facilitate this, should we pick a preferred keyserver or two? Devs
> of course are welcome to use others also, but if we're going to check
> for
On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote:
>> - keys are revoked [3]
>
> yes
>
To facilitate this, should we pick a preferred keyserver or two? Devs
of course are welcome to use others also, but if we're going to check
for revocations, we should specify where devs should upload them
On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote:
> we might want to add an automatic e-mail warning to the developer when
> their key is about to expire (like 1 week).
on 2nd thought, no need. we'll let repoman handle it locally.
-mike
for people who dont have a key yet:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6
for people interested, bugs to get repoman extended to make the gpg
process smoother:
http://bugs.gentoo.org/360459
http://bugs.gentoo.org/360461
-mike
On Fri, Mar 25, 2011 at 10:33 AM, Michał Górny wrote:
> On Fri, 25 Mar 2011 08:15:32 +0100 Torsten Veller wrote:
>> - keys are revoked [3]
>
> How about manifests signed before the key was revoked?
you cant do this at commit time (computers cant predict the future),
so it has no bearing on the ori
On Fri, Mar 25, 2011 at 3:15 AM, Torsten Veller * Mike Frysinger :
>> On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> [Manifest signing]
>> > Does that get us any closer to GLEPs 57, 58, 59 (or generally
>> > approaching the tree-signing/verifying group of problems)?
>>
>> yes
>
> I thin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2011 11:04 AM, "Paweł Hajdan, Jr." wrote:
> On 3/25/11 3:43 PM, Michał Górny wrote:
>> How about Gentoo Foundation funding devs a full blown X509 client
>> certs?
>
> Let's get signing and verifying working first, and then consider
> anything
On 3/25/11 3:43 PM, Michał Górny wrote:
> How about Gentoo Foundation funding devs a full blown X509 client
> certs?
Let's get signing and verifying working first, and then consider
anything that requires funding.
signature.asc
Description: OpenPGP digital signature
> > it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2
> > that the validity should be <6 month. What is the protocol when the
> > expiry date is approaching?
>
> I'd say that should be changed. With keys changing every half a year,
> we're soon going to have a tree spammed with M
> > Having said that, for those that just use "keys" for e-mails (most of
> > us), it would make more sense to use full blow SSL certs in the long
> > run. (Mathematically, same thing. But a cert needs to be signed by a
> > CA, and we should ideally maintain a Gentoo CA.) I need to get up to
> > sp
> > Do you want to reject signed commits if
> > - keys are not publicly available [1]
>
> We'll need to define what does 'public availability' exactly mean? Does
> that mean a specific keyserver?
Good point. Although most keyservers synchronize each other, it might make
sense to define an additi
> > * The key must have an userid that refers to an official Gentoo
> > e-mail address. E.g. dilfri...@gentoo.org
>
> I think this is pretty useless assuming we're already wanting
> to limit the amount of keys trusted to a specific list.
See the remark in a separate sub-thread about signing...
D
On Fri, 25 Mar 2011 10:47:19 +0100
Thomas Kahle wrote:
> it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2
> that the validity should be <6 month. What is the protocol when the
> expiry date is approaching?
I'd say that should be changed. With keys changing every half a year,
w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 25 Mar 2011 07:59:49 -0400
Dane Smith wrote:
> Having said that, for those that just use "keys" for e-mails (most of
> us), it would make more sense to use full blow SSL certs in the long
> run. (Mathematically, same thing. But a cert needs t
On Fri, 25 Mar 2011 08:15:32 +0100
Torsten Veller wrote:
> Do you want to reject signed commits if
> - keys are not publicly available [1]
We'll need to define what does 'public availability' exactly mean? Does
that mean a specific keyserver?
> - keys are revoked [3]
How about manifests signed
On Fri, 25 Mar 2011 09:53:01 +0100
"Andreas K. Huettel" wrote:
> Of course now we can add additional requirements:
>
> * The key must have an userid that refers to an official Gentoo
> e-mail address. E.g. dilfri...@gentoo.org
I think this is pretty useless assuming we're already wanting
to lim
On 23:48 Thu 24 Mar , Christoph Mende wrote:
> Index: mono.eclass
> ===
> RCS file: /var/cvsroot/gentoo-x86/eclass/mono.eclass,v
> retrieving revision 1.13
> diff -u -b -B -r1.13 mono.eclass
> --- mono.eclass 8 Mar 2009 15:46
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2011 07:55 AM, "Paweł Hajdan, Jr." wrote:
> On 3/24/11 10:59 PM, Mike Frysinger wrote:
>> is there any reason we should allow people to commit unsigned
>> Manifest's anymore ? generating/posting/enabling a gpg key is
>> ridiculously easy and
On 3/24/11 10:59 PM, Mike Frysinger wrote:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ? generating/posting/enabling a gpg key is
> ridiculously easy and there's really no excuse for a dev to not have
> done this already.
Firstly, I'm excited we're moving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2011 05:44 AM, Andreas K. Huettel wrote:
>>> * The key should be signed by some central instance for automated
>>> validity check.
>>>
>>> Here things get hairy. How about having recruiter/infra team sign a dev's
>>> key on completion of the r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2011 05:47 AM, Thomas Kahle wrote:
> Hi,
>
> it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
> the validity should be <6 month. What is the protocol when the expiry
> date is approaching?
>
> -) Extend expiry date an
On Friday 25 March 2011 11:11:12 Peter Volkov wrote:
> В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
> > is there any reason we should allow people to commit unsigned
> > Manifest's anymore ?
>
> Why? Without policy on how we do that and more importantly how we check
> that signing makes
On Fri, 2011-03-25 at 10:55 +0100, Antoni Grzymala wrote:
> Thomas Kahle dixit (2011-03-25, 10:47):
>
> > it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
> > the validity should be <6 month. What is the protocol when the expiry
> > date is approaching?
>
> “After size com
В Чтв, 24/03/2011 в 17:59 -0400, Mike Frysinger пишет:
> is there any reason we should allow people to commit unsigned
> Manifest's anymore ?
Why? Without policy on how we do that and more importantly how we check
that signing makes no sense...
--
Peter.
Thomas Kahle dixit (2011-03-25, 10:47):
> it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
> the validity should be <6 month. What is the protocol when the expiry
> date is approaching?
“After size comes the expiration date. Here smaller is better, but most
users can go fo
Hi,
it says here http://www.gentoo.org/doc/en/gnupg-user.xml#doc_chap2 that
the validity should be <6 month. What is the protocol when the expiry
date is approaching?
-) Extend expiry date and upload again?
-) Create new key (and sign with ?? ) ?
Cheers,
Thomas
--
Thomas Kahle
http://dev.gent
> > * The key should be signed by some central instance for automated
> > validity check.
> >
> > Here things get hairy. How about having recruiter/infra team sign a dev's
> > key on completion of the recruitment process? Just a first thought...
>
> I think this is an important requirement howeve
Torsten Veller dixit (2011-03-25, 08:15):
> * Mike Frysinger :
> > On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> [Manifest signing]
> > > Does that get us any closer to GLEPs 57, 58, 59 (or generally
> > > approaching the tree-signing/verifying group of problems)?
> >
> > yes
>
> I t
Andreas K. Huettel dixit (2011-03-25, 09:53):
> > Do you want to reject signed commits if
> > - keys are not publicly available [1]
>
> Yes, since that defies the purpose of the signature.
>
> > - signatures are from expired keys [2]
>
> Yes if the signature was made after expiration. (Dont kno
>
> Do you want to reject signed commits if
> - keys are not publicly available [1]
Yes, since that defies the purpose of the signature.
> - signatures are from expired keys [2]
Yes if the signature was made after expiration. (Dont know if that is even
possible.)
No if the signature was made
On 03/25/11 15:15, Torsten Veller wrote:
> * Mike Frysinger :
>> On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
> [Manifest signing]
>>> Does that get us any closer to GLEPs 57, 58, 59 (or generally
>>> approaching the tree-signing/verifying group of problems)?
>>
>> yes
>
> I think, it's
* Mike Frysinger :
> On Thu, Mar 24, 2011 at 8:09 PM, Antoni Grzymala wrote:
[Manifest signing]
> > Does that get us any closer to GLEPs 57, 58, 59 (or generally
> > approaching the tree-signing/verifying group of problems)?
>
> yes
I think, it's a "no".
The MetaManifest GLEP relies on a signed t
56 matches
Mail list logo
