RFC: Signed JAR Packaging Policy

[Rob Crittenden]

Gary Benson wrote:
> 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.

This is assuming that the jar we build is identical to the Mozilla jar 
without the signature, right?

How would we want to go about implementing Warren's idea? I assume we'd 
check in the Mozilla-signed jar as a source? Would this cause anyone 
major heartburn?

> 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.

But any random JVM that a user downloads from Sun or IBM directly 
wouldn't know about this extra endorsement, right? So any 
non-rpm-installed JVMs would still not work?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070313/bba2ab99/attachment.bin>