On Tue, May 10, 2011 at 08:19:27AM +0200, "Paweł Hajdan, Jr." wrote:
> On 5/10/11 4:08 AM, Jim Ramsay wrote:
> > - Does this tree signing key have to be DSA? Or is RSA okay too?
>
> No idea, I'd probably just try and see if signing works.
/me plugs his ears and presses "GO"...
Looks like it wor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/10/11 02:19, "Paweł Hajdan, Jr." wrote:
> On 5/10/11 4:08 AM, Jim Ramsay wrote:
>> - Does this tree signing key have to be DSA? Or is RSA okay too?
>
> No idea, I'd probably just try and see if signing works.
>
>> - If I have a key already, sh
On 5/10/11 4:08 AM, Jim Ramsay wrote:
> - Does this tree signing key have to be DSA? Or is RSA okay too?
No idea, I'd probably just try and see if signing works.
> - If I have a key already, should I generate a new subkey just
> for manifest signing, make a whole new primary key, or just use
>
On Fri, Mar 25, 2011 at 02:30:20PM -0400, Mike Frysinger wrote:
> for people who dont have a key yet:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=6
I'm pretty new to advanced gpg usage and management, and so had a
couple questions not answered by that page:
- Does thi
On Fri, 25 Mar 2011 10:44:31 +0100
"Andreas K. Huettel" wrote:
> * the signature proves the key belongs to the e-mail address, nothing
> else
Anyone could generate a signature with one of my @g.o e-mail addresses
in it, then pass themselves off as myself, right? If they then trick you
into think
On 03/27/2011 22:47, Kumba wrote:
> Rather than mounting an expedition to find it, it's probably easier for me to
> generate a new key, but this raises a few questions, because I'm a complete
> idiot when it comes to GPG/PGP stuff:
This is all fixed. My new key is published, but the old one will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2011 08:13 PM, Robin H. Johnson wrote:
> On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote:
>> 3) Rely on an existing key list somewhere distributed in portage; the list
>> file with the key id's (not the keys themselves) is
On 2011-03-28 2:54 PM, Rich Freeman wrote:
>> 3. If I'm going to start using GPG, I might as well use it for a few things.
>> Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows?
>
> Enigmail. Haven't actually used it on windows but it is pretty
> transparent and I believe it
On Sun, Mar 27, 2011 at 10:47 PM, Kumba wrote:
> 1. How can I revoke the old key? The revocation cert is probably on the
> same drive.
You can't. You need the private key to generate a revocation
certificate. The best you might be able to do is ask keyserver admins
to remove it manually, or tr
On 3/28/11 2:05 AM, Robin H. Johnson wrote:
> I see so many bad ideas mentioned in this thread. The suggestions to
> keep a gpg-agent with a very long passphrase TTL just provides a massive
> new security hole:
> ===
> Attacker breaks into developer's system, has access to SSH agent and GPG
> agen
> > 3)
> 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids)
> 2. Clear-sign L, produces L'
> 3. Include L' in /metadata/ during rsync content build.
> 3.1. Provide all L' files in a trusted Git repository for historical
> reference.
> 4. Tree-sign per GLEP58, such that sign
On 03/25/2011 14:30, Mike Frysinger wrote:
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/36046
On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote:
> 3) Rely on an existing key list somewhere distributed in portage; the list
> file with the key id's (not the keys themselves) is signed with a master key.
> Is a mediocre and potentially insecure workaround.
> Pros: you can exac
On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote:
> 3) Rely on an existing key list somewhere distributed in portage; the list
...
> Cons: Mainly that the key id is a pretty short hash afaik.(Any
> better-informed
> people around?)
You can use the long-format key IDs if you wan
> first off, fix your e-mail client. this long line crap is ridiculous.
:) ever heard of flowed text? absolutely no need to get aggressive...
> second, anyone can add/remove e-mail addresses. we arent verifying
> e-mail addresses, we're verifying keys.
Unfortunately you are misunderstanding
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
> > 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
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
> 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
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 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
-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 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 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
> > 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 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
-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
> > * 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
On Thu, Mar 24, 2011 at 6:47 PM, Diego Elio Pettenò wrote:
> Il giorno gio, 24/03/2011 alle 23.42 +0100, Rémi Cardona ha scritto:
>> However, is there a howto or something explaining how to work
>> _efficiently_ with GPG? How do I avoid having to type my pass-phrase
>> for every commit?
>
> Setup g
Il giorno gio, 24/03/2011 alle 23.42 +0100, Rémi Cardona ha scritto:
>
>
> However, is there a howto or something explaining how to work
> _efficiently_ with GPG? How do I avoid having to type my pass-phrase
> for
> every commit?
Setup gpg-agent with a one-week passphrase caching and standard so
http://bugs.gentoo.org/360363
-mike
48 matches
Mail list logo
