Hello Everyone. As promised, I prepared a draft of the proposal of changes that I would love if a number of interested people discuss it, comment, criticise, agree on eventually, and submit to the ASF Board for Approval.
I tried to capture all the context, but also I marked clearly all the proposals that I think should be included in the ASF policies and clearly marked changes that should be applied. I also tried to write it in the "future-proof" way - I tried to make statements that do not refer to the Images or Helm Charts, but describe general practices of "packaged" software as opposed to "compiled" software that seems to be the origin of the current policies. So my approach was really to try to describe and set policies around "software packaging" in general, rather than "Images/Helm Charts" in particular. However I believe it is much more to take the proposed policies and apply them directly to the Images and Helm Charts rather than the original policies. As promised I also commented (with inline comments), the places where I know there are some controversies - at least those that came up in our original discussions in Airflow - and I explained how I understand the controversies that are around that. I would really love to get a lot of comments and discussion around the proposal, before we submit the proposal - I am looking forward to your comments! The proposal is here: https://cwiki.apache.org/confluence/display/COMDEV/Updates+of+policies+for+the+convenience+packages J. On Wed, Sep 9, 2020 at 10:03 PM Jarek Potiuk <ja...@potiuk.com> wrote: > Issue in COMDEV created: https://issues.apache.org/jira/browse/COMDEV-382 > > I will prepare an early draft of the proposal shortly and ping here to > spark a discussion > > J. > > On Tue, Sep 8, 2020 at 5:59 PM Matt Sicker <boa...@gmail.com> wrote: > >> I've spent an inordinate amount of time at $dayjob triaging security >> vulnerabilities from Docker scans, so I can definitely attest to >> Mark's experience there. In fact, one of the biggest offenders was the >> official Docker Hub image for openjdk! Then there were a few years >> where people pushed Alpine Linux in containers, but then maintenance >> stopped related to that in openjdk, further leading to more outdated >> images. Then there's the fairly broad lack of security awareness in >> most published Docker images (e.g., running everything as root, >> installing unnecessary dependencies, leaving behind private keys, >> etc.) On the other hand, publishing updated images puts us back into >> the problem of distributing non-AL software. >> >> Note that you could be releasing a new image every day, yet that >> doesn't fix the problem of outdated upstream layers, nor is it easily >> fixable by adding an "apt-get update && apt-get upgrade -y" step as >> that breaches back into licensing complexity (Apache isn't a Linux >> distribution after all!). >> >> On Tue, 8 Sep 2020 at 07:37, Jarek Potiuk <ja...@potiuk.com> wrote: >> > >> > Will definitely include that in my proposal Mark! >> > >> > BTW. Speaking of the report you got, we got the user talking to us on >> > slack, and got the user to retest it on the refreshed image. >> > >> > It all boiled down to 4 "undefined" risk issues reported by the tool >> (seems >> > that their - reasonable - approach is that anything High or Undefined >> is a >> > blocker). And the root cause in this case is that the base image that we >> > used (python-debian-buster) contains those vulnerabilities. Most have >> been >> > fixed in other releases of Debian (stretch, bullseye), but the current >> > (buster) LTS patch has been released over a month ago (3rd of August). >> With >> > their release cadence (~ 1/month) , we should get it sooner rather than >> > later. And following our tooling - we will regenerate and rebuild our >> > images once this is available (we are planning to automate this part >> soon). >> > And I hope most or all of those will be addressed. >> > >> > Following your analogy, that's indeed very true that the images age like >> > milk, so it looks like you are supposed to replace it with a fresh >> bottle >> > from time to time. I will try to capture that as best practice. >> > >> > I am tempted to put your analogy to the proposal ;) I wonder whether the >> > Board shares the same sense of humour. >> > >> > J. >> > >> > >> > >> > >> > On Tue, Sep 8, 2020 at 12:36 PM Mark J Cox <m...@apache.org> wrote: >> > >> > > On Mon, Sep 7, 2020 at 2:21 PM Jarek Potiuk <ja...@potiuk.com> wrote: >> > > >> > > > I also talked to the Apache Security team today (there was an issue >> > > raised >> > > > about the security of the images which I think should be part of the >> > > policy >> > > > as well. >> > > > >> > > >> > > Thanks Jarek. What happened is that we got a report to >> > > secur...@apache.org >> > > about a docker container that when scanned showed a lot of "unfixed >> > > vulnerabilities". I'm using quotes there because our usual response to >> > > people sending us unfiltered reports from scanning tools is to reject >> them; >> > > we get them quite often outside of containers and binary >> distributions, and >> > > they very rarely are useful. It's also fairly likely that the >> majority of >> > > the reported issues in the container are completely irrelevant too. >> For >> > > example the list contained a CVE for a power9 gcc issue. These >> scanners >> > > are basically going to just report on all the things in the >> underlying base >> > > image that are not updated, and even if you recreated images every day >> > > you'd still have unfixed CVEs on the list. >> > > >> > > Containers and other similar non-source distributions don't age well >> (a >> > > colleague used to say they 'age like milk, not wine'), they'll >> collect more >> > > and more of these layer vulnerabilities over time, and although most >> will >> > > be irrelevant, there are going to be times when such a vulnerability >> does >> > > actually matter, and we need to make sure projects producing them >> have a >> > > process for tracking that either my monitoring (lots of effort) or by >> at >> > > least frequent rebasing to keep them fresh. >> > > >> > > That's all assuming projects are making good security decisions to >> start >> > > with; basing on images that are maintained, in life, and updated, >> making >> > > sure users know the state/freshness of them, making sure users realise >> > > there will be vulns in the underlying layers and how to escalate >> reporting >> > > vulns they find that actually are exposed to the project. That >> should all >> > > be part of some guidelines on images. >> > > >> > > Cheers, Mark >> > > ASF Security Team >> > > >> > >> > >> > -- >> > +48 660 796 129 >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org >> For additional commands, e-mail: dev-h...@community.apache.org >> >> > > -- > +48 660 796 129 > -- +48 660 796 129
