Creating Fedora security incident organization: Deriving from XZUtils lessons learned, security(-dedicated?) SIGs, and information flows (with some incentives from research)

This is partly a follow up and partly an implementation of thoughts from the topic “xz” lessons learned: if/how to involve Fedora Magazine in CVE handling? (… and partly something new : )

I am currently working on a related publication draft, and I like the idea to start an (indirect) first attempt to bring thoughts and knowledge from two (from some point of view, three) different types of communities/fields and their people together (all contributing and affecting global security directly or indirectly) to get and create some incentives for “common/converging problem solving” (problem solving is what can bring people together / make them talk, and thus start a process to learn from and engage with each other on the long term). Also, this maybe brings the work on how to mitigate incidents like the XZUtils one forward (or at least its discussions).

First of all, I widely stick with the general goals of my previous suggestion from the first Lessons Learned topic, which aimed to create a strong outreach in the community and beyond when it is necessary, in order to avoid bottlenecks and avoid isolated/disconnected “information bubbles”. In my research, I came to the conclusion that the Linux and other communities intuitively create (social, technical, socio-technical) systems that prefer the risk of forwarding unintended information/data over the risk of hindering intended information/data (which seems to have proven competitive).

@kevin mentioned my previous suggestion creates a lot of noise and many will not respond: he is definitely right. But this is also a matter of statistics: the more channels are affected by the noise, the more people are likely to experience the noise, and the more likely it is that any one skims over the noise and might think “hey, I can act here and I have knowledge or privileges that might add value!”. In the end, noise is how I became aware of the issue in the devel mailing list and thus could set up and link the issue to the discourse topic. The XZUtils case in general became revealed by a realistic statistical likelihood in the big Linux community that any one does any test that reveals it. I think the impact to have much noise around one specific topic, at least if it is a “hard case” like the occurred one, introduces more advantages than disadvantages.

Yet, noise can create more advantageous statistics and higher outreach but it generally is not a solution of our issues on itself (I guess we can consent at least on the latter) because too much undirected noise can develop to a denial of service and thus achieves the opposite of what we want - so at the best, “some” noise is a complement to a solution to mitigate or bypass unexpected (social and technical) single points of failure and to create some deterrence against attackers who target Fedora explicitly since it cannot be foreseen who and what gets involved when, which makes the attackers’ own risk assessment and anticipations of the attacks’ development hard (Fedora being targeted explicitly was likely not the case in XZUtils but something still noteworthy).

