Meeting started at 2026-07-30 15:00:21 UTC

The Meeting name is 'Fedora Meeting 3'

The Meeting Name is now security-sig

!hi

Chris (py0xc3): Christopher Klooz (py0xc3) - he / him / his

!hi

If anyone has an urgent point or announcement that should precede the agenda topics, feel free to let us know. Otherwise I would wait a moment for everyone to arrive and then start.

!hi

Due to participants' schedules, we shift the 2.1. CNA issue to the first place of the agenda

!hi

!hi

No Fedora Accounts users have the @mfindra:matrix.org Matrix Account defined

!hi

Fabio Valentini 🌈: Fabio Valentini (decathorpe) - he / him / his

Lukas Javorsky: Lukas Javorsky (ljavorsk) - he / him / his

!hi

Michal Findrawant to register your matrix account in accounts.fedoraproject.org ?

(Zodbot did I do something to offend you?)

poor zodbot has been having a bad time this week

sure

I thought I did it already

So yeah, didn't know this was a thing

Would be nice to document what we currently have

iirc if it's not a Fedora.im account you need to use that funny Matrix syntax

just to clarify - did *anybody* on the Fedora side of the firewall know about this?

@ user : domain

not me

IIRC Neal said he knows

but he thought it was only meant for internal fedora infra stuff

doesn't count 😆

Which would make sense, but the links on the CVE site just go to all the security bugs in Bohdi

yeah looks like there's definitely some things that don't line up

Fedora as a CNA is limited in what it can do

Looks like there are some CVEs reported under Fedora CNA, e.g.: https://www.cve.org/CVERecord?id=CVE-2025-10256

Don't suppose someone Red Hat-ey can see who filed that one?

I reserved 2 CVEs today using Fedora pool

Essentially it is meant to apply to places where Fedora is the upstream or has diverged from upstream in a meaninful way to where the CVE would only apply to Fedora and its downstreams

I can see who did that

one sec

!hi

├─ Reserved by: trathi@redhat.com (fedora)

├─ Reserved on: Thu Sep 11 06:11:12 2025 +0000

CVE-2025-10256

└─ Updated on: Wed Feb 18 20:26:46 2026 +0000

├─ State: PUBLISHED

├─ Owning CNA: fedora

I'm wondering whether saying that this CNA is "Fedora" actually violates trademark rules if it's not been signed off by Council?

Conan Kudo 😌: Neal Gompa (ngompa) - he / him / his

Yeah so probably Red Hat Prodsec team is using this pool only

AFAIK it's based on our LANANA name, so it should be fine

council sign off on trademark seems very vibe-y

that was previously authorized by the Fedora Board

Yeah so probably only Red Hat Prodsec team is using this pool

What's the division on that vs using Red Hat's own CNA?

but we probably should figure out how fedora itself can manage its CNA

I would say CVEs that don't affect Red Hat products, but do affect Fedora

correct

that's probably not a workable distinction

not without qualifiers about the currency of effect

e.g. ipsilon was in RHEL and now isn't, but still is in older RHEL

so now what?

shipped in rhel - rhel pool

not rhel red hat

ok what if it's shipped in fedora and rhel

not rhel - red hat pool

say the old version in rhel is affected and the new version in fedora is also affected

Then RHEL pool

if both - red hat pool

makes the upstream/downstream distinction a bit flipped on its head but sure, I can live with that

/s/RHEL/Red Hat

though it probably should be documented

if not shipped in any -> CNA LR (Last resort )

My ideal end state for this discussion is a short page in the security docs that says: we have this, these people (ideally a FAS group) can use it, these are the times when it should be used, and how to issue one. If the last point is just a link to the Red hat careers site for now then fine

But as Neal says, ideall Fedora runs this

But as Neal says, ideally Fedora runs this

sounds like this wood be a good candidate of a page to add to the security docs!

especially as we start actively participating in embargoed discussions and things of that nature, we as fedora produce plenty of things as the "true upstream" and it makes sense to figure out how to manage it as the CNA for that purpose

But since Red Hat does full VM for Fedora, how do they (someone from Fedora community) knows what security bugs should reserve a CVE in Fedora pool?

like, it would be silly if Red Hat was the CNA for a vulnerability in rpm macros that Red Hat doesn't participate in at all except for shipping it

also the rule still is that we only reserve CVEs for components that are not under other CNA

especially if the upstream is a Fedora developer that doesn't work for Red Hat

yeah, I think those closer to where the software is developed should own it

eg. kernel - we never reserve CVEs for kernel

and until we adopt PURL the security vulnerability assignment in Fedora is a bit of a crapshoot anyway

how does PURL help us?

we should probably document a few things right? a) what we have - b) how we think we can use it today, c) the ideal end state and how to get there

yeah

Conan Kudo 😌it stops bugs being assigned against the wrong component by substring search

Yes, documentation is the biggest issue I see at the moment.

