Meeting started at 2026-07-09 15:04:04 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

!hi

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

!hi

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

Well, let's wait a minute or two for everyone to arrive (some more said they wanted to join) and then start with the linux-distros topic?

works for me

Hi folks, I'll be monitoring chat, but ping me if you're waiting any reaction from me :)

do you want to already call the topic?

I don't think the forge actually allows private tickets just yet, though it is in the works

To get it started -> 4 interrelated questions that came up in the recent days:

No perfect solution for the builds yet, though I would consider local builds not the worst possible issue atm?

Imho, @jforbes (kernel) and @decathorpe (proven packager, fesco, council) should be priority, if they want. If it is realistic, three members might be a more resilient number than two. I'm happy to support/join if that makes sense. But if a higher number decreases our chances of acceptance, I suggest to stick with the two.

Concerning private tickets, I expect we can get a team space on gitlab.freedesktop.org (we depend on their security/integrity anyway, through systemd etc). I have already a space there, and private repos, private profiles & private tickets are enabled on freedesktop. My experience is that it is not very competitive to get a space there if it's reasonable and linux-related. That would not depend on me being one of those on the list of course. We must apply at the admins, but my feeling was that this is more to exclude spam and abuse rather than to only include specific linux topics (I expect a team space application is handled like a person's application).

- Who should be in Linux-Distros

- How many

- How to tackle private tickets (freedesktop, matrix PM, at some point maybe forge, ...?)

- Do we need any private infra or do local builds suffice

But Bugzilla does allow private bugs

!hi

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

Isn't bugzilla being decomissioned?

Forge issues will replate it

Eventually, though not before we have private tickets in the forge

I haven't used bugzilla private bugs much, how flexible is it? can we say "anyone in a FAS group has access"?

Basically it should be the current thing, and when it is decommissioned, the replacement will have the needed capability.

because if it does work that way I guess it works for CVEs though it can't work for general discussion not related to a specific package

Not entirely sure, though prodsec uses it for embargoes things still.

pretty sure package owners are the only ones visible by default

I personally wouldn't entertain any option that's not within the Fedora/RH infra

But I think I know who to ask at RH if we're thinking Bugzilla

In private tickets of SELinux people needed to be manually added unless added by component, at least that's how I remember it (didn't use it for nearly a year, luckily)

Correct. Something that has already been vetted is both available to us, and the default method of reporting bugs now. Seems the logical thing to use

as long as we can add manually I guess bugzilla is good enough for now

let's not bikeshed this and we can discuss the other parts (linux-distros)?

Yes, that's indeed a good alternative, and its from within the community :O

context: some of us already have access to linux-distros wearing other hats, and it's ... difficult to coordinate with Fedora since technically Fedora doesn't have anyone cleared to hear this