In order to finally create a realistic solution, I suggest to create two mailing lists / mail addresses and I will then explain in the following why:


  • One mailing list (e…g, “incident-response@fedoraproject.org”) that EVERYONE WITH FAS ACCOUNT can receive emails from, but ONLY FAS GROUP MEMBERS (so people who not only have an FAS account but who are in any group in FAS and thus established and integrated members of the community) can sent emails to:

    → if any established member who knows Fedora (and thus its needs/properties/attributes) identifies a security-critical issue like the XZUtils one, they might use this mailing list to make aware. Limiting the possibility to send to more deeply involved members shall avoid unnecessary noise on this channel and thus ensures that occurring noise on this channel remains taken serious by recipients. We might encourage all Fedora people to subscribe here, or even talk about opt-in or opt-out when they enter any FAS GROUP. I assume the devel mailing list itself should be a recipient of the list. Maybe members of other groups can be also automatically added to the recipients of this list (then the ask-fedora and other mailing lists will be used for something other than spam :smiley: ): many people can contribute and outreach if they become aware. The ask.fedora topic seems to have served as valuable information and point to connect, so if ask.fedora people get the mail, it is sufficient if 1 of 30 recipients has time in order to achieve the creation of a related ask.fedora topic that informs users and allows to connect. The same for other teams. We should create a high outreach here to bring people together. We might add an automatic appendix to any email that is distributed through this mailing list before it is distributed to recipients: an appendix that details about the sense of this mailing and how to behave and what people could do in their respective team and with their respective privileges. The devel mailing list already adds some appendix to all mails, so the capability for adding something to mails before their distribution already exists.

  • One mailing list (e.g., “vulnerability@fedoraproject.org”) that ONLY VERIFIED PEOPLE (tbh, I tend to not include all FAS GROUP MEMBERS but even limit this mailing list to people whose real identities have been verified by some means) can receive emails from, but EVERYONE WITH FAS ACCOUNT can sent email to:

    → if any FAS member experiences an issue they consider critical, maybe even a vulnerability in any Fedora element/package, this might be used to inform trusted core members of the community. Since these issues can be something that can be exploited, I tend to limit recipients the way I mentioned. We might consent to publish anonymized (or complete?) data about incoming traffic here after the issue could be mitigated. This list can AND SHOULD include the RH security team in order to bring the community and them together (a major issue at the XZUtils case). Because such vulnerability/security report mailing lists exist also upstream and because most vulnerability-related mailing addresses are not limited to RH internally, I guess this is not a legal issue for them if it is done the same way here (feel free to add contrary comments). But this way, we can mitigate the split in information flows between the internal RH security team and the community (the latter also included RH people that seem to have been often limited to one side of the information flows, this is indicated at least by what is documented in public data - again, feel free to challenge my derivation here).

    → This way, the RH security team also gets all information, and what they do internally on their website is their issue, but what is published under the name Fedora should be consolidated, evaluated and prepared in this mailing list or other places of Fedora, not internally at RH (as far as I interpret the public data, it looks to me that RH people who were not involved with the actual development/packages, had no choice but to rely on information provided internally at RH as there was no clear place to rely on in Fedora). This way, it remains comprehensible what information has originated from where (Fedora, RH) - in the XZUtils case, this remained unclear until the end, which made it harder to mitigate the problem of the split information flows: it was unclear what information originated from where and thus it was unclear whom to talk to in order to identify what is more mature information. With this list, we also create a transparent source for involved Fedora people to derive Fedora Magazine articles, ask.fedora topics and so on… a place where it comes together and reliable output to be spread to community members can be created. And from “vulnerability@fedoraproject.org”, the above mailing list (“incident-response@fedoraproject.org”) can be involved as well to then trigger the community with what is relevant/important/trusted.

    → I think this could help both RH and Fedora to identify and overcome bottlenecks both sides experienced during XZUtils, whereas that still allows RH to act internally the way necessary to create the legal certainty they need. Creating effective/clear borders of the two entities is important to create effective/clear points to connect and exchange between them. The case has shown that RH indeed refrains to intervene in the community, which we saw when the information flow splits did not correlate to RH people (I want to mention it for people who have not been involved in the case because at first glance, the case can provoke “RH owns Fedora” perceptions and thus provoke such comments, which I would like to avoid - indication does not prove anything for sure but in my interpretation of the available data, it goes in the opposite direction).

Mailing lists remain a core element in Fedora and its communications up and downstream, and in between teams. This includes the devel mailing list, which has been seen to have evolved intuitively to the center of any mitigation means of the XZUtils. It still can, as the above mailing lists are primarily entry vectors, connectors and triggers. The dynamics of the community shall decide which channel actually develops to the center → don’t create statics in dynamic developments as they can destroy/hinder people’s intuitive capability to dynamically tailor to situations they experience.

The first mailing list gives tribute to the fact that dedication / separation of security also separates information flows, which can separate people who “experience (parts of) the problem” from people who “have knowledge that contributes to solving the problem”. In the end, everything comes down to a problem that needs to be solved :wink: Everything is somehow related to any type of security. Major points in my research…

The second list gives tribute to the fact that I recognized that, although in the Linux world (which proves sufficiently resilient in “security matters” despite attractiveness of attacks because it drives the majority of and on the Internet) security is mostly an integrated topic (“its just problems to be solved, urgent or not”), there is still a positive correlation of dedicating/separating security means when privacy is involved (this can be just a dedicated entry vector of information but also people who are evaluated rather than the content they keep private; positive correlation means here, the dedicated/separated security AND privacy often or usually both do apply or both not): privacy is meant in generic terms of data/information that can be used against something or someone if exposed publicly.

