Bugzilla – Full Text Bug Listing
| Summary: | provide an API to trust self-signed or otherwise untrusted certificate | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Igor Fedorenko <igor> | ||||
| Component: | p2 | Assignee: | Tobias Oberlies <t-oberlies> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | akarypid, alix.lourme, bimargulies, bruno.do.medeiros, eclipse, joostvanpinxten, pascal, peter, pwebster | ||||
| Version: | 3.6.2 | ||||||
| Target Milestone: | Juno M2 | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Igor Fedorenko
correction, I meant "director" not "publisher" By default the director application (DirectorApplication in org.eclipse.equinox.p2.director.app) will not check certificates at all. It should be sufficient for you to run this application to get the desired behaviour. Should you want finer grain support, I suggest that you register your own implementation of the UIServices service against the p2 agent. An example is available in the DirectorApplication code with the class AvoidTrustPromptService Special UIServices can be used to enable/disable trust check for entire p2 runtime but we need to have control over individual DirectorApplication executions, or, better yet, individual IEngine.perform invocation. This service is a p2 agent service therefore it is scoped to a particular agent. If you are using the engine directly, then you can just omit the check trust phase. (In reply to comment #2) > By default the director application (DirectorApplication in > org.eclipse.equinox.p2.director.app) will not check certificates at all. This does not seem to be entirely correct. I'm currently investigating another problem, and I'm seeing the following call stack: Thread [main] (Suspended) CertificateChecker.checkCertificates(SignedContentFactory) line: 126 CertificateChecker.start() line: 49 CheckTrust.completePhase(IProgressMonitor, IProfile, Map) line: 50 CheckTrust(Phase).postPerform(MultiStatus, EngineSession, IProgressMonitor) line: 216 CheckTrust(Phase).perform(MultiStatus, EngineSession, Operand[], IProgressMonitor) line: 84 PhaseSet.perform(EngineSession, Operand[], IProgressMonitor) line: 44 Engine.perform(IProfile, IPhaseSet, Operand[], ProvisioningContext, IProgressMonitor) line: 73 Engine.perform(IProvisioningPlan, IPhaseSet, IProgressMonitor) line: 44 PlanExecutionHelper.executePlan(IProvisioningPlan, IEngine, IPhaseSet, ProvisioningContext, IProgressMonitor) line: 41 PlanExecutionHelper.executePlan(IProvisioningPlan, IEngine, ProvisioningContext, IProgressMonitor) line: 23 DirectorApplication.executePlan(ProvisioningContext, IProvisioningPlan) line: 575 DirectorApplication.planAndExecute(IProfile, ProvisioningContext, ProfileChangeRequest) line: 569 DirectorApplication.performProvisioningActions() line: 556 DirectorApplication.run(String[]) line: 807 DirectorTask.execute() line: 79 It is true that the DirectorApplication will install an instance of AvoidTrustPromptService as UIServices service, and through that instance the CertificateChecker will trust all unsigned plug-ins. It will however cancel the operation if any signed but untrusted artifact was found: Certificate[] trustedCertificates = trustInfo.getTrustedCertificates(); // <<-- always null! // If we had untrusted chains and nothing was trusted, cancel the operation if (unTrustedCertificateChains != null && trustedCertificates == null) { return new Status(IStatus.CANCEL, EngineActivator.ID, Messages.CertificateChecker_CertificateRejected); } The net result of this situation is that Eclipse, an open source platform, has a playing field that is tilted against open source development. Code signing certificates are expensive, and not easily available to individuals at all. You forgot to call us evil or something like that... We are open to quality code contributions. Pascal, I don't throw 'evil' around, and I tried to avoid heated rhetoric in my comment here and in the Google+ posting I just made on this subject. I apologize if I failed to make my point neutrally enough. What I'd really rather see is an viable way to allow open source developers to obtain real certificates without starting companies and paying a fractional fortune. It's an unfortunate chain of circumstances that Java is tangled up with X.509 and the X.509 universe is not very friendly to open source. I don't know if I feel competent to push this area of endeavor on the top of my open source development stack. (In reply to comment #9) > Pascal, > > I don't throw 'evil' around, and I tried to avoid heated rhetoric in my comment > here and in the Google+ posting I just made on this subject. I apologize if I > failed to make my point neutrally enough. > > What I'd really rather see is an viable way to allow open source developers to > obtain real certificates without starting companies and paying a fractional > fortune. It's an unfortunate chain of circumstances that Java is tangled up > with X.509 and the X.509 universe is not very friendly to open source. > > I don't know if I feel competent to push this area of endeavor on the top of my > open source development stack. Self-signed certificates have no value to the end-user and they do not help establish original of the code. So this bug only affects test scenarios and organizations using self-signed certificates for internal code distribution. Open-source developers and organizations not willing to purchase "proper" certificates from CAs should just ship unsigned code. (In reply to comment #10) > Self-signed certificates have no value to the end-user and they do not help > establish original of the code. ACK. > So this bug only affects test scenarios and > organizations using self-signed certificates for internal code distribution. Unfortunately, this is not entirely correct. It also affects scenarios where the valid certificates could not be verified - for example, because some root certificates were missing. The OpenJDK docs even state this: "The cacerts file shipped with OpenJDK is initially empty." but some package maintainers just go ahead and leave people without root certificates. this.getCurrentRant().abort(); It's at least very confusing that the current implementation accepts unsigned code (which is inherently unsafe as you stated) and at the same time rejects signed code with an incomplete certificate chain (which may or may not be safe, we can't tell either) with the very same error message. It took me several hours to find out that the problem was not in one of my unsigned artifacts but in the (signed!) Eclipse components I was trying to repackage. > Open-source developers and organizations not willing to purchase "proper" > certificates from CAs should just ship unsigned code. I doubt that the problem lies in the 'willing'... Igor, A certain amount of googling today failed to turn up any CA at all that would sell a code signing certificate to an unincorporated individual. Do you know of one? (In reply to comment #12) > Igor, > > A certain amount of googling today failed to turn up any CA at all that would > sell a code signing certificate to an unincorporated individual. Do you know of > one? Assuming you are asking about "not willing" part in comment 10, that was meant to apply to organizations only. Sorry for the confusion. Created attachment 202904 [details] trust every certificate Changed the AvoidTrustPromptService in the DirectorApplication to declare every certificate as trusted. This allows to use self-signed certificates in test builds where you dont have access to a "real" certificate. Jar files signed by a self-signed certificate are now as valid as unsigned jar files (and not worse). From comment #2 it seems that this was the intended behavior of the DirectorAppliction anyway. (A TODO in the CertficitateCheckerTest implies this also). (In reply to comment #14) This sounds good. I'll review the patch and probably apply in in the next couple of days. Applied the patch in master (114c88c). This makes the director application allows to install signed bundles, even if they have not been issued by one of the trusted CAs. Will this API be exposed for command-line use by the director application? I would like to be able to run something like "eclipse -application org.eclipse.equinox.p2.director -installIU my.self-signed.feature -ACCEPT_SELF_SIGNED". See for example http://www.eclipse.org/forums/index.php/mv/tree/202885/#page_top Should I file a separate feature request for that? (In reply to comment #17) > Will this API be exposed for command-line use by the director application? IIRC, self-signed certificates are now always accepted by the director. This is the same as with unsigned bundles. Hi, Thanks for this evolution, it can allow to automatise some eclipse distribution with P2 ! Is there any way to apply this change on Eclipse Indigo 4.2 ? (obviously not in official bundle ... but with a workaround / patch / etc). Because for some plugins, these case have not the same result : - Builder Juno -destination Indigo - Builder Indigo -destination Indigo - Builder Indigo (provisionning same bundle) Cf. https://jira.springsource.org/browse/IDE-1251 Objective : Eclipse 4.2 bundle automatisation, containing : - Some self signed plugin - SpringToolSuite plugin And today I have no solution ... no way ... it's a hair-raising problem :-). (In reply to Igor Fedorenko from comment #10) > > Self-signed certificates have no value to the end-user and they do not help > establish original of the code. So this bug only affects test scenarios and > organizations using self-signed certificates for internal code distribution. > Open-source developers and organizations not willing to purchase "proper" > certificates from CAs should just ship unsigned code. I'm curious to as why the support for self-signed certificates isn't any better. What we would like is a convenience step for the end-user; the certificate can be accepted once, as you are installing/updating 'unsafe' code, from a certain source (albeit self-signed). This then disables future notifications of the pop-up, unless the certificate changes, which might notify the user that something has changed. Of course, buying a proper certificate is in the end a better idea... However, that doesn't take away the validity of the use case of using a self-signed certificate for internal use, or for small deployments. I believe the PyDev team (not a small plugin) also uses self-signed certificates. If I choose to accept it once, I don't want to see it the second time I update the plugins... I also want to draw your attention to bug #440430, which has so far received zero attention. Please either respond to the question, or close the bug as invalid. But please do provide the reasons why this is not supported in the development, for future reference. (In reply to Joost van Pinxten from comment #20) > (In reply to Igor Fedorenko from comment #10) > > > > Self-signed certificates have no value to the end-user and they do not help > > establish original of the code. So this bug only affects test scenarios and > > organizations using self-signed certificates for internal code distribution. > > Open-source developers and organizations not willing to purchase "proper" > > certificates from CAs should just ship unsigned code. > > I'm curious to as why the support for self-signed certificates isn't any > better. What we would like is a convenience step for the end-user; the > certificate can be accepted once, as you are installing/updating 'unsafe' > code, from a certain source (albeit self-signed). This then disables future > notifications of the pop-up, unless the certificate changes, which might > notify the user that something has changed. > > Of course, buying a proper certificate is in the end a better idea... > However, that doesn't take away the validity of the use case of using a > self-signed certificate for internal use, or for small deployments. I > believe the PyDev team (not a small plugin) also uses self-signed > certificates. If I choose to accept it once, I don't want to see it the > second time I update the plugins... > > I also want to draw your attention to bug #440430, which has so far received > zero attention. Please either respond to the question, or close the bug as > invalid. But please do provide the reasons why this is not supported in the > development, for future reference. If you are asking me personally, I am not a p2 developer and can't answer your questions. (In reply to Igor Fedorenko from comment #21) > (In reply to Joost van Pinxten from comment #20) > > I also want to draw your attention to bug #440430, which has so far received > > zero attention. Please either respond to the question, or close the bug as > > invalid. But please do provide the reasons why this is not supported in the > > development, for future reference. > > If you are asking me personally, I am not a p2 developer and can't answer > your questions. The roles are very difficult to spot on Bugzilla; your comment just turned out to be the most revelant to link to this bug/request. I hope some p2 developer can actually pick this up. (In reply to Igor Fedorenko from comment #10) > > Self-signed certificates have no value to the end-user and they do not help > establish original of the code. I'm not a security expert, but my understanding is the above is incorrect. If a self-signed certificates had no value to the end-user, then web-browsers and other security-minded applications (like SSH clients) wouldn't have the option to add self-signed certificates to the applications trust store. Specifically, self-signed certificates have *some* value to the end-user, even if not as good as authority-signed certificates. A self-signed certificate that is added to a trust store guarantees that any future code installations come from the same source as the original installation. Yes, it doesn't guarantee on itself that the original installation is genuine, but it is still much better guarantee than unsigned code, which could be forged on *any* installation/update, as opposed to just the first one. And even this issue can be addressed by having the first installation be performed/downloaded from a trusted source, for example, a user can download a feature/update-site of an open-source from Github, using HTTPS, (thus guaranteeing the original installation comes from the official developers), and then they can trust the self signed certificate that came with it. |