| Summary: | RFE: please provide version 1.46 on EPEL5 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | CristinaA <caifti> |
| Component: | bouncycastle | Assignee: | Steve Traylen <steve.traylen> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | el5 | CC: | joni.hahkala, steve.traylen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-12 11:37:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
CristinaA
2012-01-18 16:49:06 UTC
bouncycastle-1.46-1.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/bouncycastle-1.46-1.el5 Package bouncycastle-1.46-1.el5: * should fix your issue, * was pushed to the Fedora EPEL 5 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing bouncycastle-1.46-1.el5' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-0221/bouncycastle-1.46-1.el5 then log in and leave karma (feedback). From one of the interested people: I've tested a little bit 1) installs on SL5 and updates 1.45 correctly. 2) compilation and all canl tests run fine using the library. 3) observation: the jar from this library is unsigned (as the SL6 version). This was discussed lengthy on EMT (start on 25.03.2011), when talking about 1.45 version. I've briefly read the thread now and I can say that I think nobody was fully right (at least regarding the main thread topic). With the current 1.6 JDKs signing the provider is optional (it was not before, e.g. in JDK 1.4, what Bernd thought is still true). However for unsigned providers some of the features won't work, the list is here: http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6 And this is not true that Fedora maintainers can not sign when rebuilding BC from source: they can, it is described in the above document how to obtain a signing certificate. Anyway this point is probably not our business, as it seems that even indirectly we don't use restricted APIs. However I can't guarantee this for sure. E.g. it may happen that I use indirectly a restricted API, but for the algorithms which are tested the standard JDK provider is chosen, while for one or two not implemented in the JDK provider BC provider would be chosen. Bottom line: I would ack the package. Cheers Krzysztof Fails for me: Upon upgrade requests to my tomcat services (probably trustmanager) just hang. Will close won't fix shortly. Steve. It was a weird problem. When definitions that were deprecated in X509Extensions were used, the threads just hung. They didn't proceed or throw exceptions. Replacing the references to the deprecated definitions with the string values made things work fine. To me it seems to point to bug in java or maybe there was something else thrown that tomcat swallowed. I couldn't use the new definitions from bc 1.46 as they were not present in bc 1.45. Ubuntu/debian seem to still use 1.44 etc, so just supporting 1.46+ isn't a good option. |