Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] about signing feature jar's...

Doesn't seem like a critical problem at this point in the release from my perspective. As you said this isn't the only case. The main drawback is that the user would be warned that they are installing unsigned content if they install those features into a target platform.

John



Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
Sent by: eclipse.org-planning-council-bounces@xxxxxxxxxxx

05/29/2012 11:19 AM

Please respond to
"eclipse.org-planning-council"        <eclipse.org-planning-council@xxxxxxxxxxx>

To
Eclipse Planning Council <eclipse.org-planning-council@xxxxxxxxxxx>
cc
Ralf Sternberg <rsternberg@xxxxxxxxxxxxxxxxx>
Subject
[eclipse.org-planning-council] about signing feature jar's...





Hi Planning Council fellows,

we found out that two of our three features that we are contributing from the RAP project to the Simultaneous Release Repository have unsigned feature jar's (see [1]). The reason for this has its roots in the famous 'A.PDE.Target.Platform' construct and in the resulting complex RAP build. We will be able to remove this in RAP for Kepler, but not yet in the Juno release.

('A.PDE.Target.Platform' had been introduced to prevent people from installing runtime-only bundles into their IDE via p2. In Kepler we will be using the negative dependency construct in p2 that has been introduced to solve this problem.)

Note that this is only about the feature jar's, the bundles itself are signed! And note that these two features are runtime-only features, i.e. features that are not meant to be installed into the Eclipse IDE.

I've checked that there are other projects out there which do not sign their features, too. Maybe they have similar reasons. And strictly speaking we've only the requirement in our Simultaneous Release Requirements to have signed bundles, there is no hard requirement to sign the features.

I cannot see any negative consequences if we leave these feature jar's unsigned. They are only used when someone uses them to build a target platform.

The question is: Is it acceptable that the two feature jar's remain unsigned?


Thanks,
Markus


[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=380516 Runtime features are not signed _______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.


Back to the top