Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [orbit-dev] To sign or not to sign? .... is that a question?

Hi Dave,
 
if I'm not mistaken, about a year ago we decided to not sign Orbit
bundles because Eclipse's jarsigner had problems with re-signing
bundles again that were already signed:
http://dev.eclipse.org/mhonarc/lists/orbit-dev/msg00260.html
 
The corresponding bug is still in NEW state, so I'm not sure
if it works properly now:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=174475
 
Before that issue was detected, it seems like there was agreement
that we should sign everything we deliver from Eclipse. Even if
it's already signed by the original distributor (since we typically
at least add some manifest, or mark it as "approved by Eclipse".
 
Looking at what Orbit is good for (ensuring that there is ONE
canonical version of a 3rd party lib at Eclipse), I think that
it's Orbit who should do the signing -- or not do it if it turns
out (by any consuming project) that a particular bundle can
not be signed for any reason.
 
 
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 


From: orbit-dev-bounces@xxxxxxxxxxx [mailto:orbit-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Mittwoch, 13. Februar 2008 01:25
To: Orbit Developer discussion
Subject: [orbit-dev] To sign or not to sign? .... is that a question?


Have we decided this issue in Orbit? I vaguely remember talking about it, but don't recall a decision.  And, thinking about it now, I could see doing it or not doing it, I sort of lean towards not doing it.

Reasons Orbit should sign:

        It could be argued that "every bundle produced by Eclipse should be signed by Eclipse".
               
        If we leave it up to the projects to sign or not to sign, there would be bundles "in the wild" that had the same version and qualifier, but one was signed and one was not (not sure this is bad .. just confusing).



Reasons Orbit should not sign:

        Orbit essentially produces bundles for the projects, and it's up to the projects to sign them, before they distribute them.  Orbit itself doesn't distribute these bundles, in the normal sense of the word.

        There might be some hopefully rare cases where a bundle can not be signed, at least for some particular project, if it would result in excessive performance penalty, which can happen if it has it's own classloader .. .and we know several third party bundles do have their own class loaders.



Any other opinions, or arguments pro or con?  Or ... pointers to where this has already been decided?!

Thanks,

Back to the top