I think a combination of what Zach suggested and option 2 are what I think sounds best. If the limitations of Bouncy Castle aren't insurmountable, I would rather use that than try to write our own. --Dave
On Fri, Sep 11, 2020 at 4:25 PM ocket 8888 <[email protected]> wrote: > > 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 > > > > > >
