Community
Participate
Working Groups
Currently the IVerificationListener interface supports returning CHOICE_INSTALL_TRUST_ALWAYS, which would seem to imply that the update manager should not prompt the user *ever* again for this signer. This would require that the update manager place the representation of trust into someplace where the Jar verification subsystem (ie: OSGi JarVerifier) could reference it. This does not currently seem to be the case. If CHOICE_INSTALL_TRUST_ALWAYS is not appropriate because it implies trust across a feature or an update session, then we should add a CHOICE_INSTALL_TRUST_PERSIST to represent the permanent trust.
Created attachment 52166 [details] patch for the update core plug-in Support certs persistence, if the IVerificationListener returns CHOICE_INSTALL_TRUST_PERSIST, the persistence of cerst will be delegated to a CertificatesTrustService OSGI service. This also requires the patch from the OSGI JarVerifier https://bugs.eclipse.org/bugs/show_bug.cgi?id=157669 .
Please update the patch based on the new class/method names for the changes that were released to the OSGi bundle in bug 157669. Thanks.
I think there is a lot of changes in the new update.core plug-in, do you need me to produce against the old or new update.core plug-in?
Created attachment 58449 [details] update the patch w/ renamed CertificateTrustAuthority DJ, The class name change was trivial in the OSGI bundle and it changed from CertificatesTrustService to CertificateTrustAuthority. I just updated the previous patch w/ the new class name. Please let me know if you have any more questions. Thanks. -eric
Pls also assess how risky it would be to backport the 3.3 patch in 3.2 maintenance branch.
Also, is this committed for 3.3M7?
This looks very scary. I have no experience in this area and cannot release it unless somebody from the Equinox team approves it.
Created attachment 64193 [details] api for persist the trust certs and expired jars
Created attachment 64194 [details] make the class 'jar expired' sensitive
Philippe, the patch can't be applied into 3.2.2 since it requires the changes of OSGI plug-in in M4. The new patch that I just uploaded works w/ the latest code 3.3M6 update code. I have tested it out. Can anybody on the Equinox Team approve it?
Tom will take a look. We had no prior knowledge of this issue/patch and given the late date, it seems unlikely that we'll get something for M7.
Created attachment 65227 [details] org.eclipse.update.core patch I am not comfortable with this patch. It adds new API which will need PMC approval at this point in the release. Asside from that the changes to IVerificationResult adds a new method getCertificates(). The javadoc says "Clients may implement this interface." So any clients will no longer work. I'm not sure if update really supports just anyone implementing this interface but I'm not familiar enough with the code to make that determination, I only have the javadoc to go by. According to the javadoc this would be a binary incompatible change. A new interface would need to be defined which extends IVerificationResults that adds the new method. This patch does *not* address these issues. I also found a problem in how UpdateCore finds the CertificateTrustAuthority service. This algorithm must be identical to how the framework finds the trust authority. I've updated the patch to make this identical to the framework.
For people having problems with this issue, is there a recommended workaround or suggestion for avoiding multiple prompts?
I admit I scanned the bug very quickly, but there is a button to accept signatures (or lack thereof) for all subsequent features after the one that opened the dialog. So yes, I definitely claim that we probably can avoid them :-).
Any updates on this bug?
The Eclipse Update component is no longer under development, and no longer exists in the Eclipse Platform 4.x stream. If this problem still occurs in Eclipse Platform 4.2 or later, please enter a new bug report against Equinox p2.