With this approach, we would have a “security SIG”, but it would be as dynamic as the community, without dedicated/separated security infra or people, but one that is dynamically integrated into a dynamic community. Security is here nothing separated or dedicated, but only an entry vector to trigger and direct information flows without creating unnecessary distracting noise (and without exposing what can be harmful). Create effective and efficient information flows when they are (time-)critical :wink:

Beyond implementing some findings of my research [1][2], this approach “steals” ( :stuck_out_tongue: ) from an incentive from @mattdm who already integrated the confined-users and incident-response into a common security-sig in discourse, without enforcing some dedicated/separate security-sig. So when we deploy my approach also to the tags that Matthew has already created, we might say: if anyone is not sure about security implications of something for Fedora or the community, they might feel free to add the security-sig as generic tag to their topic, and everyone is encouraged to review such topics (and maybe subscribe to the tag) in order to get security-related review (indeed, massive distributed review/testing from different perspectives is a major element in the way security is created in Linux). Everyone who creates and opens a topic in Project Discussion can be a member of security-sig , and so far, Project Discussions do not create much noise/traffic in general, so I am not sure if it is even necessary to restrict the use of such a tag. People should be safe to use it without fearing too many emails (we might restrict it later if that changes). At the same time, incident-response can serve as counter-part to incident-response@fedoraproject.org , and maybe linked (socially or technically).

Looking forward to thoughts, alternatives and challenges :wink: If anything is unclear, feel free to let me know: I aim to make data & knowledge from all sides compatible to the respective other sides: academia, the Linux/crypto/related actors/communities/entities (that already solved a lot of problems that are still debated - the latter not seldomly with much less effective approaches but also vice versa), and non-tech actors/communities/entities (companies, organizations, governments). Obviously, they are overlapping and there is no clear boundary (in some areas, these “communities/fields” are even equal, in some they ignore each other - it is people who “call”/“cause” and connect systems in their very situation… or not - I don’t go deeper here for now). But too much problem solving “in the world” is split at the moment (it’s about information flows), and in many cases, one side deploys bad compromises that could be easily improved by a respective other side. Here I start to create and gather incentives :slight_smile: Just that you get a little my superordinated idea/reasoning… In this topic, the focus shall be the Fedora problem we experienced during XZUtils and how to mitigate it in future…

[1] Because Linux is law: mapping the socio-technical architecture around Linux and determining its institutional dynamics
[2] The order of information flows: How people in self-organized collaborative competition integrate sufficient holistic socio-technical security THROUGH anarchy rather than providing security IN anarchy (PhD project interim title)

1 Like

Hello @py0xc3 ,
Sorry, I haven’t read fully through what you are proposing here, I will though. From the community POV in a general sense let’s say, I would like to see a graphical indicator of security status (on this site, the main fedora landing page, the comm blog, matrix, etc…) that was also a link to a details page on the current/past security issues being faced by Fedora, whether that be the projects infra or the releases. I think something like this would be better than a mailing list, but have a mailing list for the SiG? you’re proposing, thus reducing the noise.

  • Why graphical indicator? Quick visual with audible to cover a range of inclusiveness and provide a quickly identifiable state using obvious visuals and colours and audio.
    *Where would this go? Possibly the landing page of Fedora (start.fp.o) and both discussion.fp.o and ask.fp.o as well as the commblog landing page, and the chat rooms, and possibly an rss feed if that is appropriate and still used.
1 Like

There is no SIG. Any attempt to create one has been obsoleted quickly. And at no time a security dedicated SIG had been integrated throughout the community, at least not the time I was here. So that’s already an issue on itself, but of course worth to be discussed too!

The one security dedication that existed (a type of “security SIG”) was the RH security team, and that one remained isolated from the community throughout the incident. So I consider it another failed attempt to dedicate security, although I admit there is not sufficient data to say for sure what the issue was and if it was really related to dedication of security. But in any case, they have not been integrated with the community, and thus their information flow was not up to date with the community. The last state was that their information was incorrect most of the time, and those who knew about the issue were not able to reach out to them.

