* Mike Frysinger vap...@gentoo.org:
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
On 03/25/11 15:15, Torsten Veller wrote:
* Mike Frysinger vap...@gentoo.org:
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,
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
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 know if that
Torsten Veller dixit (2011-03-25, 08:15):
* Mike Frysinger vap...@gentoo.org:
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
* 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 however it's
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
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 for a
В Чтв, 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.
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 comes the
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 no
-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 and
-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 recruitment
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 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 there's
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:54
On Fri, 25 Mar 2011 09:53:01 +0100
Andreas K. Huettel dilfri...@gentoo.org 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
On Fri, 25 Mar 2011 08:15:32 +0100
Torsten Veller ml...@veller.net 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 25 Mar 2011 07:59:49 -0400
Dane Smith c1p...@gentoo.org 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
On Fri, 25 Mar 2011 10:47:19 +0100
Thomas Kahle to...@gentoo.org 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
* 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...
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 additional
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
speed with
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 Manifests
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
-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 that
On Fri, Mar 25, 2011 at 3:15 AM, Torsten Veller ml-en@veller.wrote:
* Mike Frysinger vap...@gentoo.org:
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
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
for people who dont have a key yet:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=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 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
On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger vap...@gentoo.org 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
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 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 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
maintenance
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 every half a
-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 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 the
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 make
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 to make
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
address. E.g.
-) 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 property
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_ until
* 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 is the
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 signature
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
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
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 verify
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
# Thomas Beierlein tom...@gentoo.org (25 Mar 2011)
# Masked for removal.
# No longer required by sci-electronics/geda.
# Removal in 30 days.
sci-libs/libgeda
--
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 gpg
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:
-
-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
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 address
On Fri, Mar 25, 2011 at 7:28 PM, Mike Frysinger vap...@gentoo.org 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
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
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
Hi Zac (et al),
while this problem occurs on AIX only (for now?), I doubt this problem is
introduced in prefix-portage.
With recent prefix-portage-2.2.01.18125 (Fabian, how do you calculate the
version numbers since moving to git?), the EbuildProcess spits this
every now and then during emerge
On 25-03-2011 09:21:27 +0100, Michael Haubenwallner wrote:
Hi Zac (et al),
while this problem occurs on AIX only (for now?), I doubt this problem is
introduced in prefix-portage.
With recent prefix-portage-2.2.01.18125 (Fabian, how do you calculate the
version numbers since moving to
58 matches
Mail list logo
