[
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:
The corresponding bug is still in NEW state, so I'm not
sure
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
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,