Fedora is itself the outcome of a widespread collaborative competition of many projects. Our teams are very diverse and have often different organizational structures because they are sometimes more integrated with their upstream rather than with some other Fedora teams. So I am not sure if creating a dedicated/separated security SIG will get relevant data or be able to spread it independent of affected areas.

I like the idea, but someone has to control and set it, which means at some place all data needs to come together. (If I get your idea right). The related Fedora Magazine article used to have the goal to achieve that, but most of the time, its information was wrong.

Yeah that seems to be the crux of the technical side of pulling the details out of various contributions, announcements, etc… there is no SiG for security threats so there is no coordination within the project, but that really is a flaw from anyone’s POV. So the only recourse actually is to form the SiG among those interested and willing enough to take it on, since it is a larger than life task for an individual.

1 Like

So far, security dedicated/separated SIG-type formations have had no impact, disappeared or even contributed to spread false information because they split information flows and created isolated information bubbles. Effectively, in the recent case, that split the community in a type of social (or “socio-technical”) “net split”. Related approaches have not worked so far, and now we know it didn’t work with the RH security team as well. If you disagree with integrating security and if you prefer to create something dedicated/separated (security SIG with dedicated/explicit members), how to do so without repeating the given experiences? Why to assume that creating a new security SIG will have a different impact than before?

Of course your idea should be part of the discussion as well - it is a totally justified one - but if we just try again to form a “security SIG”, I see no reason to assume it will differ from past attempts, unless something is adjusted to tackle the issues we experienced. The question here is what and how. (Which obviously leads back to the question why things used to be the way they used to be : )

Absolutely :smiley: And we’ll never know for sure until we failed :smile: Additionally, information flows might be relevant in both directions, and usually it is not just one or two points where relevant information is coming from. A lot has to be coordinated and exchanged. Imho, this works best and most reliable without bottlenecks in between and in a decentralized manner, but with incentives and triggers that “make people talk” and evolving into common directions. It will be always dynamic, and each new case creates yet unforeseen new dynamics - this is what we have to be prepared for

This is a long read and I’m afraid I had some difficulty reading thru it
all. :wink: but some thoughts…

First in general, I am not sure we want to create / push any new mailing
lists. I know @mattdm would like us to move more here than lists.

All our existing lists are opt in. We never subscribe people without
their consent, and if we did, some people would be pretty upset.

We can set lists to be moderated (ie, all posts must be approved by list
owners), but we don’t have any way to only accept emails from specific
people. email isn’t really authenticated, so it’s really easy to just
forge emails from whoever you like (and spammers do).

  • One mailing list (e…g, “incident-response@fedoraproject.org”) that EVERYONE WITH FAS ACCOUNT can receive emails from, but ONLY FAS GROUP MEMBERS (so people who not only have an FAS account but who are in any group in FAS and thus established and integrated members of the community) can sent emails to:

    → if any established member who knows Fedora (and thus its needs/properties/attributes) identifies a security-critical issue like the XZUtils one, they might use this mailing list to make aware. Limiting the possibility to send to more deeply involved members shall avoid unnecessary noise on this channel and thus ensures that occurring noise on this channel remains taken serious by recipients. We might encourage all Fedora people to subscribe here, or even talk about opt-in or opt-out when they enter any FAS GROUP. I assume the devel mailing list itself should be a recipient of the list. Maybe members of other groups can be also automatically added to the recipients of this list (then the ask-fedora and other mailing lists will be used for something other than spam :smiley: ): many people can contribute and outreach if they become aware. The ask.fedora topic seems to have served as valuable information and point to connect, so if ask.fedora people get the mail, it is sufficient if 1 of 30 recipients has time in order to achieve the creation of a related ask.fedora topic that informs users and allows to connect. The same for other teams. We should create a high outreach here to bring people together. We might add an automatic appendix to any email that is distributed through this mailing list before it is distributed to recipients: an appendix that details about the sense of this mailing and how to behave and what people could do in their respective team and with their respective privileges. The devel mailing list already adds some appendix to all mails, so the capability for adding something to mails before their distribution already exists.