that's where it should start imho

ah right that

Yeah it's not documented at all so to speak :D

then we can see what to make of it and how to develop and align things. But first we need something clear that can be aligned :)

Not sure that can be resolved within a meeting before (?)

In the hopes of moving towards an action item, Lukas Javorsky Michal Findra would one of you be willing to write the page for https://forge.fedoraproject.org/security/docs/ documenting how it works today, then we can figure out what tomorrow looks like

Michal Findra: has more hands-on experience on this so I would leave it to him if that's okay Michal. Either way we'll have a sync on it so if there is something I can help with I'm willing

If there is anything we can help with concerning Docs or so, feel free to let us know

More about this topic?

Chris (py0xc3): you have some specific module(space) you want the doc to be drafted?

Or should a new dir be created in https://forge.fedoraproject.org/security/docs/src/branch/main/modules/ROOT/pages

you can still use the default module, ROOT. for the team docs and stuff like that, this will not change.

modules/ROOT/pages/CNA.adoc or something like that should be fine

exactly

We can then see how to put it best to the nav.adoc. I don't have the current sub categories in mind off the cuff tbh :)

([FESCo docs](https://forge.fedoraproject.org/fesco/docs/src/branch/main/fesco/modules/ROOT/pages) are also just a flat directory structure like this, the actual docs structure is in `nav.adoc`)

I think to have seen there is a sub category for cryptography. But not sure off the cuff

Anyway, in case of a doubt, we can just leave it at the main category without a sub or so

We don't have that much anyway :)

We'll need to leave shortly, is there anything else CNA related you wanted to ask?

I think that covers things for now :)

Shall I move on with topics?

THOU SHALL

I think there is not much new on the Linux-distros discussion. One might add that @jforbes mentioned that co-maintainers for the kernel are ramping up, which is great news with (positive) security implications on the long term. When the linux-distros discussion is more advanced and the roles/expectations better defined, we might ask if they should be considered for the second member at the mailing list (if we get two). But I think that's nothing to discuss at this stage. Anyone else anything to add to this topic?

I've been a bit busy, what's the blocker on getting this working right now?

I would say not at this point

like, what are we waiting for before asking for this in oss-sec

I would like to avoid hardcoding anything into policy that relies on bugzilla, with its sunset date being on the horizon (EOY plusminus a few months?)

Well, the process is one thing. I suggested something that can be "questioned". Not sure that is ready for approval.

I don't think bugzilla is a requirement, any replacement should (according to the flock discussion) support private tickets

We can probably keep the implantation , but we do need somewhere private

We can probably keep the implantation vague, but we do need somewhere private

Yes, indeed. Not sure I considered that yet. One thing to review+change if applicable

jforbesI think we should plan for the worst case scenario though

If that draft is useful at all to eveerybody

bugzilla should be fine until forge.fp.o supports private tickets, hopefully the latter happens before the former is shut fown.

bugzilla should be fine until forge.fp.o supports private tickets, hopefully the latter happens before the former is shut down.

e.g. pagure.io usage of private tickets... is now gone on forge.fp.o even though private tickets are not supported yet

so yeah, hopefully the next sunset works better but we should not assume it will

I'm not particularly confident on a timeline for forge.fp.o supporting private tickets

so we should think about alternatives to that

me either, hence my "hopefully"

though I have seen progress on those feature branches recently.

I also don't like to have this outside of Fedora, but the possibility with freedesktop.org remains. We depend on them indirectly anyway. It might be also considered as worst case back up, if we want to have one.

I’m not convinced that’s really an option with the confidentiality requirement

So if we want to have a worst case alternative in place if both alternatives break away, though I'm not convinced of that

annoying as it is, the one time I needed to coordinate embargoed stuff with people who don't want to use encrypted email or Matrix we ended up on ... Signal

Signal isn't so annoying

Well, having encrypted matrix or signal channels is not so bad

at least secure. But vulnerable to too much traffic.

Not really equivilent to a proper ticket though

Yes indeed

These meetings are chaotic enough

Not a sole solution on itself

I don't want us to go round in circles too much

So maybe we write this as if we have a private ticket platform

And we revisit if that looks like it's going away

that would be fine with me

yes, +1. So writing it platform neutral.

So then we've two tasks, writing the policy and creating the Bugzilla plumbing. We'll need a volunteer for the former (don't mind if it's me), the latter will need Alasdair's help

yes, +1

Ok, so, going ahead with the draft of mine? I already implemented the name of Conan Kudo 😌 , and have to review to ensure its neutral for the ticket platform.

I'm happy if someone else wants to start with something else. Just wanted to get the discussion about contents started.

Maybe PR what you've got so far against the docs site and we can review there

As it needs to end up there anyway

we also still have gitlab.com/fedora FYI

Yes, can do that. Need to improve text from the current bullet-point-only style anyway.

we can still use that for private tickets in a pinch

that's better than freedesktop, yeah

Something something xkcd 927

at least until fedora/redhat stops renewing the OSS gitlab arrangement

Good point, I think I'm still developer there ^^ But not sure if I consider gitlab more private than freedesktop?

GitLab's privacy is bound by contract

gitlab.com/fedora leakage is redhat's fault :)

Partially, its a US company, which leads to restrictions.

per the arrangement with them and gitlab

Not necessarily a game breaker of course, but still just another compromise

gitlab bv is dutch FYI

The mother is not a US?

no

the parent company is Dutch

Ukrainian guy moved to Netherlands and founded the company to commercialize a side project

that's how GitLab started

Interesting. Anyway, don't see this too critical in this particular case.

Ok so we have an action item there to make the PR

So I'm fine anyway

I would draft for now neutrally, and just add a specific place to fill in gitlab, bugzilla, forge, or whatever, and keep this part easy-to-update

if that is ok?

👍️

Ok, anything else on the topic?

In terms of Bugzilla, does the proposed architecture of a `Fedora Security` component with a dedicated service `Embargoed Bugs` make sense?

And would we want to sign that service up to the list directly or rely on list members raising bugs?

the former

so that would make sense, yeah, and once the embargo is lifted we can either reassign the bug to the real component or open a new one I guess?

+1, the other might cause bottlenecks

I guess open a new linked bug is better

yup

I think that's a case-by-case issue

reassign is typical, no need to hide once embargo is lifted

e.g. when I handled a PackageKit CVE, I made a new bug because the original contained a PoC exploit that we didn't want to disclose

Oh, those should be private comments either way

if no sensitive data after the fact exists, no reason to not just reassign and make public

we can't make private comments currently, so it's not a feature I can rely on

Yeah for Samba I know they do a mixture depending on what was written on the ticket

only Red Hatters can do that

yeah, we have the option to do both anyway but probably safer to always just open a new linked bug

Oh :(

yeah, if it was a thing I could do, I would

But yeah, PoC should never be made public unless they are already public

it drastically simplifies things

Which, these days...

responsible teams don't do terrible things like zero-day the world

but some fools do, and then we're kind of stuck with it

again, case-by-case handling

In terms of access to that new Bugzilla, I'd suggest we stick it behind a new FAS group whose members are the people on the list on our behalf

"Security Bug Handlers" or something like that

sec-bugzappers :)

Yes, that might make sense. To not be bound to security sig members = private access

I'm a fan of the classics :)

See that's much snappier

I was trying to come up with a name but Neal nailed it

(classics?)

I missed the reference too tbh

our original bug triage team was called BugZappers

Ok so two more items there. One to create the FAS group and one to create the Bugzilla

https://fedoraproject.org/wiki/BugZappers

ah. so in the time before my Epoch 0 😆

On Bugzilla, https://forge.fedoraproject.org/security/tickets/issues/17 might go in there as well, but given nirik and friends are the ones responding to those alerts we should go wherever they want it

most of their functions were absorbed into Fedora QA

so the team withered away

Can you do that one Daniel?

I can certainly ask Infra to do it

Cool :)

