Community
Participate
Working Groups
I20100805-1700. In the latest build it's just 'org.eclipse.jface' that's not signed but with each build some bundles are unsigned due to unreliable signing process, see bug 321642 for details and bug 321795 for the underlying issue. The question is whether we consider this a stop ship for M1 or not.
Maybe this happened before but we simply didn't check it since we don't have a test that fails when this happens?
I personally don't think that milestone builds must be signed, so I wouldn't consider this as a stop ship - but adding an automated test to check whether all bundles are signed seems to be a good thing to check at release time. Here is what I've been doing for the TM project since a couple years on the update site just before promoting it: for x in `ls plugins/*.jar features/*.jar`; do result=`jarsigner -verify ${x} | head -1` if [ "$result" != "jar verified." ]; then exit 1 #fail fi end exit 0 #pass
>I personally don't think that milestone builds must be signed, so I wouldn't >consider this as a stop ship I would say the same. The only drawback is the additional warning dialog for people that use p2 to update.
It's unfortunate but I don't consider this stop-ship for M1. Especially considering the signing process is unreliable, we can't be sure a rebuild will fix it.
When the main concern is p2's warning dialog on an "update", one option might be to just manually sign affected bundle(s) in the repo but keep the downloadable ZIP's unchanged. I'm not sure whether signing a bundle would change any checksums that would need to be regenerated in p2's metadata, so I don't know whether this is practical. Another option might be just rebuilding the repo from the same original tag but keep the downloadable ZIP's unchanged.
You don't want to have bundles with the same id and version but different binary content. This would be the case if we signed the jface bundle the repo, but left the zips intact. We want people to have the same content in their install if they install from a repo or a zip. This is why we use the comparator in our builds :-) If you sign a bundle, you need to run p2.process.artifacts over the repo to update the checksums. In any case, I will open a bug with the ui team to sign jface for 3.7M2.
>In any case, I will open a bug with the ui team to sign jface for 3.7M2. You mean, to retag, so it gets signed, right? > Especially > considering the signing process is unreliable, we can't be sure a rebuild will > fix it. Given 3+ for not stopping M1 due to this bug I suggest we close this as WORKSFORME. I've filed bug 321996 about adding a test to detect unsigned bundles.
(In reply to comment #6) > You don't want to have bundles with the same id and version but different > binary content. In general I agree, of course. In the concrete case, the question is what's the bigger itch - different binary content or the annoying dialog when updating. I personally don't care too much an a Milestone build, and if there is any risk associated with patching the repo, we better leave it alone.
Unfortunate but not a particular issue in my books. As for having different content for the same version, I believe strongly that we should never do that. There is a trust relationship between producer and consumer and introducing such a variation would severely undermine that fundamental notion. Annoying click is way better than not being able to trust that you know what you are deploying.
.