I fear this may be misused for ‘xyz security bug isn’t fixed yet, fix
it!’ type emails.

  • One mailing list (e.g., “vulnerability@fedoraproject.org”) that ONLY VERIFIED PEOPLE (tbh, I tend to not include all FAS GROUP MEMBERS but even limit this mailing list to people whose real identities have been verified by some means) can receive emails from, but EVERYONE WITH FAS ACCOUNT can sent email to:

    → if any FAS member experiences an issue they consider critical, maybe even a vulnerability in any Fedora element/package, this might be used to inform trusted core members of the community. Since these issues can be something that can be exploited, I tend to limit recipients the way I mentioned. We might consent to publish anonymized (or complete?) data about incoming traffic here after the issue could be mitigated. This list can AND SHOULD include the RH security team in order to bring the community and them together (a major issue at the XZUtils case). Because such vulnerability/security report mailing lists exist also upstream and because most vulnerability-related mailing addresses are not limited to RH internally, I guess this is not a legal issue for them if it is done the same way here (feel free to add contrary comments). But this way, we can mitigate the split in information flows between the internal RH security team and the community (the latter also included RH people that seem to have been often limited to one side of the information flows, this is indicated at least by what is documented in public data - again, feel free to challenge my derivation here).

    → This way, the RH security team also gets all information, and what they do internally on their website is their issue, but what is published under the name Fedora should be consolidated, evaluated and prepared in this mailing list or other places of Fedora, not internally at RH (as far as I interpret the public data, it looks to me that RH people who were not involved with the actual development/packages, had no choice but to rely on information provided internally at RH as there was no clear place to rely on in Fedora). This way, it remains comprehensible what information has originated from where (Fedora, RH) - in the XZUtils case, this remained unclear until the end, which made it harder to mitigate the problem of the split information flows: it was unclear what information originated from where and thus it was unclear whom to talk to in order to identify what is more mature information. With this list, we also create a transparent source for involved Fedora people to derive Fedora Magazine articles, ask.fedora topics and so on… a place where it comes together and reliable output to be spread to community members can be created. And from “vulnerability@fedoraproject.org”, the above mailing list (“incident-response@fedoraproject.org”) can be involved as well to then trigger the community with what is relevant/important/trusted.

    → I think this could help both RH and Fedora to identify and overcome bottlenecks both sides experienced during XZUtils, whereas that still allows RH to act internally the way necessary to create the legal certainty they need. Creating effective/clear borders of the two entities is important to create effective/clear points to connect and exchange between them. The case has shown that RH indeed refrains to intervene in the community, which we saw when the information flow splits did not correlate to RH people (I want to mention it for people who have not been involved in the case because at first glance, the case can provoke “RH owns Fedora” perceptions and thus provoke such comments, which I would like to avoid - indication does not prove anything for sure but in my interpretation of the available data, it goes in the opposite direction).

Red Hat has Security contacts and procedures - Red Hat Customer Portal
which basically says to mail secalert@redhat.com. I don’t know that they
would be interested in having another point of contact via fedora that
would have an unknown number of people involved.

Mailing lists remain a core element in Fedora and its communications up and downstream, and in between teams. This includes the devel mailing list, which has been seen to have evolved intuitively to the center of any mitigation means of the XZUtils. It still can, as the above mailing lists are primarily entry vectors, connectors and triggers. The dynamics of the community shall decide which channel actually develops to the center → don’t create statics in dynamic developments as they can destroy/hinder people’s intuitive capability to dynamically tailor to situations they experience.

It did. Party though because we didn’t have any well known alternative
and people just go to what they know (IMHO)

I think I might prefer something more structured, but less on technical
details. I think some of the confusion or issues we had were because we
didn’t know who or where to look for things, so as you noted, people
gathered around the devel list (and other places).

