| gouthamr | frickler: priteau: sent an email to openstack-discuss proposing the cleanup of the group.. the TC's been handling that repo | 05:19 |
|---|---|---|
| opendevreview | Ivan Anfimov proposed openstack/governance master: Update Zun release/security liaisons https://review.opendev.org/c/openstack/governance/+/1002501 | 05:44 |
| opendevreview | Merged openstack/governance master: Update Zun release/security liaisons https://review.opendev.org/c/openstack/governance/+/1002501 | 06:02 |
| priteau | Thank you gouthamr | 09:40 |
| cardoe | gouthamr: I wanna bring up point releases and OSSN. I haven't added it to the agenda and I know it's late. | 14:49 |
| opendevreview | Jeremy Stanley proposed openstack/governance master: Propose SECURITY.rst goal https://review.opendev.org/c/openstack/governance/+/1002692 | 15:03 |
| cardoe | frickler: that ironic 35.0.2 you +2'd is part of ^ above. | 15:51 |
| tkajinam | one question. Do we accept a commit with Signed-off-by: <company name> ? | 16:22 |
| tkajinam | I mean a commit signed off by a person but a company | 16:22 |
| gouthamr | no | 16:22 |
| tkajinam | this is where I found that https://review.opendev.org/c/openstack/ceilometer/+/1003269 | 16:22 |
| gouthamr | tkajinam: this is legal territory, but, only humans/individuals can use the DCO signed-off-by imv | 16:23 |
| fungi | it looks like some company created a shared account not for an individual? but without knowing more it's certainly possible that there's a person named "fivetime" with that e-mail address too | 16:23 |
| gouthamr | yeah, could me an individual too? "fivetime <td@fivetime.ltd>" | 16:24 |
| fungi | right now we're assuming it's impossible that a person named "fivetime" wrote and proposed that change | 16:24 |
| tkajinam | I'm not sure if that ltd domain can be used by a person, not by a company | 16:25 |
| fungi | gerrit makes sure that at least one signed-off-by matches the committer and, further, isn't configured to allow normal users to push changes for which they're not the committer | 16:25 |
| tkajinam | but I'll ask the author to clarify that | 16:25 |
| gouthamr | that change also has "Co-Authored-by: Claude ..." ; that should be dropped as well.. | 16:27 |
| gouthamr | We use "Assisted-By" for this sorta thing | 16:27 |
| fungi | for completeness here, https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-with-dco-for-all-contributions.html passed by the tc last year refers to https://developercertificate.org/ | 16:27 |
| fungi | by adding a `signed-off-by` trailer, the account holder/committer is asserting that the statement there is completely true | 16:28 |
| tkajinam | yeah | 16:29 |
| fungi | i don't see where we have anything in writing that explicitly states a legal entity such as a corporation can't agree to and assert those things (through a representative), though i've heard it said fairly often that signed-off-by has to be applied by a person | 16:30 |
| fungi | it's a bit of a grey area | 16:30 |
| * gouthamr gah, forgot the reminder to the reminder | 16:31 | |
| gouthamr | tc-members: a gentle reminder that our weekly IRC meeting will be hosted here in ~29 minutes | 16:31 |
| fungi | if the tc wants to require the dco be asserted only by an individual "natural person" and not by a "legal person" such as an organization, it might be a good idea to make that clear somewhere | 16:31 |
| gouthamr | tc-members: agenda is here: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 16:31 |
| fungi | (in most jurisdictions i'm familiar with, an officer of a corporation can legally enter into a binding agreement on behalf of that organization, for example) | 16:32 |
| gouthamr | fungi: i'd hope the foundation can clarify this. it may be hard to meaningfully implement beyond someone maybe catching it in code review | 16:32 |
| clarkb | kernel docs say only humans can sign it fwiw | 16:32 |
| dansmith | ++ for humans | 16:32 |
| clarkb | which I take to mean no legal entities or LLMs | 16:32 |
| fungi | yes, i think it can't hurt for us to say that somewhere, but an officer of a company agreeing to the dco is a person doing it | 16:32 |
| clarkb | fungi: right but they should sign it as a human then | 16:33 |
| clarkb | Johndoe@corpemail.com | 16:33 |
| fungi | i agree, but we don't say that anywhere that i can find | 16:33 |
| tkajinam | that's why I asked that question here, in fact. | 16:34 |
| clarkb | fwiw my read of the DCO itself is that you don't need to explicitly state it as its already there | 16:34 |
| clarkb | corporations don't use first person pronouns | 16:35 |
| tkajinam | I'll ask the auther if a human name can be used there instead, but if that's rejected I may need some more official clarifications to find an official solution | 16:35 |
| tkajinam | I'll come back here in that case... hoping I don't need that | 16:35 |
| fungi | i've also asked folks in openinfra foundation executive management | 16:36 |
| tkajinam | oh thanks. | 16:37 |
| fungi | part of why it's an odd situation is that the copyright on code written as a "work for hire" is held by the employer, a company, which is a vast majority of the code that makes it into openstack. with the dco we're asking someone whether they have the permission of the copyright holder, i.e. the company which employs them | 16:38 |
| fungi | i'm not a lawyer, but i can certainly see an argument for the copyright holder asserting the dco | 16:39 |
| fungi | also there doesn't seem to be a website attached to that domain and i can't look up whois details for it either, so it's entirely possible it's the business name for a single-person consultancy or even just someone's personal vanity domain | 16:46 |
| tkajinam | fungi, yes. there are a few points needing clarification from both the author and foundation to find the right path, I think | 16:51 |
| tkajinam | there are still number of items I'm still "guessing" | 16:51 |
| gouthamr | #startmeeting tc | 17:01 |
| opendevmeet | Meeting started Tue Sep 1 17:01:11 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:01 |
| opendevmeet | The meeting name has been set to 'tc' | 17:01 |
| gouthamr | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 17:01 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| spotz[m] | o/ | 17:02 |
| cardoe | o/ | 17:02 |
| gouthamr | noted absence: m n a s i a d k a | 17:02 |
| dansmith | o/ (kinda) | 17:02 |
| noonedeadpunk | o/ | 17:03 |
| gouthamr | courtesy-ping: frickler bauzas | 17:03 |
| bauzas | o/ | 17:04 |
| bauzas | back from PTO folks | 17:04 |
| gouthamr | welcome back | 17:05 |
| gouthamr | let's get started | 17:05 |
| gouthamr | #topic Last week's action items | 17:05 |
| gouthamr | AC/APC active-core-reviewer election-tooling changes should have all merged, ty for your work there, fungi | 17:06 |
| gouthamr | #link https://review.opendev.org/q/hashtag:%22core-reviewers-as-ac-apc%22+(status:open%20OR%20status:merged) | 17:06 |
| gouthamr | the TC election is underway | 17:06 |
| frickler | \o | 17:06 |
| gouthamr | and will conclude at 23:45 UTC on Sep 16 2026 | 17:07 |
| gouthamr | #link https://governance.openstack.org/election/ | 17:07 |
| gouthamr | if you haven't noticed a ballot email, log into civs and check please, because CIVS needs an opt-in for emails for the past few years | 17:07 |
| gouthamr | #link https://civs1.civs.us/cgi-bin/opt_in.pl (CIVS Opt-in) | 17:08 |
| gouthamr | i think the 2027.1 runtime update is on track | 17:10 |
| gouthamr | #link https://review.opendev.org/q/topic:%222027-1-testing-runtime%22 | 17:10 |
| gouthamr | next week after the RC1 patches roll in, gmaan will unblock the rest of the changes | 17:11 |
| gouthamr | the last action item i was tracking was regarding PTL appointments | 17:12 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/1002415 (Appoint PTLs to Glance/Skyline/Masakari for 2027.1) | 17:13 |
| gouthamr | we've gathered some +1s there, need a few more Roll-Call votes so we can close this out | 17:13 |
| gouthamr | alright, that's a wrap for action items | 17:15 |
| gouthamr | were you working on any and would like to share? | 17:16 |
| gouthamr | #topic Consistent project management | 17:17 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/KPLX44YX6VEAJT4SZ3T7CJ3K2U6HJUTZ/ ([tc][all] Proposal: require projects to document their path to (and standard for retaining) core status) | 17:18 |
| cardoe | So it's been fairly quiet on this one. | 17:19 |
| gouthamr | cardoe brought this up here a couple of weeks ago, and it evolved into a good discussion. there are several angles to this, and the common denominator that i saw consensus on was that we need to document conventions/rules on how someone can become a project maintainer.. | 17:19 |
| cardoe | I will say I joined the neutron team meeting this week and they discussed the topic and I felt like the discussion was positive. | 17:20 |
| cardoe | They brought up some folks that were cores that hadn't been reviewing in a while and they had emailed them about their involvement without a reply. | 17:20 |
| gouthamr | he does have a second item there regarding dropping cores, but we can try and get this first topic some more discussion to see if there are any thoughts | 17:20 |
| cardoe | And it lead back to what clarkb and I discussed after the last tc meeting that they felt it was a bit of a security concern that those folks were cores without reviews in a year and not replying. | 17:21 |
| cardoe | So just sharing that as one project's "feedback" | 17:21 |
| cardoe | I can get something written up for the governance repo and propose it if that sounds like a good next step. | 17:22 |
| gouthamr | i think its a good next step | 17:22 |
| gouthamr | can you link us to the discussion? | 17:22 |
| cardoe | or the project-team-guide? | 17:22 |
| spotz[m] | Might also be a good discussion topic and working session for the PTG | 17:22 |
| opendevreview | Merged openstack/governance master: Fix election script edits https://review.opendev.org/c/openstack/governance/+/1002409 | 17:22 |
| cardoe | https://meetings.opendev.org/irclogs/%23openstack-neutron/%23openstack-neutron.2026-09-01.log.html it really starts around 13:53 | 17:23 |
| cardoe | spotz[m]: sure that works as well | 17:23 |
| gouthamr | cardoe: you could try a cross project goal if you'd like to see documented process | 17:24 |
| gouthamr | ty for the link, i scrolled right past it :) | 17:24 |
| cardoe | What repo would that be? | 17:25 |
| gouthamr | but yeah, looks like a familiar problem: "contacted X to see about removing X from core team but have not had a response" | 17:25 |
| gouthamr | governance | 17:25 |
| gouthamr | cardoe: https://review.opendev.org/q/project:openstack/governance+(topic:goal-proposal+OR+hashtag:goal-proposal) | 17:26 |
| cardoe | okay yes that's what I was originally thinking. | 17:26 |
| gouthamr | you could add the project-team-guide content too, but a goal is a way for a champion or a group of people to work with project teams and get something done | 17:27 |
| TheJulia | One thought of caution, a documented process requires something/someone to execute the process | 17:27 |
| TheJulia | in other words, process without a report, or processes without a trigger are less meaningful. | 17:27 |
| TheJulia | They are great in principal and getting on the same page though, lets just not trap ourselves in that thought process, because it only then ends up being a starting point to iterate upon | 17:28 |
| gouthamr | yeah, i think as you were discussing here, maybe project teams should discuss what inactivity means from a core reviewer and document it clearly. anyone from a core-reviewer team has permissions to add/remove core reviewers on gerrit.. but, traditionally, the PTL has done so in PTL-led teams | 17:29 |
| TheJulia | Yeah, setting that expectation would be an ideal outcome | 17:30 |
| gouthamr | so, maybe the "inactivity check" is a once-per-cycle check that someone does; or maybe more aggressively if the project chooses to.. either case, it'd be better than status quo | 17:31 |
| TheJulia | Well, someone does is the challenge. It really needs to be like a monthly automated report or soemthing like that. | 17:31 |
| TheJulia | but, that may be a longer term thing. | 17:31 |
| gouthamr | since core reviewers are nominated with trust, ideally there's some communication when someone steps away. this process to dropping someone is purely an objective test if there's no communication | 17:32 |
| TheJulia | Going back to the security concern standpoint, I've had some folks express the same concern to me as of recent, so I think we're at a point where more eyes are on the topic which mirrors discussion so far | 17:32 |
| TheJulia | Life does happen, the concern is if someone's account with rights gets compromised. | 17:33 |
| * TheJulia misses Ilya | 17:33 | |
| TheJulia | Anyway, back to my other screen, thanks folks! | 17:33 |
| gouthamr | inserts obligatory: "we'd welcome you back with t-rex arms if you'd like" | 17:33 |
| TheJulia | gouthamr: lol, that cheered me up after the sad thought, thanks! | 17:34 |
| gouthamr | no really, code review and project maintenance is service, and people with the best intentions do this work... so if they have to step away, it's okay.. happens all the time, and the hope is the teams are sustainable to survive these sort of removals | 17:35 |
| TheJulia | well said | 17:36 |
| gouthamr | ++ | 17:38 |
| gouthamr | no really, this is service, and its appreciated | 17:38 |
| gouthamr | grr, line in copy-paste | 17:38 |
| gouthamr | any further thoughts here? | 17:38 |
| fungi | it's why core review activity is now counted officially as qualification for active reviewer status | 17:39 |
| fungi | er, active contributor status i mean | 17:39 |
| gouthamr | ++ | 17:39 |
| gouthamr | if not, something from a similar vein: | 17:40 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/KLUURVAJWNJCNBOVYNX5CXZ3C2F4Y3ZU/ (Recommended approaches to improve contributor and maintainer experience) | 17:40 |
| gouthamr | we can discuss this separately if warranted, some very cool ideas here | 17:40 |
| gouthamr | mharley[m]: are you around? | 17:42 |
| gouthamr | cardoe: do you need anything else to start on this proposal? | 17:42 |
| mharley[m] | Hey, have I been summoned? 😊 | 17:43 |
| cardoe | Nope. I'm good. | 17:43 |
| gouthamr | mharley[m]: i guess so, your topic is next | 17:43 |
| gouthamr | ty cardoe | 17:43 |
| gouthamr | #topic PQC Readiness community goal proposal (mharley) | 17:43 |
| gouthamr | mharley[m]: the floor is yours | 17:43 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/1001777 (Add PQC Readiness as a proposed community goal) | 17:43 |
| mharley[m] | Ops, I was not expecting to participate today. | 17:44 |
| mharley[m] | Anyway, no problem. | 17:44 |
| mharley[m] | So, the goal has been submitted. | 17:45 |
| mharley[m] | It is organized in three milestones: the first one (2027.1) focuses on removing barriers that prevent PQC key exchange from working on platforms that already support it, like replacing deprecated SSL APIs and cleaning up hardcoded algorithm choices. | 17:45 |
| mharley[m] | The second one (2027.2) is about crypto agility for asymmetric operations in Barbican, Glance image signing, and Castellan. | 17:46 |
| mharley[m] | The third one (2028.1) targets end-to-end PQC for new deployments, once upstream libraries like pyca/cryptography ship ML-DSA and ML-KEM support. | 17:47 |
| gouthamr | this "crypto agility" terminology is funny | 17:47 |
| mharley[m] | The pop-up team is driving the work and offering guidance to any project that wants to address their own findings. We are not asking projects to take on work; we are offering support and a reference point. | 17:47 |
| fungi | the industry has gone back and forth on the benefits and risks of cryptographic "agility" | 17:48 |
| mharley[m] | It might be, gouthamr, but the message here is one only: to speed up post-quantum security whereas at the same time still keeping backwards compatibility. | 17:48 |
| fungi | (several times already) | 17:48 |
| fungi | making protocols more flexible in choosing alternative cryptographic primitives has itself been the source of many, many security vulnerabilities | 17:49 |
| mharley[m] | The risk exists regardless of the terminology and of some individuals’s convictions. That’s a fact. 😊 | 17:49 |
| mharley[m] | s/s// | 17:49 |
| fungi | more systems have been compromised through broken implementations due to the added complexity than through people actually attacking the cryptography itself | 17:50 |
| TheJulia | mharley[m]: I think the issue you face is more perception management and context building. | 17:50 |
| gouthamr | ack, no problem with making sure we don't pigeon-hole into specific implementations.. | 17:52 |
| mharley[m] | That’s one of my concerns, fungi: parts of the community insist on keeping using weak algorithms and methods for the sake of tradition of some questionable value. | 17:52 |
| fungi | yes, i don't mind keeping updated to stronger cryptographic standards, but "agility" for its own sake adds complexity which is an increased attack surface for just bypassing the cryptographic protections entirely | 17:53 |
| fungi | classic "downgrade attacks" are one of the more popular examples there | 17:54 |
| TheJulia | mharley[m]: Your making a huge generalization there which is not helpful to your cause. See perception management and context building comment from earlier. As an example, I've had folks push back because their regional standards body hasn't signed off on the "shiny new algorithm". | 17:55 |
| mharley[m] | TheJulia: maybe, but the issue is not only mine. I think a bit more of acceptance than simple questioning would help a lot. | 17:55 |
| mharley[m] | I’m not trying to push anything but it’s being a bit hard to communicate a message that should be simple. 🤔 | 17:55 |
| mharley[m] | It’s not a buzzword. It’s a trend. | 17:55 |
| fungi | that's been my concern historically with the "fips" goal as well, usa nist is not as generally trusted worldwide as a lot of people living in the usa seem to assume | 17:56 |
| TheJulia | mharley[m]: you need to win hearts and minds, build consensus. | 17:56 |
| gouthamr | trend/buzzword - same thing, is corporate-speak like "zero-trust". | 17:56 |
| gouthamr | but, no offense to you mharley[m] | 17:56 |
| gouthamr | its just the weirdness of wanting to name something and sounding all-encompassing | 17:56 |
| TheJulia | fungi: and I think that is now on a direct path to "zero-trust" ;) | 17:57 |
| fungi | and many people, when they see usa nist pushing some particular angle, today suspect ulterior motives | 17:57 |
| gouthamr | yes, my first comment on the goal would be that ^ | 17:57 |
| TheJulia | fungi: yeah, that is some of the same push back I've gotten on some changes as well. | 17:57 |
| fungi | TheJulia: yes, i have "zero trust" in lattice cryptography, for example, and suspect that certain actors are promoting it because they know how to break it | 17:58 |
| gouthamr | i think we've been burned by making recommendations from a single country sound like canon.. so, we could lighten that up a bit.. OpenStack is used globally, and we shouldn't sound like our security posture mirrors that of the US government | 17:58 |
| gouthamr | but the meat of the goal itself, the flexibility of choice seems fine.. i don't have a technical pushback to offer there. ty for refining this and sharing the details here | 17:59 |
| gouthamr | the timeline may be something that needs a wider discussion, perhaps on the change itself or with project teams | 17:59 |
| gouthamr | at the PTG | 17:59 |
| mharley[m] | Thanks, gouthamr. I’m glad you guys realize this is not about mharley, it’s about security. | 18:00 |
| TheJulia | But to the point, the key is to build shared vision. Security means different things to different people. | 18:01 |
| mharley[m] | It’s a vast topic, indeed. | 18:02 |
| gouthamr | ++ maybe some of this can be security guidelines in security.openstack.org.. i'd invite you to take that route for new projects/features | 18:03 |
| mharley[m] | Yep, I’ll take the advice. | 18:03 |
| gouthamr | alright, we're past the hour | 18:03 |
| gouthamr | can't get to the standing topics today | 18:04 |
| gouthamr | but let's stop here, ty mharley[m] | 18:04 |
| gouthamr | is there anything else for the minutes today? | 18:04 |
| gouthamr | fungi mentioned some health concerns that the release team identified for a couple of tacker team deliverables, we can follow up async; and, frickler/priteau observed that we need to fix the "service-types-authority" core list: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/UNBVEOMWMNAWZBQ5EHCCJCSTPF256JGT/ | 18:05 |
| gouthamr | tty about both of those in the next meeting perhaps, or in between if we get a chance. | 18:06 |
| gouthamr | thank you all for attending | 18:06 |
| gouthamr | #endmeeting | 18:06 |
| opendevmeet | Meeting ended Tue Sep 1 18:06:25 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:06 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-01-17.01.html | 18:06 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-01-17.01.txt | 18:06 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-01-17.01.log.html | 18:06 |
| spotz[m] | Thanks all | 18:06 |
| mharley[m] | YW, gouthamr. Appreciate the opportunity. | 18:07 |
| gouthamr | dansmith: cardoe bauzas: can you RC +1 https://review.opendev.org/c/openstack/governance/+/1002415 | 18:55 |
| opendevreview | Ivan Anfimov proposed openstack/project-team-guide master: Fix typo https://review.opendev.org/c/openstack/project-team-guide/+/1003365 | 19:34 |
| opendevreview | Ivan Anfimov proposed openstack/project-team-guide master: Fix typo https://review.opendev.org/c/openstack/project-team-guide/+/1003365 | 19:36 |
| opendevreview | Merged openstack/project-team-guide master: Fix typo https://review.opendev.org/c/openstack/project-team-guide/+/1003365 | 19:54 |
| cardoe | Alright so another conversation I wanted to have is about release tags. | 20:27 |
| * fungi perks up | 20:28 | |
| cardoe | I started in the ironic channel. So I'll use the example I used there. | 20:28 |
| cardoe | https://security.openstack.org/ossa/OSSA-2026-017.html | 20:28 |
| cardoe | Ironic: >=17.0.0 <26.1.7, >=27.0.0 <29.0.6, >=30.0.0 <32.0.2, >=33.0.0 <35.0.2 is translated by GitHub security DB into https://github.com/advisories/GHSA-jrh2-f5jc-xpgr | 20:29 |
| cardoe | Even NIST https://nvd.nist.gov/vuln/detail/cve-2026-46447 | 20:29 |
| fungi | can you explain what's wrong with it? | 20:29 |
| cardoe | So 35.0.2, 32.0.2, 29.06 don't exist | 20:30 |
| cardoe | Those btw correspond to OpenStack 2026.1, 2025.2, and 2025.1 | 20:31 |
| fungi | and | 20:31 |
| cardoe | It's a public perception thing. | 20:31 |
| fungi | can you solve the problem of predicting what the fixed version will be in advance? | 20:31 |
| cardoe | A number of tools attempt to pattern match against requirements.txt and pyproject.toml | 20:31 |
| cardoe | Well the security advisory was published June 3rd. | 20:32 |
| fungi | yes, though it was communicated to downstream stakeholders in mid-may | 20:32 |
| gouthamr | cardoe: its good hygiene to get those releases tagged.. JayF mentioned (and i read on #openstack-ironic too) that ironic folks deliberately held off releases to cover a bunch of security fixes in the same releases | 20:33 |
| gouthamr | maybe do it now? :) better late than never | 20:33 |
| cardoe | A number of security auditing tools still flag an unreleased value. | 20:33 |
| cardoe | gouthamr: yeah I've requested it. | 20:33 |
| gouthamr | ++ perfect, i've been doing it for all repos with OSSAs other than ironic.. | 20:33 |
| gouthamr | or nudging people to.. | 20:34 |
| cardoe | gouthamr: I'll cut to the end point. But there's a lot of work for humans here and it's quite repetitive and manual. | 20:34 |
| cardoe | So I looking to suggest some addition to the bot for proposing releases. | 20:34 |
| fungi | i can't tell if your concern is that we've specified upper bounds that end up not being actual versions that are tagged and never exist, or that teams aren't getting backports merged and tagged in a timely fashion after the advisory is published | 20:34 |
| cardoe | fungi: the patches live in stable/2026.1 for example | 20:34 |
| fungi | so clarification appreciated | 20:34 |
| gouthamr | cardoe: https://review.opendev.org/c/openstack/agentic-workflows/+/995136 | 20:34 |
| cardoe | But folks aren't running pbr against repos. | 20:35 |
| fungi | i'm not sure what it means to run pbr against a repo | 20:35 |
| cardoe | Especially when they're using audit tools from companies. | 20:35 |
| fungi | let's rewind. what is your proposal? | 20:35 |
| fungi | i'm having trouble untangling your actual concern | 20:35 |
| cardoe | We need to make release tags near the time of the announcement being published. | 20:35 |
| cardoe | I don't want to put that work on humans. | 20:36 |
| fungi | okay, i'm not sure how we can do that if the changes they would tag don't merge right away, so that needs to be solved first | 20:36 |
| gouthamr | by announcement, you mean OSSA or OSSN? | 20:36 |
| cardoe | OSSA | 20:37 |
| gouthamr | if yes, i agree with fungi.. we have problems getting fixes merged in many projects on the day of the announcement | 20:37 |
| fungi | the current process relies on "eventual consistency" since we don't have project managers to coordinate advisory publication, core reviewers, ci/cd and release requests | 20:37 |
| fungi | they're all handled independently by disaggregated groups of community participants | 20:37 |
| cardoe | I was going to suggest something like a header "Release: patch" | 20:38 |
| cardoe | And when that commit landed in a stable/<blah> branch the bot could auto-propose a patch bump. | 20:39 |
| fungi | the vmt asks teams to please prioritize reviewing the fixes once they're pushed to gerrit and to keep an eye on them to make sure they merge, and to reach out to me or others if the need ci to prioritize certain changes because of backlogs | 20:39 |
| fungi | once the release request is proposed, the release team will need a ptl or release liaison to acknowledge the request as well, so there's still a team representative in the loop even if we auto-propose release patches, just be aware | 20:40 |
| fungi | it potentially saves a step though, sure | 20:40 |
| * gouthamr does the deed for OSSA-2026-037 | 20:40 | |
| fungi | would you want the automation to wait for all the backports to merge and then combine them into a single release request, or propose them one at a time as they merge? | 20:41 |
| cardoe | I dunno. Just floating an idea out here. | 20:41 |
| cardoe | You wanna know where all this came from? | 20:41 |
| cardoe | My kids are in Boy Scouts. I went along on the last camp out. | 20:42 |
| cardoe | Another dad works for GitHub on their security product. | 20:42 |
| fungi | usually the human proposing them groups them into a single release request, but sometimes an older branch has trouble with some unexpected test bitrot for example | 20:42 |
| cardoe | We got to talking about software at one point. | 20:42 |
| cardoe | We somehow got to OpenStack and he mentioned how it shows up in the GitHub vulnerability DB. | 20:43 |
| cardoe | Another dad is his company's software security person. | 20:43 |
| fungi | so under current practice there's a human judgement call to balance putting more workload on the release team vs getting things that can be released done sooner | 20:43 |
| * gouthamr https://review.opendev.org/c/openstack/releases/+/1003379 - gtema, PTAL | 20:43 | |
| cardoe | They use OpenStack somewhere. He complained how OpenStack always fails all security audit tool stuff and he has to get exceptions. | 20:43 |
| cardoe | So my sample size is 2 random adults in the world complaining about the perception of OpenStack and security. | 20:44 |
| clarkb | fwiw this is a common issue with distros like debian (because they backport fixes and don't pull the latet relaese) | 20:44 |
| fungi | neat that github is using openstack, i had never heard that but i know some people who would love to hear more ;) | 20:44 |
| cardoe | So it just got me thinking that it was a bad perception for us to have as a project. | 20:44 |
| clarkb | if you look on quay it complains about all the debian images for this reason | 20:44 |
| fungi | i don't think we have a bad perception as a project, if anything we are often cited as an example of doing this the right way | 20:45 |
| cardoe | fungi: GitHub isn't. He works on GitHub's security tooling product they sell. | 20:45 |
| cardoe | The other dad works for a NASA contractor. | 20:45 |
| fungi | and our process has been reused by lots of other projects and enshrined in popular recommended practices | 20:45 |
| cardoe | alright well nevermind then | 20:46 |
| fungi | we were a pioneer of transparency in vulnerability handling for community-developed open source | 20:46 |
| fungi | that's not to say that we're perfect and i'm happy to entertain improvements, but chesterton's fence and all | 20:46 |
| * gouthamr is not opposed to some automation to propose releases automatically | 20:47 | |
| fungi | the processes we follow have been slowly evolved over the past 16 years and most of what's there is for a very good reason, so first it helps to understand the reason something is done before recommending it be changed | 20:47 |
| clarkb | Anyway I bring up the distro patching problem because maybe if the audit tools have solved it for them (unlike quay) perhaps there is a solution there? | 20:47 |
| clarkb | I guess the distros do bump their specific versions with a suffix indicating the distro patch level which is probably what audit tools look at? | 20:48 |
| cardoe | Maybe? | 20:48 |
| clarkb | which sin't helpful here if the problem is the release is missing int he first place | 20:49 |
| cardoe | I don't use any of them and don't have access to them. | 20:49 |
| fungi | but yes, this is the reason our advisories link to the changes in gerrit rather than telling people to install a particular release, because we acknowledge that releases may lag behind the announcement by an unpredictable amount of time | 20:49 |
| cardoe | I do personally use https://docs.renovatebot.com/ and it uses version source catalogs / DBs. | 20:49 |
| cardoe | And they've got stuff like a docker registry and pypi registery as a source of info. | 20:50 |
| cardoe | I suspect that's what these other tools are doing similarly. | 20:50 |
| fungi | auto-proposing release requests is not a bad idea per se, but as always the devil is in the details (like for example the batching dilemma i mentioned), and it doesn't necessarily speed things up since the usual delays are getting the changes merged at all, and getting the ptl or release liaison involved in the release request (whether they propose it or merely acknowledge it) | 20:50 |
| cardoe | I'm just using renovate to propose new version bumps. | 20:50 |
| cardoe | All I'm bringing is a data point to the table and looking to discuss it with a wider audience if there's any value in the data. | 20:52 |
| cardoe | In some of my own stuff I've got a requirements.txt which has ironic==35.0.1 pinned | 20:53 |
| cardoe | Cause that's what renovate bumped it to. | 20:53 |
| cardoe | If that had any kind of auditing for like clarkb pointed out of quay then it would probably show up as vulnerable. | 20:54 |
| cardoe | It's just a GitHub Action to utilize some of the code to run tests so it's w/e. | 20:54 |
| cardoe | What I don't want to do is add more manual work to humans though. | 20:56 |
| fungi | yes, historically we expected distribution package maintainers to backport the patches we publish to their maintained packages, and considered users who don't rely on a curated distribution to be maintaining their own de facto distribution (because realistically they are) | 20:56 |
| fungi | naively installing openstack from pypi isn't "safe" and if you jump in your time machine and go back about 10 years we intentionally didn't publish service releases to pypi because of that | 20:58 |
| fungi | we started putting them on pypi as a convenience for our own testing | 20:58 |
| TheJulia | so, from a $0.02 perpsective, on a stable branch, we should seek to just drive towards an engagement doesn't explicitly require a bunch of humans because perceptions are important and humans can easily not notice and other's can gain damaging perceptions | 20:58 |
| fungi | we'll have to drop testing to achieve that, but i'm not entirely opposed to the idea | 20:59 |
| fungi | right now, final testing of backports is usually the primary delay, especially on older maintained branches | 20:59 |
| TheJulia | I'm not sure what you mean by testing to achieve that because it also seems feasible. I guess I'm just trying to get people accustomed to the idea what humans shouldn't be in the middle of all things. | 21:00 |
| TheJulia | Reasonable gates/controls makes a ton of sense and all, but milage may vary | 21:00 |
| fungi | most of it is babysitting stable branch testing to make sure the fix doesn't merge with an unnoticed regression | 21:00 |
| cardoe | Yeah I don't really think we need human sign off for these release tags to be made. | 21:00 |
| clarkb | you can push the patch the stable branch but if it doesn't pass testing then you need humans in the loop to either fix that or make a judgement that it can be overridden | 21:00 |
| TheJulia | fungi: do you mean additional human stable branch testing? or automated? | 21:01 |
| cardoe | clarkb: sure but if it passes tests and it has a magical header like "Release: patch". We could do X.Y.Z+1 automatically when that patch lands in the stable branch. | 21:01 |
| TheJulia | agree completely | 21:01 |
| fungi | the automated stable branch testing is often finicky on older stable branches due to bitrot | 21:01 |
| TheJulia | Yes, but those can be managed | 21:02 |
| fungi | and also sometimes the developers have just flat out forgotten to include an additional patch they relied on in one of their backports | 21:02 |
| TheJulia | I guess maybe whatever drives the releases should ensure no CI job config changes occur, so maybe a little more nuanced | 21:02 |
| fungi | by "those can be managed" you mean without human intervention? | 21:02 |
| TheJulia | (just so someone can't somehow shove something in which turns off testing and etc | 21:02 |
| TheJulia | fungi: should be managed as part of normal care and feeding, i.e. fixing those jobs is disjointed from, for example, a security issue being backported and landed | 21:03 |
| TheJulia | at least, ideally. | 21:03 |
| fungi | i'm just saying right now there are humans in the loop at these steps precisely because eliminating them leads to problems. obviously fewer problems would be a great goal to work toward, but don't we already try to prioritize eliminating problems? | 21:03 |
| clarkb | I think we proved that ideal is impossible sometime in 2013 | 21:03 |
| clarkb | we set up email notifications so people could get alerts when periodic jobs fail and fix them and literally no one paid attention and things only got fixed when trying to make some other change | 21:04 |
| clarkb | (less testing as fungi mentioned is probably a more reliable path if that is something we want to accomplish) | 21:05 |
| fungi | though the reason for that is people have trained themselves to ignore e-mail. what we need is to collect everyone's phone numbers so we can send them text messages | 21:05 |
| fungi | i don't actually keep my cell phone on me most of the time, but i've heard a lot of other people do | 21:06 |
| TheJulia | fungi: but, what is basically being advocated for is post merge releasing or post-merge automatic release on stable branches as opposed to "hey, human, remember todo that" | 21:06 |
| TheJulia | or "hey, human, oh.... your on leave... oh" | 21:07 |
| fungi | yes, i'm not against adding some post or promote job to openstack projects that proposes release requests, though i noted some of the choices an implementation is going to have to make when someone has time to start buildingit | 21:07 |
| TheJulia | yup | 21:08 |
| fungi | i don't personally have time to create that without stopping doing other things that need to be done, but if someone else is excited to make it them i'm in favor of giving it a try | 21:08 |
| fungi | it eliminates one step for humans, but it's just one step out of many others | 21:08 |
| fungi | we're still going to need humans to push the security fixes to gerrit, to review/approve them, to make sure they actually successfully run the test gauntlet and merge, then to acknowledge(ptl or liaison)/review(release manager)/approve the release request | 21:10 |
| TheJulia | yeah, but to my point, people being able to land and then remembering to cut a release is disjointed because we've not made humans nor are they motivated by downstreams to cut new upstream releases | 21:11 |
| cardoe | fungi: I'll write it | 21:12 |
| fungi | another consideration is that, especially lately, we're not only batching up releases from multiple stable branches but also batching up fixes from multiple security advisories into a release, in order to not have to constantly adjust the predicted fixed version numbers in published advisories | 21:12 |
| TheJulia | they are motivated to get the thing in place so they can proceed to their next step in their long list of things to do | 21:12 |
| cardoe | I just wanted to bring it up at a project wide level because I think it'd be useful for all to have. | 21:12 |
| fungi | the keystone advisory linked as an example was one of multiple keystone advisories published the same day, so we'd want them to have the same fixed versions | 21:13 |
| TheJulia | I think it might be safe if we have some sort of automatic "x amount of time has passed" thing, then it makes it pretty easy to know what the next patch level release would be | 21:13 |
| fungi | er, i guess the linked example was an ironic advisory, the one gouthamr proposed the releases for was keystone | 21:13 |
| cardoe | I use GitHub labels for this stuff. Someone sends me a PR on a Rust crate or a PyPi project and I might label it "backport" or I'll label it "release:minor". If I've labeled it "backport" then it'll automatically try to backport it to each of my stable branches and automatically cut a release from those stable branches when I merge their PR. If I've labeled it "release:minor" then it'll bump the minor version and cut a release. | 21:14 |
| fungi | yes, i think it has the potential to be a time-saver, but just to be clear the reason it doesn't exist as automation already has nothing to do with nobody thinking of it, rather that it's not as logistically simple a problem to solve as it sounds like | 21:15 |
| fungi | cardoe: right, pbr supports that same sort of labeling, though it's done in commit message trailers instead of pr labels | 21:15 |
| cardoe | Yes. I've seen it. Hence why I proposed using the commit message body the same way and having the bot propose them. | 21:16 |
| fungi | but you can signal minor or major version increases automatically in the commit message that way, and some projects do rely on that | 21:16 |
| fungi | an approach like constraints proposals use may solve some of the batching problems, by continuously pushing new patchsets to an existing change as long as there's one open, and starting a new change if there isn't one yet | 21:17 |
| gouthamr | i like batching mainly to avoid regressions releasing things out of order | 21:18 |
| fungi | yeah, i think as long as you design it to be at least idempotent and at most additive then it can batch successfully, with a batch being concluded by approving the change and getting it to merge | 21:20 |
| TheJulia | And to be clear, we're taling about perception management and relatively making sure something does happen, not immediate tack it along and get it shipped into pypi ASAP | 21:20 |
| TheJulia | I think, cardoe has been just trying to see if there was interest/thoughts in alignment because that would help push back the negative perception which can result from forgetting to do an upstream only activity | 21:21 |
| cardoe | I was sitting in the woods without technology and reading a book... well dang it... it was an e-ink reader so I did have technology... | 21:22 |
| TheJulia | DOH! | 21:23 |
| TheJulia | :) | 21:23 |
| TheJulia | so, you were reading and then what happened?!? | 21:23 |
| cardoe | One of the other dads walked by with a GitHub hoodie. It had his username down the back of the sleeve and something else. | 21:24 |
| * TheJulia assumes there is background story somewhere here | 21:24 | |
| cardoe | His son is new and so we don't really know him. | 21:24 |
| gouthamr | fellow dad came and said "you look weird out here with your technology in the woods, you must work on OpenStack" | 21:24 |
| cardoe | And another dad sitting near by who also is a dev made a comment to me like "look whose trying to swing some nerd gang signs" or something cheesy | 21:25 |
| cardoe | And engaged him | 21:25 |
| cardoe | And I was keeping to myself when it was "yeah Doug's the open source guy" | 21:26 |
| gouthamr | its a good world when the github hoodie dad wasn't called that :D | 21:27 |
| cardoe | So the town I live in has a lot of engineer-y types per capita | 21:27 |
| cardoe | And we have a lot of gov't stuff. | 21:27 |
| gouthamr | sorry, flame war | 21:27 |
| cardoe | I know the govvies love to talk software supply chain risk management | 21:27 |
| cardoe | and open source is the either poster child or the bad kid on the street from that stand point depending on which side of the turf war you live on. | 21:28 |
| cardoe | There's team "zomg they let any old rando commit something and it could have evil backdoors that wake up years later" | 21:28 |
| cardoe | And there's team "open source is fully auditable and visible" | 21:29 |
| cardoe | Obviously I'm on the pro open source side here. | 21:29 |
| cardoe | I was just trying to read my book. I hadn't read The Three-Body Problem yet. | 21:30 |
| gouthamr | :D enigmas of our convictions | 21:31 |
| clarkb | two of my neighbors work IT/tech for credit unions | 21:32 |
| clarkb | I think that world is even more removed from open source than the government | 21:32 |
| cardoe | GitHub dad was showing what he worked or to now a group of dads cause somehow Boy Scouts has a bunch of software dads in it in my area now. And since open source is a turf war thing and I had said I currently am pretty heavily involved in OpenStack for "what open source stuff to you work on" | 21:32 |
| cardoe | He searched up OpenStack in their security thingy | 21:33 |
| TheJulia | clarkb: my wife used to work for a bank, apparently they had an actual rule about no minor versions being 0 as ever being permitted to being deployed in production. | 21:33 |
| TheJulia | cardoe: let me guess, their tool based upon pypi and tags to determine if a fix had actually been "released" ? | 21:33 |
| cardoe | This is when another dad who is team open source is scary evil chimed in saying that he does security audit stuff for NASA and they're constantly having to get security exception stuff for OpenStack. | 21:34 |
| cardoe | I just wanted to read my book. | 21:34 |
| TheJulia | oh my | 21:34 |
| cardoe | But I did want to at least share the experience/perception with other folks involved in OpenStack. | 21:34 |
| TheJulia | unrelated question, was the book good? | 21:35 |
| cardoe | TheJulia: yeah a bit confusing at first but it's really solid. Different take on things. | 21:35 |
| cardoe | TheJulia: So I've done a little bit of digging. And I've even asked our internal security folks. | 21:36 |
| cardoe | So NIST advisories for OpenStack actually scrape git tags from our repos. | 21:36 |
| TheJulia | oh, heh | 21:36 |
| TheJulia | that would do it then | 21:37 |
| cardoe | So the govvie got me some further info. | 21:37 |
| clarkb | one of them works for the credit union I use which in mid june removed my ability to transfer money directly to family member accounts at the same institution due to a new restriction on only allowing transfers between accounts you own. So guess who got a new joint account recently... Anyway apparently every other country has figured out money transfers but ours or something | 21:37 |
| cardoe | The Mitre CVE is created from our OSSA | 21:38 |
| cardoe | NVD (National Vulnerability Database) has augmented the record | 21:38 |
| cardoe | https://nvd.nist.gov/vuln/detail/cve-2026-46447 | 21:38 |
| cardoe | All I asked the dads at the camp out was to give me an example and he asked me which area and I told him ironic | 21:39 |
| cardoe | https://security.openstack.org/ossa/OSSA-2026-017.html is what he picked | 21:39 |
| cardoe | Which is what that CVE is | 21:39 |
| clarkb | cardoe: and I guess the underlying issue is NASA patches by pulling the code down and rebuilding container images or whatever, but because the version on the tin isn't bumped to match the advisory the audit toolfails | 21:40 |
| cardoe | clarkb: Yeah that's my guess. | 21:40 |
| cardoe | I'm not saying there's a magical fix here. | 21:41 |
| TheJulia | I talked to what's his name... last year, and I think that is exactly what he said they were doing | 21:41 |
| cardoe | yeah I cannot remember his name either. He works at Wallops. | 21:41 |
| TheJulia | yeah | 21:41 |
| cardoe | One of the dads I talked to worked for a local contractor that does the security auditing of Wallops systems. | 21:42 |
| cardoe | Anyway the take away I had was "huh I bet if we had a tag that would make this go away" | 21:42 |
| cardoe | And then GitHub apparently uses PyPi as a source | 21:42 |
| cardoe | https://github.com/advisories/GHSA-jrh2-f5jc-xpgr | 21:43 |
| cardoe | I've already submitted a few PRs to GitHub's DB to correct some things about OpenStack which are incorrect. | 21:43 |
| cardoe | I saw fungi post https://review.opendev.org/c/openstack/governance/+/1002692 | 21:44 |
| cardoe | whose title is "Propose SECURITY.rst goal" | 21:44 |
| cardoe | So I just figured I'd mention this convo. | 21:44 |
| cardoe | clarkb: I don't know why money transfers are so damn hard here either. It's annoying. | 21:45 |
| clarkb | quick someone say SBOM (in theory this is the proper solution to this problem?) | 21:45 |
| cardoe | I've heard that way too many times. | 21:45 |
| clarkb | rather than auditing a derivative value like a version number audit the actual contents of the thing | 21:45 |
| cardoe | Anyway... with the release of keystoneauth and openstacksdk recently it's shown me how manual the release process really is. | 21:46 |
| cardoe | How much human involvement is needed. | 21:46 |
| cardoe | And to TheJulia's point I just thought hmmm maybe the intersection here is to automate this away. | 21:46 |
| TheJulia | to be fair, this is not the first thing today I've responded to with "that relies upon humans doing a thing" and suggested automating or removing the expectation of the overloaded human remembering to do the thing. :) | 21:48 |
| clarkb | as a counter point releases may be one of the most important things to keep humans in the loop on? | 21:49 |
| clarkb | the ability to easily ship releases has created many supply chain issues in recent months | 21:49 |
| TheJulia | except, then we must ensure we ship regardless to not forget | 21:52 |
| clarkb | right, it comes down to priorities and where we think the value for our time chips is most efficiently spent | 21:53 |
| TheJulia | An argument can be made to only do this on stable branches, and following the backporting rules should always ideally be spotted or identified as a delta | 21:53 |
| TheJulia | so reviewers are still key, they are still engaged, its more so "post-review/post-merge" | 21:54 |
| TheJulia | yup | 21:54 |
| cardoe | My suggestion is only for the stable branches | 21:56 |
| cardoe | When the patch successfully lands on a stable branch, we auto create the release for it. | 21:56 |
| cardoe | And the patch has to be flagged with a commit header as such. | 21:56 |
| clarkb | right but anyone can add a commit header | 21:57 |
| cardoe | The person that +W'd it needs to check for that. | 21:57 |
| TheJulia | but not anyone can just workflow | 21:57 |
| clarkb | so if reviewers don't catch that | 21:57 |
| cardoe | Unless we can have another gerrit clickable for only -core folks. | 21:57 |
| clarkb | yup its a new thing reviewers would need to both be aware of and know to cheeck on every commit merged to stable branches | 21:57 |
| clarkb | so we're shifting the "make a release patch" as an explicit step to "make sure that the commit header doesn't accidentally make a broken release or worse" step | 21:58 |
| TheJulia | It could also make sense for reviewers to manage | 21:58 |
| TheJulia | for example "If I know I've got 3 patches about to land, I only want the last patch to do the needful, then I have the commit message tags set appropriately" | 21:58 |
| cardoe | Exactly why we need some kind of control. | 21:59 |
| TheJulia | that makes a lot of sense to me then | 21:59 |
| cardoe | I'm happy to draft a change. | 22:00 |
| cardoe | clarkb: if you've got a suggestion for a trigger mechanism that's not a commit header that'd be cool. | 22:00 |
| cardoe | or if the answer is a commit header... any suggestions? | 22:01 |
| clarkb | I don't have any great ideas. In opendev we write changes that go to production, but that is always a property of the commit itself and not the commit message | 22:01 |
| clarkb | updating a container image for example | 22:01 |
| clarkb | its possible that something like that would be more eye catching to reviewers. But then you're "polluting" what would otherwise be a clean backport patch | 22:03 |
| cardoe | Well I was thinking the header could land in master and just no-op. | 22:04 |
| cardoe | But that could de-sensitize people. | 22:04 |
| TheJulia | Well, truthfully, If I'm doing it, and the code only looks at stable, then I'd just stack it all up upfront and let it automatically do it's thing upon merger | 22:04 |
| clarkb | ya that is the upside to the commit message it probably keeps your commits cleaner for that reason | 22:04 |
| TheJulia | in the stable branches | 22:04 |
| cardoe | So maybe the header "Stable-Release: patch"? | 22:05 |
| cardoe | or "Stable-Release: yes"? | 22:05 |
| cardoe | "Stable-Release: get-to-the-chopper" | 22:05 |
| TheJulia | heh | 22:05 |
| gouthamr | https://review.opendev.org/c/openstack/releases/+/1003379 only took about a minute to verify fixes and write up.. we could just run a cron against OSSNs and OSSAs to do this externally | 22:05 |
| cardoe | It's after 5pm and I'm talking security and releases... I'm justified in being a little squirrelly | 22:05 |
| clarkb | gouthamr: that would also handle the batching | 22:05 |
| clarkb | gouthamr: once a day we gather up all the outstanding things and batch them? | 22:05 |
| gouthamr | yeah | 22:06 |
| gouthamr | rather than rely on a human to put the commit message annotation in the right place :) | 22:06 |
| clarkb | and that patterns fits with translations and requirements updatse and so on | 22:10 |
| fungi | cardoe: another problem we've been having is that getting cve ids assigned in a timely manner is hit-and-miss, there have been a lot of discussions among the vmt and adjacent on options there, but just to say you can't assume there will even necessarily be a cve id initially associated with our advisories | 22:26 |
| fungi | maybe somebody else has said that, i'm only halfway caught up on dinner scrollback | 22:26 |
| fungi | clarkb: an sbom really only helps if the software in question is being embedded in something else that's distributed (e.g. what software versions are in this container image, what library versions this binary artifact was built from, et cetera) | 22:28 |
| fungi | if you're in an ecosystem that focuses a lot on releasing binary artifacts or vendoring/embedding some software inside other software, an sbom is pretty handy | 22:29 |
| clarkb | right I'm somewhat assuming that the audit system is flagging and artifact like that | 22:29 |
| fungi | for a project that releases source code, it's less useful upstream, but downstream may want to add an sbom to describe what they did with your software | 22:29 |
| fungi | if we're back to stable release auto-proposals, i think it would be fine to have a job that runs in post to refresh an open release request for that deliverable each time another patch lands to any stable branch, then rely on a ptl or release liaison to come by and +1 indicating "yes we want to release our branches in the described state now" | 22:32 |
| fungi | cardoe: clarkb: to the point about "fixed versions" and distributions, debian just announced their fixed packages for CVE-2026-80182, CVE-2026-80183, and CVE-2026-80184 which are bundled in a keystone package with a version number of 2:27.0.0-3+deb13u5 whereas 27.0.3 is the upstream version for those fixes | 22:48 |
| fungi | so any security scanner on debian stable is going to see keystone 27.0.0 even though the vulnerabilities are patched | 22:49 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!