> 2. Use a third-party library. Some third-library parties offer partial replacements of the namespace (e.g. BouncyCastle).
For the cases where java.security.* alone is not sufficient, do we need anything outside of org.bouncycastle.jce.provider? That's been a dependency since https://github.com/apache/trafficcontrol/commit/6ebd7a428f , so we already have that at our disposal. > 3. Custom implementation. We could just mirror the functionality of the ‘sun.security.*’ namespace within the ATC codebase. While it gives more fine-grained control, the ATC project is now responsible for maintaining certificate management code and other things that are irrelevant to the main focus of the project. I'm -1 for rolling our own crypto IMO refactoring to remove sun.security.* usage is enough of its own thing to warrant its own PR before anything Java 11-related. Super excited to see this project, Java 11 will mean new language features and a performance boost. -Zach On Fri, Sep 11, 2020 at 11:52 AM Zenn, Joshua (CCI-Atlanta) < [email protected]> wrote: > Hello! I’ve been working on upgrading ATC Traffic Router to use Java 11 > LTS from Java 8. I’ve come across an issue, and it was proposed that it be > presented here for an official consensus on how to move forward. > > As of Java 9+ the ‘sun.security.*’ namespace has been made internal-only, > which a fair amount of TR certificate management code relies on. Up through > Java 8 Oracle has stated that the package was for internal use only, but it > was publicly accessible by other namespaces. Based on my research so far, I > found that other projects have taken one or more of these paths to resolve > this issue: > > 1. Hack some compiler options to manually include the ‘sun.security.*’ > internal package again. This is not recommended by Oracle and has the > possibility of being broken on any given Java update, but it is the fastest > to implement and will have the least impact on the codebase. > 2. Use a third-party library. Some third-library parties offer partial > replacements of the namespace (e.g. BouncyCastle). The trade-off is that we > would lose some fine-grained control over certificate loading (which might > affect other ATC components). This option may also introduce some licensing > issues. Finally, this would require an overhaul of the cert part of the TR > codebase. > 3. Custom implementation. We could just mirror the functionality of the > ‘sun.security.*’ namespace within the ATC codebase. While it gives more > fine-grained control, the ATC project is now responsible for maintaining > certificate management code and other things that are irrelevant to the > main focus of the project. > > A great suggestion that was given by Zach Hoffman in Slack was to use the > ‘java.security.*’ namespace. This would resolve some of the missing > classes. However, the namespace is not a 1:1 implementation of > sun.security.*, so the remaining missing classes would need to be resolved > using one of the above methods (or any new ideas that can be suggested). > > -- > Joshua Zenn >
