| opendevreview | Tony Breeds proposed openstack/requirements master: Manually generated constraints https://review.opendev.org/c/openstack/requirements/+/900435 | 01:02 |
|---|---|---|
| opendevreview | Tony Breeds proposed openstack/requirements master: [DNM] Tools and data used for previous commit https://review.opendev.org/c/openstack/requirements/+/900436 | 01:02 |
| opendevreview | Takashi Kajinami proposed openstack/requirements master: Allow locally requiring a package for specific python versions https://review.opendev.org/c/openstack/requirements/+/901119 | 08:25 |
| SumitGupta153 | I had this question => Is there a way to conditionally include a statement like this in requirements.txt, where a package's certain level is installed if python version is 3.x.y ? For example, install zuul-sphinx>=0.2.0 only when python version is greater than 3.8.0 and got an answer for this on other channel, that while it is viable to do so by changing requirements.txt as (ex. cryptography>=41.0.3;python>=3.9), it | 09:24 |
| SumitGupta153 | is not recommended. | 09:24 |
| SumitGupta153 | frickler, what should be the place for it? I have seen this in ansible projects on opensource projects such as ansible collection. | 09:26 |
| frickler | SumitGupta153: what would be the reason for the zuul-sphinx constraint? | 09:31 |
| SumitGupta153 | That was just an example, my real targets are these packages: cryptography, certifi, requests | 09:58 |
| SumitGupta153 | https://security.snyk.io/package/pip/cryptography => There are vulnerabilities listed (and latest version is non-vulnerable) | 10:06 |
| SumitGupta153 | The reason for needing this change is, that we (at IBM) do security vulnerability scan of the products for all libs that are used in our products. Whenever a non-vulnerable version of the impacted lib is out, guidelines are to update to that version. | 10:11 |
| frickler | you could do that without enforcing this upstream, though? I'm really not sure whether this is a good idea, but maybe other people like fungi, tonyb or prometheanfire have other opinions | 10:13 |
| SumitGupta153 | 1. I think we can't. (We can just put it in IBM specific documentation to upgrade those libs to those levels). But, I think, since these are python libs, this change will positively impact everyone in community since they'll be on a more secure libraries levels). | 10:26 |
| opendevreview | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for python-neutronclient to new release 11.1.0 https://review.opendev.org/c/openstack/requirements/+/901126 | 10:51 |
| opendevreview | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for python-cyborgclient to new release 2.3.0 https://review.opendev.org/c/openstack/requirements/+/901127 | 10:54 |
| opendevreview | OpenStack Proposal Bot proposed openstack/requirements stable/2023.1: update constraint for oslo.messaging to new release 14.2.3 https://review.opendev.org/c/openstack/requirements/+/901128 | 10:58 |
| opendevreview | OpenStack Proposal Bot proposed openstack/requirements stable/yoga: update constraint for oslo.messaging to new release 12.13.3 https://review.opendev.org/c/openstack/requirements/+/901129 | 10:59 |
| opendevreview | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for etcd3gw to new release 2.2.0 https://review.opendev.org/c/openstack/requirements/+/901130 | 11:02 |
| opendevreview | OpenStack Proposal Bot proposed openstack/requirements master: update constraint for tooz to new release 4.3.0 https://review.opendev.org/c/openstack/requirements/+/901131 | 11:06 |
| fungi | SumitGupta153: that is what curated distributions are for. openstack is not a curated distribution of software, openstack is a software project. we explicitly do not track vulnerabilities in our dependencies, as we already have our hands full with the software we maintain | 13:08 |
| fungi | SumitGupta153: distributions like starlingx, sovereign cloud stack, ubuntu openstack, rdo and so on track and patch vulnerabilities in openstack's dependencies. if you're not using a curated distribution of software, then you have become the curator of your own distribution and doing that work falls on you | 13:10 |
| fungi | when we set specific minimum versions of dependencies, it's pretty much always because the software won't run and therefore can't be tested with older versions | 13:13 |
| fungi | basically, we try to track the oldest versions of dependencies that openstack *can* run with, and it's up to downstream consumers (usually distribution package maintainers) to either use newer versions of dependencies or backport fixes to dependencies in order to address any bugs in them | 13:16 |
| tonyb | SumitGupta153: With respect to the fundamental question which I interpret as "Can I list different minimums based on python version eg: library>=1.2.3;python_version==3.9\nlibrary>=2.0.0;python_version>=3.9" I don't think there is a technical reason for us to *NOT* support that. I don't think we do at the moment and with some concrete examples of when/why we'd need it I think we'd take chnages to support that in the tooling | 13:39 |
| tonyb | SumitGupta153: WRT the specific question around cryptography I believe you al ready have the answer from fungi | 13:41 |
| frickler | fungi: thx for adding some better context and wording around my vague ideas. though now I'm wondering whether scs is a distro or osism and whether maybe kolla should already handle some of this | 13:42 |
| fungi | frickler: i'm probably a little fuzzy on the dividing line between scs and osism (i guess the former is a set of specifications/standards and the latter is a conforming distribution?) | 13:43 |
| frickler | fungi: also, is the "we do not track vulnerabilities in our dependencies" documented somewhere? | 13:43 |
| frickler | and yes, it isn't completely clear to me, either | 13:43 |
| fungi | frickler: there's lots of things openstack doesn't do, we can really only reliably document the things we can do, not everything we can't. but the vmt does document in a couple of places that it doesn't do that | 13:44 |
| fungi | https://security.openstack.org/vmt-process.html#report-taxonomy describes "A vulnerability, but not in OpenStack supported code, e.g., in a dependency" as a class c2 report, the vmt doesn't produce security advisories for that but members of the community are welcome to add a security note about something to the security guide if it seems warranted | 13:45 |
| fungi | https://security.openstack.org/repos-overseen.html#requirements item #2 states "The VMT will not track or issue advisories for external software components. Only source code provided by official OpenStack project teams is eligible for oversight by the VMT. For example, base operating system components included in a server/container image or libraries vendored into compiled binary | 13:46 |
| fungi | artifacts are not within the VMT’s scope." | 13:46 |
| frickler | fungi: thx, that amply covers my question | 13:48 |
| fungi | if the kolla team wants to take on tracking and notifying users about vulnerabilities in non-openstack software it's shipping, then that sounds cool, but be absolutely sure it's something the team has bandwidth for before making promises to users and then potentially putting them in a bad spot when it turns out you can't do that reliably | 13:48 |
| fungi | the party line from the kolla team used to basically be something like "we provide pre-built images for evaluation purposes, but users are strongly encouraged to build their own carefully audited images if they plan to use them in production" | 13:50 |
| frickler | fungi: just noticed on the second link of yours there's a link to "extended maintainance" as https://security.openstack.org/phases which 404s | 13:50 |
| frickler | actually three of those links | 13:51 |
| fungi | thanks, i think that was supposed to go to releases.openstack.org | 13:51 |
| fungi | i wonder how sphinx didn't bomb on that | 13:51 |
| fungi | https://opendev.org/openstack/ossa/raw/branch/master/doc/source/repos-overseen.rst | 13:53 |
| fungi | looks like an error on my part. i'll fix the rst | 13:53 |
| fungi | frickler: https://review.opendev.org/c/openstack/ossa/+/901137 Update stable branch terminology for unmaintained | 14:11 |
| fungi | that should also fix the broken links | 14:11 |
| fungi | thanks for spotting it! | 14:11 |
| fungi | i suppose i could make it depends-on https://review.opendev.org/897505 that updates the project team guide similarly | 14:13 |
| fungi | but eventual consistency is okay for that document i think, since it's just guidance to the project teams on what deliverable repositories qualify for vmt oversight | 14:18 |
| frickler | +1 | 14:23 |
| opendevreview | Merged openstack/requirements master: update constraint for python-cyborgclient to new release 2.3.0 https://review.opendev.org/c/openstack/requirements/+/901127 | 21:03 |
| opendevreview | Merged openstack/requirements stable/yoga: update constraint for oslo.messaging to new release 12.13.3 https://review.opendev.org/c/openstack/requirements/+/901129 | 21:03 |
| opendevreview | Merged openstack/requirements master: update constraint for etcd3gw to new release 2.2.0 https://review.opendev.org/c/openstack/requirements/+/901130 | 21:03 |
| opendevreview | Merged openstack/requirements master: update constraint for tooz to new release 4.3.0 https://review.opendev.org/c/openstack/requirements/+/901131 | 21:03 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!