and given the rapid pace of CVEs these days it's ... confusing sometimes when you see an update pushed out and turns out it's for a previous CVE :(

Out of curiosity, how many members do the other distros usually have on the list?

As I said, I think jforbes and Fabio Valentini 🌈 would be the best choices if we use 2. Given what the two cover. Happy to be a third if that makes sense. But if a lower number has better chances of acceptance, I would stick with the two, if it is fine for them?

I am fine with being on linux-distros. I was on vendor-sec back when it existed representing rPath Linux/ Foresight. I understand the protocols. I am also a proven packager.

I think in the past the understanding was RH ProdSec acts on behalf of Fedora for embargoed CVEs, but in general we are not told until the embargo is over... I think it makes sense to have Fedora people directly, with the understanding that like in centos Hyperscale, we don't push things until the embargo is over but can test locally

yeah, I think provenpackagers make sense and jforbes is one of the few people who can actually build a kernel (given the signing requirements). +1 to both

if Fabio Valentini 🌈does not object

I think last time we asked though, they said Red Hat had representation and therefore they wouldn't add Fedora. Which Red Hat is the primary sponsor of Fedora, and makes some effort, but prodsec is swamped

*ping*

sorry, lost track of time

between me/Neal (wearing CentOS hats) and Neil (Rocky) and Jonathan (Alma) we are all happy to vouch for Fedora being added I think

yeah we can clarify that it's not working out in practice and let's just do it this way

FWIW I am not a provenpackager

because some things are serious enough we do need to test ahead of time - imagine having to iterate a few times and being slowed down by s390x...

we can easily fix that

I dropped the privs on purpose

I don't want to be

Does you being on the list as a CentOS person impact your ability to use the knowledge for Fedora if Fedora are on there?

ok, a packager at least :P

I already have 0 ability to use my knowledge for Fedora, officially

what I can do I guess is work on my own commit in the background and only push it out and do a PR after the embargo lifts. which is not ideal

Would you want to be at linux-distros?

I worry if it's a non-proven-packager that we'll end up with a queue of PRs to fix CVEs when there's a lot more time pressure than on a normal bug

Proven packager can merge the PR

So if he just asks we can merge it

yeah, I'm a provenpackager and can help merge, definitely

honestly I have trouble keeping up with my responsibilities as-is so I'd rather not be

Also proven packager should not just create and merge his own PR

A proven packager should be contained, but not sure if that is the most critical thing that everyone is :/ There is more communications that can matter

Well, it is still pretty much policy that we try to get the package maintainer to do it first

I just don't want to be dual-hatted on this, and in any case having more people is better

Just because a proven packager *can* do it, that shouldn't be the first line

Exactly

but yeah having advanced notice help us first work on the patch if it looks bad enough, and figure out who and where to contact when needed

and if the world is burning then I guess we can aggressively merge after say half a day

While not representative, during XZUtils, a major bottleneck was communications. Being able to work and connect to many in the short amount of time was useful (or... would have been)

This is only partially applicable to what comes down this road, but its still more than radical packaging.

We will also need some sort of policy on who gets read in, how that is handled, etc.

Yeah I linked the Gentoo one on the Forge ticket, I assume we'll need something similar

so should we try and figure out a policy first and then find people, or elect/nominate people first then have them take charge of figuring out the policy?

Makes sense so they have a clearer idea of what they're signing up for

Maybe the policy will be relevant for whose is best eligible to implement?

Would Fesco have any input?

is that a FESCo or a Council thing?

yeah, not sure. but Fabio and I are in FESCo so if we need to officially bless this we can

Definitely FESCo (...I think?)

* we can bring this up

something sligthly related came up at fesco - about who should approve crypto policies, and I think our workaround is that "until there is clear procedures in place FESCo gets to approve"

Worth discussing with FESCo, but realistically the policy for reading people is not directly tied to having proven packager representation on the list. It just improves how we handle the data we get from it

Just seems like it'd make sense to see if they have any ideas first, before we go and make a decision they might take issue with.

yeah, I think the more connected someone is to different leadership committees the more useful they will be to be read in

e.g. Fabio is not provenpackager but he's in fesco and is the council rep

given that we have two people dual hatted here (and Neal who's also in FESCo) I think it is fine to come up with something here and then propose it - I know at FESCo we get enough tickets to vote on we appreciate fleshed out proposals more than "let's figure something out about X"

caveat: personal impressions, I can't speak on behalf of fesco which has not officially discussed this as a body

(ok, I've now read most backscroll - I agree that having two Fedora representatives be able to read that security list would be good)

and I think who those people are can be figured out once this proposal passed the smell test

Ok, then, agreed to use bugzilla until we can switch to forge, if we do this & if nothing comes up that suggests otherwise, and work on a policy first, and then propose it to FESCo?

ok next topic then...

https://forge.fedoraproject.org/security/tickets/issues/12

I stand by my position that this is complexity for complexity's sake

Most is in the ticket. Personally, I would prefer to have the hardening Docs in Quick Docs for now, at least as long as most security Docs are in Quick Docs. I did some testing with QA's tech docs in their team space, and unless I search them specifically, Google doesn't output them at the first page. The SEO is bad

for EPEL there's only one set of documents iirc

with separate pages depending on who is reading

I had a chat with the systemd maintainer. So the hardening will be part of systemd. I'll maintain it. And I will do later some hardening possibilities for SELinux. The open question is just the Docs.

Most is in the ticket. Personally, I would prefer to have the hardening Docs in Quick Docs for now, at least as long as most security Docs are in Quick Docs. I did some testing with QA's tech docs in their team space, and unless I search them specifically, Google doesn't output them at the first page. The SEO is bad on Team pages with tech Docs.

Hardening should cover more than systemd/SELinux in the docs. Best practices, etc...

Absolutely. I mean for now something prepared that users can just enable and that is updated itself.

But a Docs page is easiest to allow users to enable it.

kernel hardening in systemd, for the selinux, not yet sure. If something changes in future, and we need to add or remove param, users will not need to do it. It will come with their daily updates.

It will be scoped to still ensure everything works fine for average users, but specialized use cases might be not considered if they might go along with security issues.

But that's not super relevant for now. It's more where I should put the first page. As I think its unlikely to be found when we put it to the Team spaces, which ain't intended for that.

But that's not super relevant for now. It's more where I should put the initial hardening page. As I think its unlikely to be found when we put it to the Team spaces, which ain't intended for that.

I don't think the Docs team will care if we have more Docs in our Team Docs. But given the purpose, I see little chance they would accept that we take more security Docs of Quick Docs to put them there

Chris (py0xc3): I would recommend not to use the "edit" feature during meetings. editing a message causes *every* version of that message to be present in the meeting logs, which is probably confusing.

I don't think the Docs team will care if we have more tech. Docs in our Team Docs. But given the purpose, I see little chance they would accept that we take more security Docs of Quick Docs to put them there

> But given the purpose, I see little chance they would accept that we take more security Docs of Quick Docs to put them there

why?

Because its Team Docs, to elaborate what teams are and how to join them.

Its usually already a hard process to convince to get something removed that is obsoleted or out of Quick Docs :) Even without putting it to something that is actually off topic

from what I've seen (and heard Docs working group members say), they prefer docs to be maintained by technical people actually involved with the topic, so I would be surprised if we said "hey we're the Security SIG we want to maintain these docs now" and they'd say "no"

True. But they also keep their umbrella on their structures. Team pages are to say what is this team and how to join them. Not to elaborate tech.

I'm not convinced that's correct

what is this "Team page" and why is it relevant to this discussion?

Cloud SIG has pages on running Fedora in AWS, Gaming SIG has pages on installing Steam on Fedora

Engineering Teams -> "Learn about FESCo and Engineering subprojects, SIGs, Work Groups, and teams."

Those sections of the docs site are not just holding pages for each tema

https://forge.fedoraproject.org/docs/tickets/issues/50 may be relevant here, we could probably get a security captain

For me, the question was just where to put the Hardening page :) This ended up two weeks ago in a long discussion about Security Docs, SEcurity SIG Docs, etc.

Personally, I could not get a Search Engine to find tech documents within non-tech pages that elaborate a team. That's why I would prefer Quick Docs for now.

and I still don't see why those have to be two separate things.

> discussion about Security Docs, SEcurity SIG Docs, etc.

let's not overcomplicate things please?

if we end up having too many documents that a natural split into two sections make sense, then we can discuss it

I'm conscious of the time and that rzhukov wanted to talk about CRA today

My point is just, has anyone a problem if I put the hardening page to Quick Docs for now, at least as long most security pages are there anyway? If people search for hardening, they don't go to the pages that elaborate the tasks of a team, and search engines show only Quick Docs on first pages. That's all :) In everything else, I am actually quite neutral myself

