Community
Participate
Working Groups
When using a bugzilla server via HTTPS to a server with un-officially signed certificates, you cannot attach a context, nor create a new repository query. Dialog comes up saying: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target Please check your settings in the bugzilla preferences. On Windows if you open a browser window inside eclipse and tell IE to accept the certificate, then they work. eclipse 3.2rc6 / mylar dev build may 26th, both windows and linux.
*** Bug 142332 has been marked as a duplicate of this bug. ***
I wonder if you should use dummy cetificate store and trust manager and allow to add certificates to the store on user's request.
Linux update: Repository synchronizing works, but context attaching is still a no-go.
Created attachment 45126 [details] Attach Context accepts all SSL certificates Adds a factory to take advantage of the already in use TrustAll with the HttpClient.
*** Bug 147661 has been marked as a duplicate of this bug. ***
Created attachment 45136 [details] mylar/context/zip
Patch applied, and manually tested, great work Nathan. Nits: - we never dump exceptions, so take a look at the way I made getSslSocket use MylarStatusHandler - note the capitalization change of SSL in the type and method to follow our coding guidelines - please attach a context when you submit patches - it would be great if you submitted a unit test for this. It doesn't need to do much or connext to a server, just making a test call createSocket and check that the socket was created correctly will suffice.
Guys, are you sure it is really good idea to register protocol handler globally like this? Protocol.registerProtocol("https", new Protocol("https", new TrustAllSslProtocolSocketFactory(), 443)) It would be safer to add it per request...
That's a very good catch Eugene and I was sloppy in my review. Nathan: this could cause problems for things like webtools registering different protocol handlers. Also, currently the handler is registered every time we upload. I have commented out the registration for now. Could you please submit a patch with Eugene's suggestion?
Created attachment 45208 [details] Certificates Patch Mik, Eugene: thanks for the comments. Added a couple tests and localized the protocol change.
Created attachment 45209 [details] mylar/context/zip
Created attachment 45216 [details] Certificates Patch Change set was tracking an extra file, this patch is cleaner.
This approach looks good to me. Eugene, if you have any concerns with it please voice them. Nathan, you will need to re-create the patch to the test case because that class has changed in HEAD. PostMethod postMethod; if (repositoryUsesHttps(repositoryUrl)) { Protocol acceptAllSsl = new Protocol("https", new TrustAllSslProtocolSocketFactory(), getSslPort(repositoryUrl)); client.getHostConfiguration().setHost(getDomain(repositoryUrl), getSslPort(repositoryUrl), acceptAllSsl); postMethod = new PostMethod(getRequestPath(repositoryUrl) + POST_ARGS_ATTACHMENT_UPLOAD); } else { postMethod = new PostMethod(repositoryUrl + POST_ARGS_ATTACHMENT_UPLOAD); }
Created attachment 45340 [details] Re-made the patch
Created attachment 45341 [details] mylar/context/zip
Patch applied and manually tested, nice work Nathan. I did not include the changes to ExistingBugEditor and assume that they were unintentional.
Oh, sorry about that, must have accidentally slid in.
Mik, I have been unable to replicate your failure on the test cases, even on my laptop running xp home with the windows firewall enabled. However, I've come up with a slightly better approach for the test case, with any luck it will be more reliable. Instead of binding to a particular interface on a particular port, it will now try to bind to 0.0.0.0:0, and let the kernel pick what interface/port. I tested this on windows and linux, passes on both.
Created attachment 45938 [details] New test case
Patch applied and verified. Good stuff Nathan.
