On Mon, 2008-09-22 at 09:34 -0400, Hiram Chirino wrote:
> The only reason I suggested including the sigs in the source distro is
> because a source build like Apache ServiceMix depends on hundreds of
> third party dependencies.. so an end user would need to end up
Yes. Now you are getting closer.
> trusting LOTs different signatures to get ServiceMix to build.
Right. You already have to do that today. Only you don't do it. And you
do trust Maven not to pull any compromised artifact as a four-levels
removed dependency. IAW, you are already in that hell, only Maven hides
it from you.
> It would be easier if the end user could just trust the Apache source
> distro and also transitively trust the signatures that we trust for
> our dependencies.
And that does not work. What is the "Apache source distro"? And whom do
you trust? Consider the following case (if you look really, really
close, you might find similarities to existing projects):
The "Apache Foo" project has a stable release for a long time. This
release was signed by a developer well connected to the Apache web of
trust and so it was possible to somewhat verify that this distribution
is genuine. The project went from stable to dormant. After two years, a
new crop of committers was voted in and started to work on that project
again. They decided to release a new and improved version, ran through
all the Apache release process and the developer finall doing the
release used his new, shiny and nice "[EMAIL PROTECTED] (Code Signing Key)"
key to sign this release. However, as he never has visited an Apache
Keysigning event yet and is BTW living in Juneau, Alaska, his key is not
at all connected to the Apache web of trust. But this new version
contains a number of bug fixes that the dependees have waited for a long
long time. So they eagerly changed their Maven poms."
How do you verify, that the release that Maven has just downloaded from
a maven repo mirror is really this new release and not a hacked one?
Or worse:
You have, for any reason, two different versions from two repo mirrors,
both are signed by "[EMAIL PROTECTED] (Code Signing Key)" with different
fingerprints. www.apache.org is down or unreachable (think airplane).
Which one do you trust?
Another scenario:
You have two different versions from two repo mirrors, both are signed
by "[EMAIL PROTECTED] (Code Signing Key)" with the same fingerprint.
Which one do you trust? [1]
a) When asking "[EMAIL PROTECTED]", he confesses that he lost an USB-stick
with his secret key a few months ago. He thought it fell from the ferry
last time he went back home to Juneau, Alaska and was lost.
b) When asking "[EMAIL PROTECTED]", he confesses that he made a mistake
while cutting the release and quickly uploaded a corrected version. He
is reasonably sure, that no-one ever saw the first one.
None of these scenarios are invented. Each of them has happened in the
past (or is bound to happen at some point in the future).
Face it: To get a *reliable* verification of signatures, an arbitrary
web of trust does not work. That is why trust centers have root
certificates and hand them out to browser distributors like candy. So
you have a base line that you can trust from an independent source.
And again, there is no "high nineties" security. Your solution is either
secure or it is not. And the Jackpot of being able to open a backdoor in
*every* application around the planet that e.g. pulls in
commons-collections at some point through Maven is too good to assume
that it will never happen. Many banks use Java software. I'd assume that
every bank using Java software has a commons-collections or commons-lang
stashed away somewhere.
>
> The end user would still need to manually validate the source distro
> signature.
I assume that only a very very small number of "end users" knows that
there is source code, will ever download it or knows how to verify it.
Ciao
Henning
[1] For the answer "the one that is on www.apache.org/dist" will buy you
the question "So you assume that www.apache.org can not be hacked?"
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
