Meeting started at 2026-07-23 14:59:22 UTC

The Meeting name is 'Fedora Meeting 3'

The Meeting Name is now security-sig

!hi

Daniel Milnes: Daniel Milnes (thebeanogamer) - he / him / his

!hi

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

!hi

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

!hi

Michel Lind ☘ UTC+1: Michel Lind (salimma) - he / him / his

Anything critical that anyone needs to mention at the top before we jump into the first topic?

I'm here, but on unreliable Internet. So I might disappear :D

hi

!hi

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

!hi

jforbes: Justin Forbes (jforbes) - he / him / his

You'll need to set your matrix name on https://accounts.fedoraproject.org/user/rzhukov/settings/profile/

alright, nothing pressing it seems... first topic then.

!Topic #14 Review Fedora security documents to align with “Vulnerability and Incident Policy” CRA requirement https://forge.fedoraproject.org/security/tickets/issues/14

I think topic needs to be lower case (?)

!hi

rzhukov: Roman Zhukov (rzhukov)

So on this one I'd really like a steer from rzhukov. We _can_ try and plow through everything mentioned on that ticket, but some idea of priority would be nice

Sec, typing

This ticket ^^ started with simple Review existing docs against the Stewardship guidelines (see this first line item https://access.redhat.com/security/eu-cyber-resilience-act-stewardship-guidelines#:~:text=Cybersecurity%2C%20Vulnerability%20Management%20and%20Incident%20Response%20Policy)

But I like how discussion involved into actually making a table

with the entire lists of guidelines and doing gap analysysy

So, I'd suggest step-by-step:

1) For this ticket - do the docs gap analysys. I saw someone mentioned that infra, docs, other teams may be involved. So, would be looking for volunteer who can go ahead and investigate :)

2. Create an artifact (e.g. .md) in one of the repos with the full table of Guidelines. If someone can point me out to the repo - I can make an initial MR

wdyt?

Do you mean create a document so we can collaborate on each point, or create a doc in the docs site that'll link to what we do on each point

for #1 - I mean take the 6 items: 1) Secure development practices 2) Contact information for security questions, vulnerabilities and incidents reporting 3) Contact information of the project’s Steward (cra-steward@redhat.com) 4) The processes for vulnerability reporting, identification, remediation, patching, and coordinated disclosure (CVD). 5) The process for handling incidents for underlying infrastructure and tooling used 6) Intended support period for addressing vulnerabilities and the end-of-life process.

and map them to existing Fedora docs. Where does not exist - suggest which doc will be the best to amend

For #2 - let start with the targeted repo where I can push an .md file with what I think would be a good tracking table so that we go over, do gap analysys and create issues for missing items

`map them to existing Fedora docs` I think some of those will just need to be created entlrey. If anything exists, it's probably going to be very outdated (on an old wiki or something no one bothers with anymore).

stale info has been a problem for years, and there's no easy fix since things are scattered around a half a dozen locations.

RH is the CRA steward by default because there is no standalone Fedora legal entity, I assume?

What might be better long term... is to just decide as a team where we want the current info to reside... and focus on creating/improving what exists and create a single source of truth for 'current' cocs.

ah, ok. then in this ticket (https://forge.fedoraproject.org/security/tickets/issues/14) we can propose what we think is the good approach for each of those 6 items

or would it make sense to have a fedoraproject.org alias, even though right now it just forwards to the RH address?

I think there is a council ticket about this. It is not obligated but encouraged.

RH is the Steward for Fedora by current (veg) definition in the CRA and our understanding.

Seems like a reasonable starting point

If someone can lead the charter, I'm of course happy to contribute/help/etc.

https://forge.fedoraproject.org/council/tickets/issues/559

"veg" ?

Yes, because there are many interpretations who can, can not be and must be Steward and for what. Even within EU Comm there are different opinions. But I personally think it doesn't prevent us from doing reasonable things/improvements

Moving on, I'll be willing to accept more support and contributions from other companies. We in fact discussed that already already at Flock with AWS and MS

ah, sorry , I meant I am not sure what 'veg' means

So far, we consider Red Hat as a "leading" Steward anyway :) Until somebody tells us the opposite...

Ah, sure. Sorry. Veg = nobody really understands what it means xD

veg = vague?

pretty much

I'm not sure if I like that we forward people in docs to RH without making clear for what. It remains very implicit. (Concerning the above comment to add "contact details of the steward").

Right but in reality, Fedora and Red Hat are so tightly intertwined that this isn't the place to start with unpicking that

Yeah, good point too

1 sec. Here is our security.md template and what we suggest to include into the docs:

