f5fab38988
Motivation: SSLContext.buildTrustManagerFactory(...) builds a KeyStore to initialize the TrustManagerFactory from an array of X509Certificates, assuming that array is a chain and that each certificate will have a unique Subject Distinguised Name. However, the collection of certificates used as trust anchors is generally not a chain (it is an unordered collection), and it is legitimate for it to contain multiple certificates with the same Subject DN. The existing code uses the Subject DN as the alias name when filling in the `KeyStore`, thereby overwriting other certificates with the same Subject DN in this collection, so some certificates may be discarded. In addition, the code related to building trust managers can take an array of X509Certificate instances to use as trust anchors. The variable name is usually trustCertChain, and the documentation refers to them as a "chain". However, while it makes sense to talk about a "chain" from a keymanager point of view, these certificates are just an unordered collection in a trust manager. (There is no chaining requirement, having the Subject DN matching its predecessor's Issuer DN.) This can create confusion to for users not used with PKI concepts. Modifications: SSLContext.buildTrustManagerFactory(...) now uses a distinct alias for each array (simply using a counter, since this name is never used for reference later). This patch also includes a unit test with CA certificates using the same Subject DN. Also renamed trustCertChain into trustCertCollection, and changed the references to "chain" in the Javadoc. Result: Each loaded certificate now has a unique identifier when loaded, so it is now possible to use multiple certificates with the same Subject DN as trust anchors. Hopefully, renaming the parameter should also reduce confusion around PKI concepts. |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-haproxy | ||
| codec-http | ||
| codec-socks | ||
| common | ||
| example | ||
| handler | ||
| license | ||
| microbench | ||
| tarball | ||
| testsuite | ||
| testsuite-osgi | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
How to build
For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.
You require the following to build Netty:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.
Branches to look
Development of all versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.