Some questions:

  1. When do we know when something is a ‘incident’ that we need to have a
    story around and information flowing, and when is it just a ‘security
    bug’ that follows our normal process? Who decides?

  2. Once something is decided to be a incident, I think we should appoint
    someone as coordinator. Possibly someone from the infosec team, or who
    can interact with them closely. This person would then be the one to ask
    for updates, would gather things, check facts, etc. Note that this
    should not likely be someone who is working directly on fixing the
    problem, but someone technical. Perhaps the council would appoint them
    (if they could do that fast enough, that might be too slow)

  3. For such a person, we could have a checklist. Something like “initial
    notification to community, On xyz , on mailing list on magazine
    , etc”. Including a note to send a ‘all clear’ at the end and
    organize some kind of retrospective. The coordinator could decide where
    the best place to keep up to date information would be and answer
    questions, etc. Then we don’t need to decide mailing list or whatever,
    we just need to make sure it’s clear who the coordinator is and where
    they are going to be providing updates/in what way.

There’s a zillion ways to do all this, but it’s really good to discuss
this before need to do something again, as I am sure we will.

3 Likes

Sorry for that :blush:

Well, that’s actually not literally correct. When people are added to groups/teams, they are added to lists without being explicitly informed about it. Several people became aware of being added to the ask-fedora mailing list (and actually that one exists) when it was started to abuse it for spam. I was added to several mailing lists of Docs when I joined that team a long time ago.

But I agree that this slightly differs since people do not opt in to the list. Yet my point was less to add people themselves but mailing lists as recipients in this respect. But your argument still applies to a large extent of course. Something like that should in any case not be done without at least get a lazy approval from the wider community. But opt in remains as another possibility. Or something completely different^^

It is less intended to prevent that. Such attacks are unattractive and can apply to any of our mailing lists anyway. My point here was more to avoid what you already mentioned:

→ if the senders are limited to people who know about the community and that this is not the way security bugs are fixed, makes it less likely that it occurs that way.

Well, it is not only about what they want. In the last incident, the RH security team became Fedora. Their internal state was published under the name of Fedora and communicated to the whole community as such, without any consult with the community or any information about their actions. Since they remained isolated from the community (including isolated from RH people who were working through the community), they lacked information, and as far as we know, their internal state was wrong, and thus wrong information that was distributed as Fedora information. Although we had people (including RH people) working on the issue in the community, which included those who were involved with the very packages and the affected areas of Fedora and their upstream, there was no working information flow between them and the RH security team. Correct information was available in the community.

I am thankful that people acted and did not refrain from acting, and I am thankful for the work of the RH security and all others teams and those who did their best to propagate information about the issue - at the very time it was possible only to a limited extent to verify information. The outcome was in any case better than the absence of actions. But now that we know the outcome, we need to mitigate it. The absence of communication before publishing information as Fedora information contributed to the confusion and to the condition that most did not know/understand for long what is correct and what not, and the absence of knowledge of what originates from where made it impossible to find out whom to ask. Everyone including the RH security team acted when it was necessary, as good as they could, but while it was an understandable outcome the last time, it would imho not be acceptable to reoccur that way.

If RH would need to take over the situation and what is published as Fedora for legal reasons in such cases, they would need to let the community know (and information has to be somehow traceable to its source when published anyway). If not, we need to find a way to either split the information flows between the RH security team and the community in order to ensure that it is clear what belongs to / originates from where (everyone decides themselves what to publish in their name), or we need to find a way to connect or integrate their information flows.

As you suggest, my proposal can be questioned in several respects, and I lack information about some internals and also from the perspectives of several Fedora teams. My proposal is more to encourage a discussion towards a solution :wink:

A definition would be indeed a good thing to start. In my proposal, it would be a limited set of people who could start a discussion in a mailing list or any preferred channel. If the currently available people consent that there is an incident occurring that can impact Fedora users or members and/or any of their private data in a negative/disadvantageous way, I tend to consider it as security incident.

