Luke, I assume that the edits I made to the page are acceptable. I see that further edits have been made.
I added some additional extensions to the list of standard binary artifact types that are allowed (doc, docx, ppt, pptx). I suggest we scan the current repos to see how prevalent binaries are, and what types there are before we kick this off. I would suggest that it start out allowing anything that is currently there, and we can back off the list, and add project-specific exceptions as we get more experience with why/how we would want to restrict/assess binaries more. Some examples might include: * Any situations that we can detect, in which binaries might have questionable/risky content. This would imply e.g. a virus etc scan of the binaries, or a license scan. * If we want to encourage projects to include only certain types of binaries (not sure how or why). Using this tool as a hoop that projects would have to jump thru (however easy) to encourage sticking to certain content types, seems pretty useless. The goal is that as this rolls out, we do not impede any commits at start, rather we gather information about what *may* need to change in the repos, and when ready we back off the exceptions or make them project specific. I would like to see some more features added to the process though. The cursory license check is OK for code contributed to OPNFV, but just as important is any reference to code that the submitted code interfaces with. So we need to be able to scan the references to ensure that the contribution and its references are compatible under OPNFV’s policy. For example: * It is acceptable for an OPFNV-hosted module to be Eclipse licensed, and import a GPL-licensed module’s interfaces (example: the VES collectd plugin in the Barometer project: https://git.opnfv.org/barometer/tree/3rd_party/collectd-ves-plugin/ves_plugin/ves_plugin.py) . * It would *not* be acceptable for the VES collectd plugin to be APL 2.0 licensed and to import a GPL-licensed module’s interfaces. * If possible, license metadata inside binaries (e.g. an image, document, slide deck, …) needs to be explicit (our current practice is to have an umbrella license in the root of the repo). * Scanning of code and referenced code (which becomes part of the OPNFV platform when built) for licenses and known vulnerabilities * … other examples need to be developed to establish some policies that the tool can validate We may need to incorporate additional tools e.g. Fossology or proprietary toolchains (e.g. Blackduck – we should see if we can get an Open Source project use license from them). Thanks, Bryan Sullivan | AT&T From: [email protected] [mailto:[email protected]] On Behalf Of Luke Hinds Sent: Wednesday, May 17, 2017 11:22 AM To: opnfv-tech-discuss <[email protected]>; degirmenci, fatih <[email protected]>; Ulrich Kleber <[email protected]>; Jack Morgan <[email protected]>; Ashlee Young (Ash) <[email protected]> Subject: [opnfv-tech-discuss] [infra] [security] Wiki page for Anteater I have pushed up the code for anteater (releng-anteater) and have added a lot more body to the wiki page for anyone interested in the project [1]. This will also become release worthy documentation forthcoming, once I have got a feel for what needs communicating and used feedback to gather an FAQ. It is worth PTLs / committers getting familiar with writing your own regex over the coming E release cycle, as you might find Anteater falsely reports a string / binary etc, and you need to commit a patch with a project waiver. For more details on this, see the wiki section 'Anteater Has Blocked my patch, what should I do?' Anteater is planned to be non-voting for E-release, and voting for F. If anyone knows of security folk / researchers who can help add new additional to the string blacklists, please encourage them to contribute. Same for general code contributions as well. [1] https://wiki.opnfv.org/pages/viewpage.action?pageId=10294496<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.opnfv.org_pages_viewpage.action-3FpageId-3D10294496&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OrbtGCluczz9awEKz9Fv7g&m=tvgj3rZU8k95hpdxYmC2JBDssmUX2OVG-u7sehtnywE&s=wzis0JQJeIPUvl4uhJ8hit4CUW3Wdon1F2Iy0IMeuVY&e=> -- Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat e: [email protected]<mailto:[email protected]> | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44 12 52 36 2483
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
