What Dave said is accurate; the tests compare our own zone signing implementation to that of jdnssec.
On 11/16/18, 11:34 AM, "Fieck, Brennan" <[email protected]> wrote: If what Dave said is true, then I'm changing my vote to "+1 for removing entirely - including from tests" ________________________________________ From: Schmidt, Andrew (Contractor) <[email protected]> Sent: Friday, November 16, 2018 8:49 AM To: [email protected] Subject: Re: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic Router +1 getting rid of jdnssec from the rpm. If someone out there still really needs it we could wrap it in its own rpm or just provide the documentation as suggested by Jesse. On 11/15/18, 9:22 PM, "Dave Neuman" <[email protected]> wrote: If I recall correctly the “testing” is really just to compare our own developed version vs the jdnssec version. As far as I am concerned we have proven it is more than adequate by running in production so those tests are no longer necessary. +1 on removing the now unnecessary dependency completely. On Thu, Nov 15, 2018 at 15:39 Rivas, Jesse <[email protected]> wrote: > If consensus is to keep the jdnssec module for testing purposes, the > download step could be removed from the build_rpm.sh script and > documentation added on where to download the .jar and how to build with > maven. That way, the .jar isn't downloaded by default, won't cause the > build to fail, and it would be easier to maintain documentation on where to > get the .jar than maintain the build script if the location changes. > Alternatively, the URL for download could just be updated and continue to > download and build as it has in the past. > > If you feel strongly one way another on updating the download URL in the > build script, keeping the module in Traffic Router and removing the > download step from build_rpm.sh, or removing the module completely, please > share your viewpoint. > > -Jesse > > On 11/15/18, 12:39 PM, "Robert Butts" <[email protected]> wrote: > > Just FYI, it looks like it's on Github, by the original author: > https://github.com/dblacka/jdnssec-tools/releases/tag/0.12 . So it > looks > like it'd be trivial to fix and keep, if we wanted to. > > > On Thu, Nov 15, 2018 at 12:29 PM Fieck, Brennan < > [email protected]> > wrote: > > > +1 on removing > > > > I'm not super familiar with Java/maven build systems, but I don't > see a > > problem with keeping it in the tests if that's possible - but code > that > > isn't used shouldn't be a dependency. > > ________________________________________ > > From: Chris Lemmons <[email protected]> > > Sent: Thursday, November 15, 2018 12:24 PM > > To: [email protected] > > Subject: [EXTERNAL] Re: Removal of JDNSSEC dependency from Traffic > Router > > > > I'm good with removing it entirely from any even optional use in the > > code as it could run in production. But testing frameworks against > one > > another is absolutely of value, and falls squarely into an adequate > > licensing exception for LGPL use. I'm -0 on removing it from the > > tests. If we can't find an easy place for automatic download, we > > should remove it, but if it's reasonable to swap out the source, or > > allow folks to build and provide their own, I think we'd gain by > > including it in our testing scheme. > > On Thu, Nov 15, 2018 at 12:16 PM Rawlin Peters < > [email protected]> > > wrote: > > > > > > +1 > > > On Thu, Nov 15, 2018 at 10:56 AM Dan Kirkwood <[email protected]> > wrote: > > > > > > > > eliminate an unnecessary dependency? +1 (+1000 if I could...) . > > > > > > > > If it's kept around only for testing purposes, the tester > should deal > > > > with that separately: perhaps a documentation update is > warranted in > > that > > > > case. > > > > > > > > -dan > > > > > > > > On Thu, Nov 15, 2018 at 10:40 AM Rivas, Jesse < > [email protected] > > > > > > > wrote: > > > > > > > > > Hi Traffic Controllers, > > > > > > > > > > Currently, the .pkg script is failing to build the Traffic > Router rpm > > > > > because the build_rpm.sh script for TR attempts to download > > > > > jdnssec-tools.jar from verisign ( > > > > > http://www.verisignlabs.com/dnssec-tools/packages/old-releases > ), > > which is > > > > > no longer available. Traffic Router used to leverage code from > the > > > > > jdnssec-tools.jar for zone signing, but it has since been > replaced > > with our > > > > > own implementation. All of the classes and subsequent tests > that use > > the > > > > > jdnssec package were previously moved from “core” to a separate > > module in > > > > > Traffic Router (called “jdnssec”) that is not included in the > maven > > build > > > > > by default, and was kept for legacy and testing purposes. I > would > > like to > > > > > propose removing the JDNSSEC dependency from Traffic Router > > altogether; > > > > > this would include removing the jdnssec module in Traffic > Router and > > > > > subsequent pom files, and removing the “installDnsSec” > function from > > the > > > > > build_rpm.sh script in Traffic Router that attempts to download > > > > > jdnssec-tools.jar and fails if it is unsuccessful. > > > > > > > > > > Please let me know if there is any opposition to removing the > > external > > > > > JDNSSEC dependency from Traffic Router, as it is no longer > used for > > zone > > > > > signing and is no longer available for download from verisign. > > > > > > > > > > -Jesse > > > > > > > > > >
