RFC: Signed JAR Packaging Policy

[Gary Benson]

Jesse Keating wrote:
> On Monday 12 March 2007 17:02:06 Matthew Miller wrote:
> > On Mon, Mar 12, 2007 at 04:57:45PM -0400, Warren Togami wrote:
> > > Why this is bad?
> > > It still is not fully reproducible in a sense that other
> > > people can't take our source, modify it slightly, and make
> > > a Sun-blessed JSS JAR.
> >
> > I'm really against it. At the very least, it screws over
> > CentOS. This a bad path to be going down.
> >
> > I'd much prefer gcj and the future Fedora-shipped implementation
> > of the Sun JVM to make it easy to use self-generated certificates.
> > If someone wants to install a proprietary JVM, let's make _that_
> > the hard case.
> 
> I agree.  How much fun would it be if apache suddenly decided to not
> function with self signed certs and any cert you used had to come
> from verasign ?

It's not the same thing.  With httpd each user generates their own
certificate.  With signed jarfiles it'd be one key for all of Fedora.
And signing with a key you then distribute provides no security at
all.

I'd argue that Warren's two-step build doesn't screw over CentOS, or
anyone else for that matter.  Anyone wanting to rebuild could simply
rebuild (steps 3-5).  Anyone wanting to modify would get their own key
from Sun and do the full two-step thing (steps 1-5).  There's even a
refinement in that jarfile signatures are not rigidly bound to their
jars, so rather than shipping an entire jar in the source rpm we could
simply bundle the signature information and insert that into the jar
we built.

Of course, this is only required to support users running proprietary
JVMs.  GCJ doesn't check signatures, and we can disable checks in any
other JVM we ship in Fedora.  It doesn't even have to be a complete
disablement either.  It's not so much that the code must be signed as
that the code must be loaded from a trusted source.  Currently there's
no distinction between the two, but there's nothing stopping us from
introducing other trusted sources.  There is already the endorsed
standards override mechanism that basically states that code loaded
from specific system- and user-defined directories is considered to
be "endorsed" and therefore allowed to override core system classes.
We could mirror this and have it that code loaded from specific
directories be considered to be trusted.

Cheers,
Gary