Cool, I think that's it in terms of stuff we needed to discuss

Unless anyone feels like weighing in on https://forge.fedoraproject.org/security/tickets/issues/18 ?

Yeah, more points about it from someone?

not yet

Ok, final topic

That's a simple thing: does everyone agree if I give Security SIG members the privilege to create/add/migrate repos in forge? So far only owners can do that. Members can already do PR and such. PR on linked/published repos is more invasive than creating new unlinked repos anyway, but I didn't want to make something that is formally invasive on my own without asking :)

how about something related - a badge for fixing security bugs?

+1 to allow members to create repos.

Ah, didn't see another topic was raised.

I think there's already one for security-linked Bodhis

I don't know that I see a need to create repos

Also +1 on this

Most likely it will be for docs repos

need - maybe not, but I do think it's weird that there's second-class group members :)

That's where the issue just came up,

https://badges.fedoraproject.org/badge/white-hat

we can try reenabling and see if it gets abused (hopeefully not)

It doesn't really add risks, given that we are already careful with memberships, and they can already do PR

because in a pinch it might be annoying if you really need to make a repo and nobody is around

Ok, then I enable it.

That's it

... which I assume is badging related :)

I'll drop at :00 - or melt into a puddle, whichever happens first

we could probably make white hat tiered

but eh

yeah I need to go and charge my car

Daniel Milnes: shall I put #18 to the agenda for next week?

and then I need to badge back into the office, yes

Couldn't hurt

Ok. I'll do

Since some are leaving or have already left, I assume we can end the meeting?

I think so... thanks for chairing

ok, thanks for being here evreyone :)

decathorpe gave a cookie to py0xc3. They now have 6 cookies, 3 of which were obtained in the Fedora 44 release cycle