I generally agree to that, especially that it needs to be someone with relevant technical backgrounds. But the question is if someone can be appointed in advance. The last time, we could not rely that any specific person or team is available. Most jobs at Fedora are not intended to be time-critical. We would introduce a single point of failure if the appointment is done in advance. Does it maybe make sense to not appoint the person but the process to appoint one when an incident happens?

The last time, it was @catanzaro and @rjones who were closest to being the overall coordinators. I tend to assume someone from the devel mailing list should be appointed. They have the highest outreach I can think of, and technical knowledge by default. Or instead determine a process that, when an incident happens, people in devel agree on someone who is currently there to act as coordinator, also with responsibility to outreach. Actually, this is what happened the last time. It is the outreach that causes the problems, it is high, but Magazine and discussion.fp do not yet count to it. This is what would need to be added. We might be more explicit and focus to ensure a connection to the areas of Fedora where people are listening. This is discussion.fp, some mailing lists, and the magazine. So offering the devel mailing list a way to outreach to any of them already would make a difference.

100%!

100%, too :slight_smile: It’s the discussion I wanted to start with some proposal that can be challenged. It was a little the proposal for KDE being the new default that made me think of doing that :stuck_out_tongue: The idea is mostly to encourage discussion with challenging something and by putting something forward that can itself be challenged.

I think you are mixing up aliases and mailing lists?
When you are added to a fas group you are adding to an email alias for that fas group. This isn’t a mailing list, you can’t add/remove people from it except by adding/removing them from the group.

If someone added you to real lists without your consent thats not ok. :frowning:

I’m personally pretty against ‘opt-out’. Doing that is when people start calling you spammers. :wink:

On the RH security team state, etc: I agree there. I wonder if we couldn’t try and get them to only point people to our communications channel next time? ie, sure, do a short post, but talk about any affect for Red Hat, then say “all fedora communications on this are available at X” and that way they would not be in the position of having inaccurate info and us needing to try and help edit with them.

I think there is always some measure of confusion and bad information around these things. People expect us to know everything and tell them at once, but sometimes something we think is the case turns out to be wrong, or some things we simply don’t know yet and speculation leads to bad information.

I’d like us to try and be conservative and share what we know, but avoid speculation and talking about things we don’t know.

That does bring up another issue however, in that it would be nice to communicate in a way that allows people to see what has changed. Edits are constantly being done, etc. It would be nice to have some kind of changelog/timeline so people know that what they read eariler and is no longer there really was there before and removed/reworked.

I don’t think we should try and do some big process for anything that could impact fedora users. There are package security updates flowing every day that could be considered this. I don’t think we should activate a big process all the time. Only for MAJOR incidents like this xz one.

1 Like

Well, our mailing organization makes the difference between opt-in and opt-out a little fluent in some respects :wink: But one can say of course that at least joining the FAS group is an opt-in scenario and one has to expect related emails from joining a group.

I generally agree, although I tend to always check the very case before rejecting it. I just wanted to mention all possible variables for that type of solution, opt-in & opt-out, as something that would need to be discussed later if a consent would develop towards such a solution. For now, it shall be just a point to start discussion. Generally, I am a friend of creating incentives for volunteering, and incentives to become aware of needs and potential for contribution but also about the return on invest for each contributor.

At the moment, I admit I like the idea derived from yours, the one of centralizing such things in devel, and make them to appoint someone or two to become “maintainer of the case”, as it intuitively has occurred last time, and then just think of how to enable them to create a proper outreach from them to where it is necessary. Reaching discussion.fp & the magazine (maybe along with other mailing lists) might be already something that could make a difference in making those people aware who have to do something (for themselves or others). That would also “create” someone “identifiable” to go to, for those who know something is going on but not yet whom to believe (such as discussion.fp or Magazine authors or so), and those who think to have more/newer information. This would be much less invasive than my original proposal indeed.

Yes, and the case has shown that people can align and balance a lot if they have the possibility. I think the case has shown that the community has responded to an unforeseen situation in a well way. But there is space for improvement, and a few things should be mitigated in future. Nothing time critical yet of course.

100% on these things.