Community
Participate
Working Groups
An integration of the jarsigner and the keytools would be nice. It could be made in two main steps. 1. An option in the JAR-Export to simple sign the JAR with an previous external created key. So people should create their keys seperate by command line to use them. 2. A "module" or maybe a plugin integrated into Eclipse to create/delete and manage keys.
agreed, that it would be nice, but can't be done for 2.0 unless we get external help.
[jar creation]
Nothing planned for 2.1 unless someone provides code/patch
Chaning state from assigned later to resolved later. Assigned later got introduced by the last bug conversion and is not a supported Eclipse bug state.
I have recently implemented a jar signer and would be willing to integrate it into eclipse. It is currently a standalone application, but shouldn't be too hard to adapt to JarBuilder and JarWriter3. It has no references to any internal Sun packages, so should run on any 1.4 JRE. Would it be possible to re-open this issue and consider the contribution? Also, any help you could provide with integrating into the existing jar export would also be greatly appreciated. Signed jars have a unique requirement for needing to read files twice, once for the digests and once when adding to the final jar. This doesn't fit so well with the current implementation. A possible solution would be to just write the jar out once, then post process it, but this is pretty inefficient.
(In reply to comment #5) > I have recently implemented a jar signer and would be willing to integrate it > into eclipse. It is currently a standalone application, but shouldn't be too > hard to adapt to JarBuilder and JarWriter3. Can I try this application? It's not a plugin, correct? > It has no references to any > internal Sun packages, so should run on any 1.4 JRE. Does it call the external jarsign tool, or is this all implemented in Java? > Would it be possible to re-open this issue and consider the contribution? Sure. > Also, any help you could provide with integrating into the existing jar export > would also be greatly appreciated. Signed jars have a unique requirement for > needing to read files twice, once for the digests and once when adding to the > final jar. This doesn't fit so well with the current implementation. A > possible solution would be to just write the jar out once, then post process > it, but this is pretty inefficient. Sure I can help. But be aware, that if this requires to change existing API we would have to integrate it before M5, which means till end of January the latest.
Created attachment 86390 [details] prototype jar signer I have attached the prototype jar signer. So far it is a standalone application (you all params are hard coded right now). The program can be run from the JarSigner class (this is where the params are hard coded) Although it is functional, it is clearly a prototype the following things are outstanding: 1. No unit tests at all 2. Various suspected bugs in the BER encoder (especially with encoding negative integers) 3. Some unfinished types in the BER encoder (unused by the jar signer) 4. Some fields are not being populated (or encoded), such as the hash algorithm properties 5. Support the 'internalsf' param (just places the signature file in the signature block's data section) 6. Supplied certificate chain is not being checked for expiration or anything 7. Add support for progress monitoring I think it might make sense to convert the BER encoder into an OSGi bundle so it can be used by any future equinox security work that needs to encode stuff. The BER decoder from equinox could be added to the bundle too.
(In reply to comment #7) > Created an attachment (id=86390) [details] > prototype jar signer > > I have attached the prototype jar signer. So far it is a standalone > application (you all params are hard coded right now). The program can be run > from the JarSigner class (this is where the params are hard coded) Thank you! Wow, this looks super complex: -Do you have a link to some specification for the jar signing? -Doesn't a open source BER encoder Java implementation already exist (inside or outside of eclipse) which we could reuse? All the array copies look inefficient to me. I agree with you that JDT seams to be the wrong place for such functionality. -Did you write all this code yourself? We certainly will need legal approval to integrate this. -Please be aware that, in order to integrate this into JDT, the code must be converted to Java 1.4.
unfortunately, most of the code is all mine :( The bas64 encoder was coped from org.eclipse.osgi (they have a ber decoder too). Some of the PKCS7 constants were also copied from org.eclipse.osgi. Any class that was a copy should have the eclipse header. All new stuff has no header at all. There isn't much in the way of resources, but the jar spec is here: http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Signed%20JAR%20File says that the signature block is PKCS#7 which is defined here: http://tools.ietf.org/html/rfc2315 This links to about a million other ones I figured it out by creating a signature block with the Sun jar signer then trying to make mine output the same values, based on the specification. Removing the java5 stuff should be easy (only used generics to make the code easier for me to read). Should be nothing Java5 specific other than that The BER encoder is really inefficient, but I am not sure it can easily fixed. It is a Tag Length Value format and to calculate the length of a 'structure' you need to calculate the length of all of its children. There is probably an encoder in Apache Commons somewhere, but equinox already has a BER decoder, so i thought adding an encoder would be a good match. I have no emotional attachment to it though (since it is really buggy and incomplete).
(In reply to comment #9) > unfortunately, most of the code is all mine :( I'm sorry, but I have to tell you, that reimplementing the jarsign tool is a no-go for us. I assumed, that your application just calls the jarsign tool from a given SDK, like the eclipse javadoc exporter does for the javadoc tool. This would be the way for us to go.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
This is actually a nice-to-have and it is still valid.
*** Bug 341112 has been marked as a duplicate of this bug. ***
This is becoming more of a gap in the JDT for us. All of our web based (ie. most) JARs are signed. To need drop down out of the native builder to an ant script is cumbersome.
Any updates on this issue?
(In reply to Leonardo Pessoa from comment #15) > Any updates on this issue? A high quality patch is welcome.