yeah, that's why I was wondering if future-proofing by making that a new Fedora email would help. it does not matter right now, it might matter in the future

Where's your spirit of adventure? 🤣

https://github.com/RedHatProductSecurity/CRA/blob/main/Templates/Security_MD_template.md

So, this disclaimer is good enough to add:

This project is stewarded by Red Hat, Inc., an open source software steward as defined in Article 3(14) of the EU Cyber Resilience Act (Regulation 2024/2847). Contact: cra-steward@redhat.com

Refer to Red Hat's security practices and vulnerability management policy for detailed information.

EU Cyber Resilience Act — Open Source Steward Statement

This project is stewarded by Red Hat, Inc., an open source software steward as defined in Article 3(14) of the EU Cyber Resilience Act (Regulation 2024/2847). Contact: cra-steward@redhat.com

EU Cyber Resilience Act — Open Source Steward Statement

+1 to that. I think getting one as forwarding shouldn't be hard

So, it's to notify others (just in case) to direct all "legalish" questions to Red Hat, not to community. While we should keep actual "real" security docs and processes in Fedora.

so ... into *which* docs?

This seems like a good starting point. The exact destination for those reports feels like it leads into the second topic for this meeting (where do reports from the linux-distros list go)

Security, surely?

I mean until we get a Fedora Legal SIG :)

that question just keeps coming around doesn't it?

so ... forge/security/docs ? :)

I mean, I agree, just Security docs

That's where I'd put it

I would say for the mean time... we just start using https://forge.fedoraproject.org/security/docs If we come up with a better idea in the future we can move them later.

no point holding up writing things due to going round and round about where to save them.

https://forge.stg.fedoraproject.org/Rainbows-and-Unicorns/issue_creation_test/src/branch/main/security.md

There will be in the end two docs. One about the team in the team docs, one about security topics. The latter might get its own badge on the main page. I like the idea Daniel Milnes added earlier about how to distinguish them, as that might be realistic to keep on the long term and still not destroying SEO.

Though not sure if that is already relevant at this stage (?)

security.md example from thrcka

Strong plus one

yeah, we can move things later, let's just not make perfect be the enemy of good

'where to put things' is really hard to figure out *until* things are writtten anyway, because right now we have only vague ideas

So the only thing we really need to answer then is "Where do the reports go"

To which I'm tempted to say "Bugzilla email, similar to the linux-distros one"

Docs-authoring teams once managed to get Fedora out of every search engine first page even for most search queries involving the term Fedora Linux. At the same time, pages were undiscovereable even by the docs team when asked despite them being embedded in the community. My point is not that it is wrong what we do now, but just "hey writing and publishing is always good" is not always the case. It's more complex than that ;)

private mailing list should be an OK temporary solution, until we have private tickets in forgejo.

trying to look at it as a lay person... it would seem people would think they would create them under 'tickets' based on the wording of the two repos.

though somebody will need to deal with spam moderation on that list.

I missed RHCL yesterday due to a scheduling snafu, I wonder if they did talk about bugzilla or not.

I wanted to flag that hey the Security SIG is now using it in lieu of any better place for embargoed discussions

shouldn't have - bugzilla topic is scheduled for later.

100%

ah ok, so it was really open discussions, I thought initially that was next week

I think this is the same as the linux-distros reports though in that we need somewhere private and Forgejo can't do that toda

yes, but that doesn't support private tickets (for security reports) yet.

I think this is the same as the linux-distros reports though in that we need somewhere private and Forgejo can't do that today

So yeah Bugzilla or mailing list, and personally I'm a sucker for a good ticketing platform

Does forge allow templates? We could make the first line of filing a ticket be a warning about no private tickets.

Does forge allow issue templates? We could make the first line of filing a ticket be a warning about no private tickets.

Indeed it does

yup

Question: do you wanna go with reviewing/amending existing Fedora docs (listed https://forge.fedoraproject.org/security/tickets/issues/14) having 6 guidelines items in mind OR do you want to start something from scratch from those 6 guideline items (e.g. 1) Unified Vulnerability and Incident Policy; 2) Secure Dev Practices; .....)?

Don't think Forgejo supports sub-tasks, so I'd be tempted to say ticket per item

So they can be worked on seperately

But maybe I've spent too long on Jira

I'm pretty sure they'll all be "we need to write this from scratch" anyway so yeah

Even if we do plan to direct people to bugzilla, we should still put something in place in the tickets docs for people that end up doing a drive-by because they didn't see where they should go.

I think you can also have an issue template that's actually a link, so that can funnel people to the right page

(I have "voice/video" meetings all day, but this text one is something stand out - I need a break after it indeed 🤣)

yeah ...

so what I'm kind of missing is what are the actual action items now?

but we dont want to direct ALL tickets to a link. haha

The sacrifice for transparency and discoverability, but yes, I know what you mean :)

