Excellent, Eric. That neatly cleans up the problem. I do think we should merge my PR (1677), regardless, if for no other reason than to honour the authors' attribution request.
On Mon, Dec 18, 2017 at 1:47 PM, Eric Friedrich (efriedri) <[email protected]> wrote: > I emailed the owner of the password file earlier today and he agreed to > change or dual-license the project to MIT. > > —Eric > >> On Dec 18, 2017, at 3:40 PM, Phil Sorber <[email protected]> wrote: >> >> Rob, >> >> Just because we remove it for now doesn't mean we have to leave it out >> forever. I encourage you to contribute to the thread on the legal mailing >> list to make your case or at least get an understanding of their >> requirements. The ASF does tend to lean toward conservative interpretations. >> >> Thanks. >> >> On Mon, Dec 18, 2017 at 12:08 PM Robert Butts <[email protected]> >> wrote: >> >>> That's correct. No RPM, unfortunately. License is here: >>> https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project. >>> >>> -1 on downloading during rpmbuild, or especially postinstall. Both pose a >>> security risk. Moreover, it makes our build or install dependent on the >>> internet and a particular website. Neither building nor installing should >>> require either internet or a particular website; we should be working to >>> get away from that, not towards it. >>> >>> I'd prefer to find something Apache is ok with vendoring, if we have to. >>> Though, ideally we'd keep this one, Daniel Miessler is a well-known name in >>> the security community. >>> >>> >>> On Mon, Dec 18, 2017 at 11:51 AM, Dan Kirkwood <[email protected]> wrote: >>> >>>> Thanks, Eric.. Then it's possible we could download it during >>>> rpmbuild or postinstall. >>>> >>>> On Mon, Dec 18, 2017 at 11:40 AM, Eric Friedrich (efriedri) >>>> <[email protected]> wrote: >>>>> It can be downloaded from Github. >>>>> >>>>> I think this is the file (Rob correct me if I picked the wrong >>> variant): >>>> https://github.com/danielmiessler/SecLists/blob/ >>>> master/Passwords/10_million_password_list_top_100000.txt >>>>> >>>>> —Eric >>>>> >>>>> On Dec 18, 2017, at 1:38 PM, Dan Kirkwood <[email protected]<mailto: >>> dang >>>> [email protected]>> wrote: >>>>> >>>>> Rob, is there a specific download location for this file? I see it >>>>> referenced as "Projects/OWASP SecLists Project", but didn't find it >>>>> with a quick search. Is it possible it's provided by an rpm we could >>>>> list as a dependency rather than including in our source? >>>>> >>>>> -dan >>>>> >>>>> On Mon, Dec 18, 2017 at 11:11 AM, Robert Butts < >>> [email protected] >>>> <mailto:[email protected]>> wrote: >>>>> I'd really like to keep this, or replace it with a similar file from >>>>> another source. Which I'd be willing to investigate, if necessary. >>>>> >>>>> Having a good blacklist of most-common passwords specifically puts >>>> Traffic >>>>> Ops in compliance with NIST SP 800-63B. >>>>> >>>>> I also don't understand the objections, the Apache Legal FAQ >>> specifically >>>>> says CC-SA is permissible, and doesn't say anything about being limited >>>> to >>>>> binary (which would be odd, CC is designed for text, not binary). >>>>> https://www.apache.org/legal/resolved.html#cc-sa >>>>> >>>>> I'd vote we wait for the legal resolution, or find a suitable >>>> replacement, >>>>> in order to remain in NIST compliance. >>>>> >>>>> >>>>> On Mon, Dec 18, 2017 at 10:55 AM, David Neuman < >>> [email protected] >>>>> >>>>> wrote: >>>>> >>>>> Hey all, >>>>> I don't know if you have been following the release 2.1 thread on the >>>>> incubator list [1] , but we have been given a -1 vote by the IPMC for >>>>> having a file in our release [2] that has an incompatible license. >>> There >>>>> is some debate about the license, and we have reached out to Legal for >>>> more >>>>> information [3] (thanks Eric!), but we haven't heard back from legal >>> yet. >>>>> Instead of waiting for legal to get back to us, I would like to propose >>>>> that we instead remove this file from our release. The file in >>> question >>>> is >>>>> just a list of weak passwords and I feel like we can easily include a >>>> blank >>>>> file, or a file with a couple passwords that we generate, and >>> individual >>>>> installs of Traffic Control can replace this file as they see fit. >>> This >>>>> will >>>>> remove issue of having an incompatible license in our release and >>> should >>>>> also not require us to do a code change. The downside of removing this >>>>> file is that we will need to create another 2.1 release candidate and >>> go >>>>> through the vote process again. I would really like to see us get 2.1 >>>>> released before the end of the year, and at this point our chances are >>>>> looking pretty slim. So, does anyone object to removing this file from >>>> our >>>>> release? If not, I will put an issue into github, remove the file, and >>>>> back port the change so that we can get another 2.1 release candidate >>>> out. >>>>> >>>>> Thanks, >>>>> Dave >>>>> >>>>> >>>>> [1] >>>>> https://lists.apache.org/thread.html/c211f049e3d68af90196c30f6b6d31 >>>>> a67b3072029dea1efe7d35c9dc@%3Cdev.trafficcontrol.apache.org%3E >>>>> [2] >>>>> apache-trafficcontrol-2.1.0-incubating/traffic_ops/app/ >>>>> conf/invalid_passwords.txt >>>>> [3] https://issues.apache.org/jira/browse/LEGAL-356 >>>>> >>>>> >>>> >>> >
