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
-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, should I
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 works fine!
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=2chap=6
I'm pretty new to advanced gpg usage and management, and so had a
couple questions not answered by that page:
- Does this
On Fri, 25 Mar 2011 10:44:31 +0100
Andreas K. Huettel dilfri...@gentoo.org 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
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 signed list
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
agent
On Sun, Mar 27, 2011 at 10:47 PM, Kumba ku...@gentoo.org 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
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
-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 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
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 want.
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 exactly
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=2chap=6
for people interested, bugs to get repoman extended to make the gpg
process smoother:
http://bugs.gentoo.org/360459
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 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
-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 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
* 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
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
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 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
-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 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.
* 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 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
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
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 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 gpg-agent
44 matches
Mail list logo