but we dont want to direct ALL tickets to a link. haha so we'll probably need a few templates

I generally find text meetings easier to deal with, but yeah, I wonder if some of these questions could probably be dealt better async

* Create a Forgejo ticket for each of the 6 items

* Close #14 as complete

In my eyes:

* Draft PR for the docs site with that SECURITY.md

* Create a new list/bugzilla component for security vulnerability reports

in tickets, that is

yeah that sounds very sensible

need to pandoc -i SECURITY.md -o SECURITY.adoc .... because ✨️ antora ✨️

I was going to do it by hand, that's way too sensible

(text meeting are tolls for non-native English speaker, but anyway...)

I mean you do you but I can for the life of me not commit asciidoc syntax to my head

oh yeah. it's sometimes difficult for me as a German native speaker too ...

Intellij has a lint rule for "You've written markdown syntax in an asciidoc file" and I rely on it heavily

Let me see if I get it. You want to create 1 Security.md file to include all 6 items into it OR create 6 (or maybe less) news doc incorporating those items OR both of those actions?

that probably depends on how much content there will be for each of those points? if it's just one sentence, then separate documents doesn't make much sense to me IMO

fair, funnily most of us are likely non native speakers here? I know I'm not. On FESCo it's probably majority non native speakers too

although its easier to translate text afterwords rather than a video recording

right, "AI transcriptions" are also not friendly to non-native speakers

but anyway... let's not derail before I go into a spiel about how horrible it is to see a lot of blurry faces in a meeting room across VC and not knowing who any of the speakers are

(I'd agree, but my transcript parser using locally hosted model does a pretty good job actually for most of the time from the audio stream. Not to mention if you enable native captions recording in the video call itself)

that's the main point. I'd suggest the docs are not "formal" docs, but actually helpful. That's why I'm suggesting these different options - we may reuse existing docs, but if there is no "appetite" to go with full review, perhaps a few sentences into 1 single .md file would be perfect. We would need short and concise security.md files anyway to push to repos

Have you got any other projects which have adopted that template, so we can get a feel for what should go in the placeholders?

security.md = minimal info how to report, contacts, etc. Actual docs = elaboration on the full process, practices, etc.

Sure, sec

Actually, have a look at the table https://access.redhat.com/security/eu-cyber-resilience-act-stewardship-guidelines#:~:text=Cybersecurity%2C%20Vulnerability%20Management%20and%20Incident%20Response%20Policy

there are links in the third column to those examples.

or would this need to go into *every* dist-git repo too?

so which repos would we be talking about here?

> We would need short and concise security.md files anyway to push to repos

stuff hosted on forge.fedoraproject.org?

But if you're asking for "Red Hatty" one - here it is: https://github.com/stackrox/stackrox?tab=security-ov-file

Ah cool, based on https://github.com/uxlfoundation/oneDNN?tab=security-ov-file I think we could get the simple version into one doc and link out to bigger ones as requeed

I think you could put this on the docs site, in the same way we don't have a LICENSE.md in every repo

I don't think it'd go to every repo, to be honest. If we can identify "the core" it'd be great.

The main point in short security.md files is discoverability. People (and now agents) kind of expected to find these artifacts to report about vuln

I've had a backlog item to put a security.txt on the public sites

So that could point at the docs with the security.md

Maybe also a link directly to it on the main site

anyway I have another meeting in 5 minutes, gotta go

(not that I have a huge vote here 🤣) I agree with all actions, but the first one. May I suggest to not close this ticket yet, but instead propose/write how these new/rewritten policy docs may look like? Or create a new ticket for this work item :)

Sure, let's use the current one to document a plan

The current ticket is probably the best place to continue to discuss it.

I dont think we'll resolve everything in the next 3 minutes. haha

Yeah maybe let's leave it there rather than trying to cram in the other topic

And we can fan the actions out on Forge

And for other items (beyond policy) - we can create another ticket or repo with a table/gap anal

Sounds reasonable

yea we'll bump Linux-distros discussion | https://forge.fedoraproject.org/security/tickets/issues/13 to the top of the next meeting, if there's time next week we can return to this topic to discuss ideas over this past week.

sounds great, thanks folks, have a good one!

thanks all!

Do we need that? I left it because I wasn't sure if people want to discuss it, given the attention it got.

Have a great rest of your week and relaxing weekend.

But it doesn't hurt, so either way fine I guess

we can at least see if there's further comment, if not, we can move on.

Yeah makes sense

See you around, thanks everybody :)