How to verify Jackrabbit binaries

[Thomas Mueller <th...@gmail.com>]

Hi,

>  WE DON'T VOTE ON BINARIES.  We CAN'T vote on binaries.

I didn't mean we should vote on binaries.  Sorry I should have started
a new thread.

> Don't waste your abilities on
> testing binaries when we need them to test the source code.

I agree, testing the source code is more important.

>  Apache's users download the source code and build from source.
>  Jukka's users may just run the binaries.

My concern is Jukka's users. We can do a few things to verify the
binaries. What could go wrong is:

1) The wrong source code was used by mistake
2) A wrong compiler setting was used (JDK 1.6 instead of JDK 1.4)
3) The release machine could be infected with a virus that is added to
the binaries
4) After uploading, a hacker replaced the files and checksums

Item 1, 2, and 3 can be verified if I build Jackrabbit myself and
compare the binaries when releasing. I just need to use the same JVM
and release process.

Item 4: Download mirrors could cross-check each other. Are they doing
that? Another idea is to set up a daemon somewhere that downloads
Jackrabbit from time to time and compares against the initial set of
files (and sends a mail if there is a problem). Is there a service
somewhere that does that?

Again, it's not urgent, but maybe when we have time to improve the
release process we find a solution for that as well. But maybe I am
just too paranoid.

Regards,
Thomas

Re: How to verify Jackrabbit binaries

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Apr 22, 2008 at 11:27 AM, Thomas Mueller
<th...@gmail.com> wrote:
>  4) After uploading, a hacker replaced the files and checksums
>  [...]
>  Item 4: Download mirrors could cross-check each other. Are they doing
>  that? Another idea is to set up a daemon somewhere that downloads
>  Jackrabbit from time to time and compares against the initial set of
>  files (and sends a mail if there is a problem). Is there a service
>  somewhere that does that?

That's why the download pages point people to get the checksums from
www.apache.org instead of one of the mirrors. A hacker would need to
compromise www.apache.org to break the checksums. And even then the
attacker couldn't fake the GPG signatures bound to the Apache web of
trust.

I'd be more concerned about 3 (or other attacks targetting the RM) as
a potential attack vector against our users, but frankly I think the
risk for that is insignificant.

BR,

Jukka Zitting