Robert Burrell Donkin wrote on Thu, Jun 30, 2011 at 08:31:38 +0100:
> On Tue, Jun 28, 2011 at 10:20 AM, Christian Grobmeier
> wrote:
> >>> we copy a KEYS file into that directory upon succesful VOTE of the release
> >>> artifacts (which also include the KEYS file).
> >>
> >> Perhaps, but the point
On Tue, Jun 28, 2011 at 10:20 AM, Christian Grobmeier
wrote:
>>> we copy a KEYS file into that directory upon succesful VOTE of the release
>>> artifacts (which also include the KEYS file).
>>
>> Perhaps, but the point we're getting at was explicitly stated by Benson,
>> "The goal here is to allow
Thanks Bertrand!
Cheers,
Chris
On Jun 28, 2011, at 1:29 AM, Bertrand Delacretaz wrote:
> On Mon, Jun 27, 2011 at 11:59 PM, Mattmann, Chris A (388J)
> wrote:
>> Yep, makes sense. Like I told Benson, I wasn't exactly sure if the mirroring
>> system were read only downstream of the Apache root so
Nick Kew wrote on Tue, Jun 28, 2011 at 14:13:51 +0100:
> As of now, how would you know if I were to smuggle in a key
> pretending to be yours and start signing things?
Don't stop here. If you can smuggle a signature into dist/ then
you can smuggle an artefact too.
-
On 28 Jun 2011, at 13:22, Benson Margulies wrote:
> There's another possible dimension to this, which is related to the
> 'Apache Key' suggestion.
>
> The current mechanism gives a\ sophisticated/ consumer tools to get
> some confidence that what they downloaded was, in fact, created by
> someon
There's another possible dimension to this, which is related to the
'Apache Key' suggestion.
The current mechanism gives a\ sophisticated/ consumer tools to get
some confidence that what they downloaded was, in fact, created by
someone in the Apache infrastructure.
If a dozen black hats create PG
I'm not sure what I think of your suggestion of having an "ASF PGP key".
How about requiring committers to specify on id.a.o not just the last
few bytes of their key's fingerprints, but the whole fingerprint?
Nick Kew wrote on Tue, Jun 28, 2011 at 11:43:24 +0100:
>
> On 28 Jun 2011, at 09:53, J
On 28 Jun 2011, at 10:49, Christian Grobmeier wrote:
>>> I would like to know how many signing keys are actually trusted which
>>> have been used for our releases.
>>
>> Quite a few, see http://people.apache.org/~henkp/trust/apache.html
Aaargh!
That needs a health warning: pointing firefox at
On 28 Jun 2011, at 09:53, Jukka Zitting wrote:
> Hi,
>
> On Tue, Jun 28, 2011 at 10:29 AM, Bertrand Delacretaz
> wrote:
>> Hence the need for people to download KEYS files from an *.apache.org
>> domain that we do control. Putting KEYS in a distribution might cause
>> people to use them instead
On Tue, Jun 28, 2011 at 12:22 PM, Daniel Shahaf wrote:
> Christian Grobmeier wrote on Tue, Jun 28, 2011 at 11:20:13 +0200:
>> >> we copy a KEYS file into that directory upon succesful VOTE of the release
>> >> artifacts (which also include the KEYS file).
>> >
>> > Perhaps, but the point we're get
Christian Grobmeier wrote on Tue, Jun 28, 2011 at 11:20:13 +0200:
> >> we copy a KEYS file into that directory upon succesful VOTE of the release
> >> artifacts (which also include the KEYS file).
> >
> > Perhaps, but the point we're getting at was explicitly stated by Benson,
> > "The goal here is
>> I would like to know how many signing keys are actually trusted which
>> have been used for our releases.
>
> Quite a few, see http://people.apache.org/~henkp/trust/apache.html
Interesting - thanks for the link.
So, 53% of our software is signed with untrusted keys. I have expected
70% untrust
Hi,
On Tue, Jun 28, 2011 at 11:16 AM, Christian Grobmeier
wrote:
> I would like to know how many signing keys are actually trusted which
> have been used for our releases.
Quite a few, see http://people.apache.org/~henkp/trust/apache.html
BR,
Jukka Zitting
>> we copy a KEYS file into that directory upon succesful VOTE of the release
>> artifacts (which also include the KEYS file).
>
> Perhaps, but the point we're getting at was explicitly stated by Benson,
> "The goal here is to allow and encourage consumers to independently verify
> signatures. Tha
>> Hence the need for people to download KEYS files from an *.apache.org
>> domain that we do control. Putting KEYS in a distribution might cause
>> people to use them instead of getting them from a trusted source, and
>> that's bad.
>
> The keys should be included in the web of trust, so it should
Hi,
On Tue, Jun 28, 2011 at 10:29 AM, Bertrand Delacretaz
wrote:
> Hence the need for people to download KEYS files from an *.apache.org
> domain that we do control. Putting KEYS in a distribution might cause
> people to use them instead of getting them from a trusted source, and
> that's bad.
T
On Mon, Jun 27, 2011 at 11:59 PM, Mattmann, Chris A (388J)
wrote:
> Yep, makes sense. Like I told Benson, I wasn't exactly sure if the mirroring
> system were read only downstream of the Apache root sources (IOW, I thought
> we had more control then in reality we did).
>
> BTW, if someone could
Hey Hyrum,
Thanks!
Cheers,
Chris
On Jun 27, 2011, at 7:24 PM, Hyrum K Wright wrote:
> On Mon, Jun 27, 2011 at 4:59 PM, Mattmann, Chris A (388J)
> wrote:
>> Yep, makes sense. Like I told Benson, I wasn't exactly sure if the mirroring
>> system were read only downstream of the Apache root so
On Mon, Jun 27, 2011 at 4:59 PM, Mattmann, Chris A (388J)
wrote:
> Yep, makes sense. Like I told Benson, I wasn't exactly sure if the mirroring
> system were read only downstream of the Apache root sources (IOW, I thought
> we had more control then in reality we did).
>
> BTW, if someone could p
Yep, makes sense. Like I told Benson, I wasn't exactly sure if the mirroring
system were read only downstream of the Apache root sources (IOW, I thought we
had more control then in reality we did).
BTW, if someone could point me to a document where this is described, that
would certainly help m
Chris,
This is related to why it also matters how you get and verify your browser.
If someone were to successfully distribute a build of Firefox or Chrome with
bogus root certs, they could potentially do a lot of damage.
--- Noel
Gotcha!
OK makes sense. I wasn't sure how the mirroring system worked, and whether or
not the mirrors were read-only downstream of the Apache source (I guess we
can't ensure that, right?)
If that's the case, then I'm +1 for what you're saying.
Cheers,
Chris
On Jun 27, 2011, at 1:48 PM, Benson
Mirrors.
Lots of non-apache people work for all those many companies that
operate all those many, many, mirrors.
On Mon, Jun 27, 2011 at 4:48 PM, Mattmann, Chris A (388J)
wrote:
> Hi Benson,
>
> On Jun 27, 2011, at 1:37 PM, Benson Margulies wrote:
>
>> Chris,
>>
>> If my goal was to hoodwink y
Hi Benson,
On Jun 27, 2011, at 1:37 PM, Benson Margulies wrote:
> Chris,
>
> If my goal was to hoodwink you, I'd create a bogus key that claimed to
> be owned by an Apache person, put it in a KEYS file, and include in
> the release, and sign the release with it. If I was lucky, you'd just
> veri
Chris,
If my goal was to hoodwink you, I'd create a bogus key that claimed to
be owned by an Apache person, put it in a KEYS file, and include in
the release, and sign the release with it. If I was lucky, you'd just
verify the release with the embedded key, and I'd have succeeded. We
want people t
On Jun 27, 2011, at 12:58 PM, Noel J. Bergman wrote:
>> we copy a KEYS file into that directory upon succesful VOTE of the release
>> artifacts (which also include the KEYS file).
>
> Perhaps, but the point we're getting at was explicitly stated by Benson,
> "The goal here is to allow and encoura
> we copy a KEYS file into that directory upon succesful VOTE of the release
> artifacts (which also include the KEYS file).
Perhaps, but the point we're getting at was explicitly stated by Benson,
"The goal here is to allow and encourage consumers to independently verify
signatures. That calls f
Hi All,
Just for clarification here (since Gora was specifically called out), we also
maintain KEYS files in
the podling dist directory as well. However, we copy a KEYS file into that
directory upon succesful
VOTE of the release artifacts (which also include the KEYS file). So it's not
either
It seems to me that KEYS in the release is somewhat counterproductive.
The goal here is to allow and encourage consumers to independently
verify signatures. That calls for KEYS somewhere else than inside the
package.
On Mon, Jun 27, 2011 at 7:10 AM, Daniel Shahaf wrote:
> Jukka Zitting wrote on M
Jukka Zitting wrote on Mon, Jun 27, 2011 at 11:07:11 +0200:
> Hi,
>
> On Mon, Jun 27, 2011 at 6:32 AM, Noel J. Bergman wrote:
> > It seems to me to be a bad idea to distribute keys with releases. And don't
> > we already have some ASF-wide policy for managing keys?
>
> http://www.apache.org/dev
Hi,
On Mon, Jun 27, 2011 at 6:32 AM, Noel J. Bergman wrote:
> It seems to me to be a bad idea to distribute keys with releases. And don't
> we already have some ASF-wide policy for managing keys?
http://www.apache.org/dev/release-signing.html#keys-policy
http://incubator.apache.org/guides/relea
+1
KEYS should not be distributed with a release, even if the central key
infrastructure is not used, at least release manager should point
people checking the release to where they can find the KEYS so they
can check release signatures, which is normally the way used with most
of the projects I
> It seems to me to be a bad idea to distribute keys with releases.
+1
> And don't
> we already have some ASF-wide policy for managing keys?
I don't know if there is a policy, but I recently found this:
http://people.apache.org/foaf/index.html
"PGP keys may additionally be added to your profile
It seems to me to be a bad idea to distribute keys with releases. And don't
we already have some ASF-wide policy for managing keys?
--- Noel
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additi
34 matches
Mail list logo
