On Thu, May 18, 2017 at 6:25 PM, SULLIVAN, BRYAN L <[email protected]> wrote:
> 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. > > > We discussed implementation approaches at the hackfest and arrived a similar phased approach: Perform daily or weekly scans for projects that are there only to inform, not enforce. Implement the gate checks for E release as non voting (on new patches only). At F release it becomes voting, but only on each new patch set. I have reserved a session at the summit for discussion around the tool and what direction we should take. > 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 > > <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 > > > So as I understand it, the reason for just doing a cursory check, is because the LF have a lawyer who checks over these each release. So as I understand it, the tool is there just to lighten the load and encourage people to apply a licence. Aside to this though, I am happy to implement whatever consensus arrives at. The main driver is really to clamp down on people pulling down files and repos from external sources that we don't know whether we can trust or not (we had once instance of external IP address, which turned out to be someones laptop left running). This is the big concern for me and other infra. The tool is set up right now to block all git clones / wgets / curls etc from anything apart from opnfv.org build servers and openstack.org sites. Its then easy to allow access to sites, once we know we can trust them. So we work with a principle of least privateer and extend from there. I know of a incident in a different project, where a developers SSH key was stolen, and someone staged malicious code into a repo that was then deployed into production, and this is what gives me the shudders. We have numerous operators and NEP's deploying opnfv into various LABs / sites and all it takes is one wayward Trojan binary to get included or a script to call home and pull something nasty in, and our reputation will go spinning down the toilet. So what might seem like an impedance to working quickly, is well worth the hindrance when we consider the possible fall out of something untoward finding its way into the 30+ repos we have. BTW I am talking to all now, and not just you Bryan who I know is already savvy on the topic. This is an interesting write up on the level of people we very likely have taking an interest in our code and build systems already: https://medium.com/@chrismcnab/alexseys-ttps-1204d9050551 - Its a scary read and a good view of the current landscape. > 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] | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: > +44 12 52 36 2483 > -- Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat e: [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
