> IMO refactoring to remove sun.security.* usage is enough of its own thing to warrant its own PR
I agree, especially since replacing it with a 1:1 package mirror of sorts doesn't seem like the best way to go about it. From cursory searching it seems like it java.security is supposed to be a functional superset/equivalent to sun.security, just not a drop-in replacement. That could be wrong; I'm not a Java guy, but it sounds as though you should be able to do whatever you need to do without relying on a specific provider. On Fri, Sep 11, 2020 at 1:45 PM Zach Hoffman <[email protected]> wrote: > > 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 > > >