if that's where most of the docs are right now I see no problem adding more there for now

Yea I'm kinda in the same boat. I like having things orderly, but there's a point when trying to organize further makes things disorderly.

Right now it feels like we're trying to build a lot of structure without much to take advantage of it.

Until we have a larger corpus of docs, this is kinda adacemic to debate where they will go. Maybe we should focus on getting stuff written, keep it all in our forge for now. Then once we have a collection of things that might be better suited to go elsewhere... we then bundle them together and approach the docs team to get their input as to if they have a better idea.

Ok, then the critical part is closed :) For everything else, I guess whoever has time can pick up the task and start talking to Docs about if and how to consolidate security Docs over time?

we're... 54 mins in, do we have time to talk about CRA?

I don't mind running a bit over

I'm fine with it. I have time

sorry Roman, bikeshedding :/

I guess I'll be double booked with FPC

I'm writing firewall policies for $DAYJOB, happy to loiter although that only works if rzhukov is around

Unfortunately, I can't go over :(

Ok, then I put it as first topic for next meeting?

or TL;DR it first and see if we can discuss some of it async?

We can start with it next call? Actually docs discussion is super relevant. 1 thing that we would need to do is to figure out what we call "Vulnerability and Incident Response Policy"

I do need to leave at the hour, so if you do need to go longer someone else will have to end the meeting

we can make the CRA thing the top item for next weeks meeting

Also see general Fedora Updates policy https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/

This is the list of the "security-related" docs that we found: For infra apps and services there is skeletal sec. Policy for app development https://docs.fedoraproject.org/en-US/infra/developer_guide/security_policy/

For the distribution content, it’s the responsibility of the maintainer https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#security_updates and https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_manage_security_issues

This exists but is meant as guidance for all open source developers, not really a Fedora policy https://docs.fedoraproject.org/en-US/defensive-coding/

rzhukov: We can talk in the channel about what exactly I shall put on the agenda. But yes, I guess if no one objects, we can make that the first topic next time?

yeah, I think Fabio and I need to go to FPC anyway

and rzhukov won't be around too

TL;DR or question: Do we want to clean up/adjust those as part of the broader ^^ security docs discussion?

Ok, no probs to defer to the next one :)

Would be good to have a ticket on https://forge.fedoraproject.org/security/tickets so we can prep answers to those questions

Thanks folks, I read (almost) all the chat 😄😄

will do

cheers folks!

q5sys: end meeting?

Also need to leave, bye :)