Flock 2026 The EU CRA Vs Community: Why You’re Safe, And How Stewards Help

Good afternoon everybody. We're so happy to be here. Uh and thanks for surviving over the lunch and coming here for this presentation. Um yesterday we had a workshop uh about the CRA. Today is going to be uh more a talk but you will have the chance to ask your questions at the end. and we're going to talk about the EU cyber resiliency act and how it affects communities and why you're actually safe and how [snorts] stewards uh can help. Uh my name is Roman. I work for Red Hat. I'm leading open source security strategy. >> Okay. So, hi. Uh oldtimers maybe know remember me because long long long long long and longer time ago I used to be Federa program manager. So, I spent you know a lot of you know time on Federa. I'm really you know glad that the compliance things you know brings me back to community. I wouldn't never you know imagine that. So that's interesting. I now work in product security. Uh our new name is governance risk and compliance team and I do a lot of you know these you know crazy CRA kind of like stuff. [sighs and gasps] Yes. That's crazy. But um before dive diving into the craziness, we prepared some questions to you just to uh hit up a little bit and get a sense of the audience. Uh the first question would be, have you heard about the UC array? Wow, that's a lot. So that's actually interesting thing that uh we will talk about it later that CRA is not applicable to open source but from my personal experience it looks like open source community is more engaged in CRA and more interested in CRA than actual manufacturers that you know will be or will need to be compliant with CRA. So there was this you know recent survey by the open SSF uh the security foundation that among you know the manufacturers and it's actually you know getting worse every every year the results are worse than before so only uh so still 66% of uh surveyed respondents is are not familiar with CRA and I will tell you later that it's actually quite scary thing because you know it's CRA is coming and it's coming earlier than anyone, you know, anticipated. >> Yeah, that's an interesting uh statistic. You can scan the QR code and download the full report uh if you would like. Um now, do you think you or your project have some CRA obligations? Uh okay. Yes, a few hands. That's that's yeah, that's good one. Uh, and finally, do you want your project to be at a good quality, widely adopted, and widely adopted by users, and have good security practices. Woo! [laughter] Well, in the in the good room, thanks for answering these questions. We're going to dive in into some topics, but uh it sounds like it's going to be useful for um a lot of folks here. Now, I mentioned we did a workshop yesterday, and uh I do understand that not everybody with this room participated in yesterday workshops. That's why we uh actually here uh decided uh on last minute like a couple of minutes ago to um pull into the some takeaways from yesterday workshops. Uh the actual take takeaways are here on this part but uh to summarize them in the more printed characters. Um so the takeaways are uh there are no fines for stewards and maintainers are out of scope but users adopters and manufacturers expect the CRA readiness from open source projects and Fedora specifically. Anyway, so that was the uh one of the takeaway. The second one is the time is now right. If we wanted to improve security posture and wanted to think about the CRA and about adopters of our open source projects and of Fedora, we need to act now. Standards and practices are built at this very moment by community, by industry, by policy makers and we no we urge everybody to actually join this efforts to help and to build that would be that's something that would be useful for all of us, right? but not just wait on the sidelines until somebody else uh makes decision how we should act and how we should do and finally CRA uh yes everybody probably or hopefully after the yesterday's workshop got yes the CRA is coming this is not something we can prevent entirely and the question was we don't understand what exactly we need to do uh and how can and how we can contribute on healthy security and CRA efforts The honest answer and the takeaway of the workshop is we actually neither. So we don't know as well. We need to figure that out uh together and there are some links about the work that is happening on the fedora specifically to figure out how to do security better how to do CRA better. But if you have any more questions join the work on these tickets and also you can reach out us by these emails if you want to learn more or if you want to help. So that was takeaways. >> Okay, maybe I will add one more thing before I will jump to uh next slide is that we actually plan you know to be as more as involved in Fedora as possible. So we are thinking about uh making a change request and whatever you know is needed you know to make it super transparent what we want to do and how you know like to achieve it. So if you have any you know other ideas how we can you know communicate it to the community what we want to do please you know let us know because it's also super helpful insights. So yes this is for yesterday's workshop and thank you again you know whoever participated there if you were there yesterday maybe you can leave the room now because I will repeat a little bit you know about you know what CRA is about but it's great you know that everyone you know understands CRA already. So, so basically the main idea of the regulation is to how it say here is to safeguard European customers or consumers. So, this is all about consumers about you. So, you probably know you know how many uh different IoT devices you have at home that are coming from you know some you know countries that might not be you know friendliest countries and have you seen updates for these IoT devices? Not very often like you just you know buy something you will never see any update doesn't matter if it's security update or not. So basically the wall goal is cyber resiliency act is to establish the cyber essential cyber security requirements is actually called essential requirements in the legislation for companies that operates in the US. Basically uh thing is called products with digital elements. It's a very you know nice way how to say it's software without saying it's software. So yes PDE is you know what you are looking for the legislators obviously doesn't know you know our you know terminology. So yeah, we are talking about proto digital elements and the main goal here is to first you know reduce vulnerabilities in the products as I know mentioned it earlier and then another thing that wasn't very you know common in the past is also the life cycle of the products on the market. So we are calling this you know placing product on the market. Basically when you you know release thing it's a place in the market and that means there will be mandated minimal amount of support you actually need to you know provide to your uh support. Oh, thank you very much. And uh of course the last thing Yeah. And the last thing is like okay so so okay we have time perfect thank you because our colleague you know try to you know remove us from this stage but and save your time and yeah so there are you know different you know uh scopes and roles and I will talk about it uh later and very interesting part about this is the compliance question because it's all about compliance I work for compliance team. So you know European Union knows how to find companies for doing wrong things. In terms of CRA we are talking about fines up to 50 million euros or 2.5% of global revenue. That's actually you know could be significant for I don't know companies like this company Roman has on the sheet t-shirt or there are even you know bigger companies with you know huge revenue. And why I you know said is not a good idea that people do not know actually manufacturers do not know about CRA. The first obligations are coming in September. this September that means you know you have like last few days of of June then you have summer holidays and we are in Europe so it mean like two months of nothing and everyone will be at the vacations and then the obligations will be there for manufacturers and 66% are not aware of CRA and uh the full uh the CRA will be fully in effect uh after December 2027 and it's expected the regulators will be ready. They are saying that we will be ready the day one. So yeah. Okay. And now I will talk a little bit more about you know what the products with digital elements are and uh what categories of project products of digital elements we have. So there are three categories actually you know in relatively four categories. The first category is you know this default category that means for the standard consumer devices toys and simple devices and so on it's expected 90% of all products will fill will fit into this category the default category and I will talk later what does it mean to be in this category then we have another category so it's this important class one products for important class one products it could the the most important for us operating system. You know, Federa is operating system. There are things like uh web browsers, password managers, uh smart home devices and uh similar things. The thing about these category is in the first category you need to comply with so-called essential requirements. Some you know like basic requirements what every product should you know uh comply with. in this category you will you know need to comply to so-called vertical standard so I'm in a group in Etsy who's writing these standards and we are with Lucas and help of you know some other folks we are trying to define how operating system should behave from security perspective uh then another category is you know important category class two so here you can have you know uh firewalls hypervisors like KVM M in our case and so on. Again, these products needs to comply with the vertical standard written for this no vertical. However, the attestation or not attestation, the compliance needs to be done through a third party so-called notified bodies. So, you have to pay money to someone who will you know go through your product and then we'll give you give it a stamp. And the last one and hopefully uh nothing for us in you know software world but for some people let's say in hardware with smart cards and things like that there is this no critical category. I actually don't think it's possible to be compliant with this critical category because it requires so-called EUCC common criteria like uh framework in Europe that's completely incompatible with CRA. So good luck guys with products in critical category. I don't know what you will do but basically you will not be able to place your products in in the EU. Okay. And why we are talking about this? So yes, we are open source. Uh for open source, CRA is basically essentially no op. However, yes, we care about these categories. Uh it counts. I told you about these standards. So we will be affected in some or other way through the standards. Again, I will repeat myself. Open source community cares. So for example on these you know standard scores for operating system it's us from let's say redhead fedoral word there is a lady from Debian uh people from sus so that's amazing because we care in open source community and yeah so what does it mean from compliance basically I try you know to put it in you know like nice picture so these you know CRA invaders Basically the idea is like you want to shield yourself as much as possible from all regulators that you know may come to you and ask you know stupid questions you know why you know did you do this and that. So there are multiple levels you know and I call it layered CRA security because uh there are multiple ways how you can achieve the compliance. So the most essential part are so-called essential requirements. Basically things that are written in legislation you can you know go to European Union website and download the text and you will see it in the annex in so-called NX1 and it's uh written there how you should you know like uh you can you can ask me later you know what are the essential requirements then there is something that's called module H. Module H will theoretically you know give you assumption of conformity for everything you do by doing some process kind of audit of your company and uh then there are a few things like uh module A module A is for the self uh assessment for the default category uh open source attestations a big question you know in open source community because some projects you know believes that these attestations can be then sold to vendors you know and get some you know profit to open source word on the other hand some people like us are afraid that you know this will you know put liability under CRA back to open source and module B plus C is for the standards the click class two and EUCC is basically common criteria certification I told you about already okay so what else do we have yes what's out of scope So use of your own products basically you have your internal tooling you don't have to care about CRA you have a product that's under development so let's say alpha beta releases research whatever you are out of scope until you place this product in the final version the the GA version on the market then some products may be you know covered by some you know other you know legislations or regulations ations. So for example in the automotive industry uh they have their own safety related regulations but maybe you know infotainment might you know again fit under CRA so it's never you know super you know clear medical aviations whatever then software as a service out of scope for for CRA with one big big you know but it's so-called RDPS remote data processing solutions uh it's still being you know defined what RDPS means so stay tuned where is the annex art I believe you know written in Etsy that explains what remote data processing is and then the most important thing and again I will tell you again you can leave because for free and open source software if you do not place uh your open source project into the uh market and it's not a commercial activity. Again, another gray zone. What's commercial activity? Because you can imagine there are thousands of ways how you can you know monetize your open source projects or get uh funding whatever will talk about it later. So, and I don't know like uh area. Yes. So, these are the official CRA guides and FAQ by the European Commission. Uh as for the so-called CRA guidelines, these were promised to be available uh early summer. Just today I heard it's not going to be early summer. It's going to be more like the Septemberish time frame because European Union was surprised. But so how many comments they received and it was like two two over 2,000 institutions, organizations, companies and foundations responded with very thorough feedback on this guidance. So yeah, it will take probably some time. There will be another round of reviews because substantial changes are going to be made in this guidance. Okay. Now these are you know these things you know you can you know expect to receive as open source maintainer over time from your friendly manufacturers who didn't read the regulation and they don't understand that you are not regulated by CRA as open source projects. Uh yeah these are is like uh requests queries uh surveys how you know uh manufacturers are trying to do their due diligence with the open source projects and how you comply with CRA that you should provide the proof of compliance with CRA. Uh it's actually interesting that recently you know one friendly open source project reached us to us with Roman and they said hey we received this question coming from European Union if we open source one European Union agency very known one the security one if we are compliant with CRA it's like so if even the European Union agencies do not know what's written in the regulation that open source projects are not in scope of this regulation you can expect, you know, more vendors, you know, coming to you and sending you this, you know, crazy emails asking for proof of compliance. Yeah. So, and very often like impossible timelines, you know, asking for information that you don't have to provide. So, yeah, what does it say? It's simple. Opensource maintainers owe you nothing. If you are open source project you don't monetize it you can always you know respond sorry I don't care but we will later talk about in this talk that we care we should care and we should you know be very you know cloud sorry very loud and show this to the world that opensource cares about security open source cares about resiliency okay and uh now we'll be talk a little bit about the important roles in CRA the are using this terminology through this you know talk and uh uh so yeah manufacturers manufacturers are the natural or legal person who develops the PD basically we call these people vendors up until now so now we use this no longer um term so these will have most obligations like 99% of obligations will go to manufacturer ers they will have the liability all the fines showing the the compliance to several bodies. So they are so-called market surveillance authorities that will be established in all 27 member states of the European Union. So you can imagine that uh each country may have a little bit you know different requirements you know on you as a manufacturer. Then uh European Union they are actually know governed by smart guys and they know if you you know put obligations to manufacturers someone will say hey we are just importers we don't care or we are just distributor we don't care so under this you know new legislative framework it actually you know goes down to the user so if your manufacturer will say I'm not reliable then distributor is if distributor will say importer is if importer will say know even you as a you users can be ultimately responsive. Nobody will you know go to your doors and knock but uh it's like a way you know to disallow all workarounds like we don't want to do something uh interesting call the first one of the first calls about CRA was uh representative from one you know cell phone smartphones company he said and what if we will you know ship our phones without any software to European Union are we still you know under these you know manufacturers obligations Well, first you know try to sell your phones without any software. I think you know users wouldn't be very happy you know to you know receive a box with nothing but also once you know put a bootloader that will just you know load that you know operating system you are under CRA sorry guys and then you know anothers are you know the developers contributors and maintainers to open source projects again out of scope unless you monetize it. And now I will you know let Roman talk about the most important uh one from you know Federa perspective and is the open source stewards. Thank you. Now there is another role uh is open source software steward. It's actually the first time when we see uh this kind of role included in the regulation worldwide. This is novel thing and opensource software too are those who provide sustained support for open source projects but uh not a manufacturer. You can think about the foundations like Linux Foundation, Eclipse, Apache and Python and and others but also there are big companies uh like uh our company um I'll be talking about later but examples but also the Google for Android and etc etc. So those who actually support open source software um which is not monetized directly to put it in a simple picture uh let's see so then in our case Red Hat is manufacturer uh for Red Hat Enterprise Linux which is operating system we sell for money uh on the European market to our customers and partners. So we are a manufacturer. Now there is um a Linux kernel right which is under the stewardship of the Linux foundation. They don't sell Linux kernel but they do care about it right they support this. So there's Steuart um and Fedora and CentOS interesting uh for today's discussion because Red Hat is going to be a steward for uh these projects um as well because we don't monetize them, we don't take money but we do support them, right? So this is how uh all of these uh open source related roles uh all on the one picture and as you can imagine the supply chain could be super long, right? about all of these things. Um, talking about the maintainers, ylav pointed very well that you know maintainers owe you nothing. Uh, and that we need to preserve and that we need to cultivate and spread awareness of. Uh, we still don't have the official um things about the minization. But this is the simple diagram that's um supposed to be uh true. Uh, you can read it from uh left to right starting. Okay. If you're contributing to to the projects that you don't maintain like you work for the company or you're just individual contributor you're out of scope whatever like whatever happening with projects you're not affected. If you are maintainer and um you do not take money for anything at all you're out of scope whatever happening with the project. uh if you're a maintainer and accept some donations that's covering the actual costs uh you're also out of scope completely. Even if uh you charge for support for some services or data you can be in scope. You still can be out of scope but this is kind of the indication that you might be in scope. If everything else you at least as a individual uh you have no obligations not at all. Now a few indications as we see now from the implementation acts from guidance and from the CRA text itself those are indicators of non-commercial activity right like uh developing force without monetization or uh receiving donation that cover the actual costs uh or being employed to contribute uh to contribute code to a false project if you just work for the company uh publishing open source repos. uh even if you do paid support for projects that you don't monetize but only provide the services but there's some caveats you still supposed to be out of scope as you're not a manufacturer you not place the product on the market itself now those are indicators how you can be treated as a manufacturer and I think that um will be helpful for uh all of us here in the room who connected to open source who contributors and maintainer what to watch out right uh charging a price for the software definitely placement on the market monetizing via the platforms like if you build some platforms around it it's also uh monetization requiring personal data processing also explicitly mentioned the CRA as in scope if you process personal data and even if you don't take money for it donations exceeds the actual cost of living of development of how they call it fair renumeration in the area that you live in um if it's exceeded it could be treated as a taking profit uh beyond the actual costs and the last one is very uh actually nice one uh it is charging for security updates one of the CRA requirement is providing security updates free of charge for five years uh for the projects uh since it's uh placed on the market with some of the exceptions and nuances but the general rule is here and if you charge for security updates that could be treated as the um also in scope as a CRA because it's essential requirement and if you charge for essential requirement you're supposed to be like manufacturer so the full obligations may be applicable to you so this is what to watch out >> I will summarize it in this way if you buy forkswagen from your open source contributions you are okay if you buy Ferrari you are probably not okay [laughter] [gasps] >> well this unfortunate I want to drive Ferrari at some point Okay. Um now, uh those are the questions that I personally frequently asked and a lot of other uh folks around asking am I subject to CRA if I earn a living from the open source project? Right? Can a solemn maintainer be considered as somebody else like a steward and therefore have some obligations? Does the popularity of my open source project expose me to Siri regulation? say I mean my project is super popular and how did Daniel call it like in billion devices installed worldwide am I automatically in scope because I'm super important guy um how can I clear communicate I'm not subject to see what exactly I I need to do to let others know those who uh who harassing me right those manufacturers and other companies and so on and so forth and I would say you're not alone with these questions I also asked these questions. A lot of folks also asking these questions and one of the avenue where we actually get answers to these questions is the Eclipse uh ORC working group. Uh it's ORC. That's why this little ORC picture over here. You can you can join you can check out the F FAQ. There are some of the questions already answered uh by the best with the best knowledge of the community. But also you can contribute with your questions and ask this questions so to get uh answers. So you're not alone on this journey. Why Red Hat? Um I I'm I must include this slide because again why why why we red hats talking about this and investing actually into the CRA and security and everything. First and foremost because we're manufacturer we sell our software for money in the EU. So we are in scope. Then we are open source software steward uh for Fedora including but also for a number of other projects. We support them. We sub substantially support them. And now Red Hartters like many of us here are contributors to uh the open source projects, right? So we kind of affected uh by it and therefore we decided not to uh kind of sit at the sidelines but lead these activities in open source communities but also in EU standardization bodies like Yslaf, myself and a couple of others included into standardization efforts and talk directly to uh the commission and to other authorities to make sure uh the open source ecosystem is kind of healthy right and we have a good uh a good practice This is included into these guidances. Now going a little bit deeper into the steward and why we're here talking to Fedora community about this. The stewardship is not really a choice, right? Um when we thought about that okay you know you can be steward you cannot be steward but uh if you read the definition um it is the matter of providing the substantial support which could be technical which could be non-technical but if you do all of these things you are falling under definition of the steward. Therefore redot is a steward for Fedora specifically because we do all of these things as the company. Now um Ysloff mentions that the almost all the MA obligations are for manufacturers for the commercial activity uh and all the fines for manufacturers. The stewards have some obligations uh and they have so-called slight touch regime. they supposed not not supposed to be fines for Steuart but it's kind of overruled now or attempting to be overruled by some individual countries but um but they have significantly less obligations which is true and there are essentially the five of them here on the slide uh implement cyber security policy encourage secure development practices for open source projects they are stewarding then cooperate with authorities and the most important piece uh as report actively exploited vulnerabilities and severe incidents to Anisa cyber security agency for Europe and local sea sorts in uh AU countries they are operating so those applications are on the manufacturers but um we need your help that's why we're here that's why we're talking to you to Fedora community uh because Red Hat yes is a steward for Fedora and we of course committed to ensure sustainability and help the project move forward with the best security practices essentially because the CRA as you can as you will see on the next couple of slides is all about the good practices uh at the end of the day full compliance follows downstream and on the downstream commercial products in our case such as rail uh and this is covered by us as a manufacturer but Fedora is different right and we need to work together to make sure we do right things and meaningful things therefore or we are introducing uh six uh Red Hat stewardship principles, right? And this week we released the CRA uh stewardship guide book or play or playbook. You can access it freely and openly. This is a rather big document outlining how we approach the stewardship, what we think, how we work with communities. But in essence, there are six principles as you can see on the slides. We understand that all communities are different and we just can't and you know it's it's unnatural right to say you know we are red heart we need to put the hammer down. This is not the approach that we're taking. We listen first and duck second. We prioritize security first improvements over the some of the paperwork and checkbox and exercise which may need to be done but still security first is the main goal. Developer centric approach because otherwise it's not going to work. uh minimizing disruption for the current operations. Yes, we have this timeline that Yas alluded to, but we need to make sure that we're not disrupting right in at the same time. Uh we Red Hat committed to provide gap feeling support for those practices that may be missing with our guidance, advice, resources and whatnot and diversity of course. We wanted to approach all the communities on your terms, right? And work within your frameworks and etc. for some of the communities, Fedora included, uh we take the champion stewardship approach because we think that Fedora uh that's the whole world is running on Fedora, right? It's like arguably the was one of the importance uh piece of open source software out there, isn't it? So that's why it's super important to keep it running and to keep it robust, high quality and etc. That's why we are taking extra steps and giving and taking extra investments from our company to support uh open source projects like Fedora. Uh now we realize that the uh partnership is the only way to go. As I as I mentioned we are approaching different uh upstream communities uh that we are steward for Fedora included. You can check this is all the public um the public uh issues that are happening discussions about the Fedora stewardship and we outlined our proposal and we actually come with the proposals and with a few options uh provoking you guys to kind of uh comment on that and actually say you know that makes sense or doesn't make sense or something need to change and you know throw some ideas how we can approach all of these things. So that's all transparency uh and nothing else. And we do it for Fedora, we do it for RNAible and for a number of other projects in the same way, right? We we're not putting the hammer down again. We talking with the communities and we committed to do so as we move forward. Um now guidelines for projects. I mentions that we have our guide book what exactly um we kind of need to do to approach the CRA readiness and I hate to call them requirements because compliance is boring security is exciting for me but I'm strange person right I'm doing security for 21 year and still like it it's kind of not normal so um but what exactly uh we need to do and again it's outlined in our stewardship playbook but in the nutshell First of all the that we call light requirements or bare minimum requirements uh coming out of the CRA that we need to implement. Um this is security policy and security MD file as the excerpt or the short expression of the security policy for discoverability purpose and also to communicate to whole world that probably uh who wanted to report about vulnerabilities or connect fedora on the security issues. It should be clearly stated in the repos within the discoverable file, short and concise and the rules, right? Also, this is important to shield actually Fedora maintainers from some of the necessary reports. So, this this uh file contains the the short like how to report vulnerabilities, how to interact, what we as a community care and what we not so that we we are not obligated to react to to everything but to only things that's important. Now some of the policies uh we need to also figure out and the good news is Fedora is doing a tremendous job with the documentation already in place for some of the security practices. We need some help just to adjust it to the kind of CRA uh sense and language to some extent but in the in the nutshell uh it should be all very nice. So incident response uh because we as a red hat need to um need to report all these things actively exploitative businesses and sever incidents to Ana. So we need this uh to be done. Now other practices included just a good security practices which is kind of makes sense. I keep saying that the CRA actually did not invent anything brand new uh in security maybe besides the C marking for software. If you can pull out your phone or your laptop or a pin printer if it's made in Europe, it's a little C like sticker on it. We yet to understand how to get the stickers to software right [laughter] now. But everything else is actually just a good security practices, right? Sbombs, you know, release documentations, branch protection if you, you know, you don't want it to release straight away to a domain without review, right? I mean there a lot of issues uh a lot of this license files and sign in commits may be an option etc etc. the good security practices, how uh engineering practices, right? How um how security should be done uh for the projects and yes, Red Hat takes care of reporting to Anisa uh and reporting starts almost now. [sighs] Uh now open source maintainers uh I want to talk about this uh for one minute. Um so as we mentioned open source maintainers have no obligations but if what if I want uh my project to be widely adopted and to implement all of these security practices how can voluntarily do this job and there are number of things that you might look at first of all this is so-called openness of security baseline which is basically the framework uh around the security practices that I just mentioned as an examples like branch protection CI/CD hardening sbombs enable you your dependabot if you can and etc etc I mean all these things that you may think uh of that just good engineering practices and they're spanning all the domains actually it's not only about security but also it's documentation clear it is quality uh on the high level and etc etc um another thing is the maintainers guideline that we uh helped to create and then donated to uh Linux foundation open SSF that outlines finds basically the short excerpts of these uh practices related to the CRA. Now, how to react? We promise you a little bit to um if you're a maintainer, you can receive uh these nice emails like airslaught exemplified like hey you know you're my supplier can you provide me uh you know the questioner uh or whatever. So um all of these questions um our suggestion would be to uh first try to consider it as an opportunity. Of course, you always have the default option not to respond or kind of uh respond to being an ugly person. But take it as a collaboration, right? You can um for example um ask question like okay what I can get of it how can and express how they can help you but maintain uh autonomy. So you have no obligations to accept whatever even some company to be in a steward if you're a maintainer of the just open source projects right and somebody reach out to you and say you know you must join now uh us uh gentle response right as an example uh I am not your supplier uh and this is by this link this is an example of exact like legalish text how it responds with a linkage to the CRA uh to the CRA points I'm not your supplier. I have no obligations with a uh citation of certain paragraphs from the law itself. Um so all what we do is actually upstream uh what I talking about the good practices and etc. You may think okay this is Red Hat inventing something that doesn't make sense that doesn't work for for us. We take all reasonable steps among other peers in the community among other companies to make sure we don't invent something that is not working for a community. We work with the uh different communities. The first is Eclipse Orc. I already talk about this. The second one is Linux foundation open SSF um um global cyber policy working group. We also discuss all these questions and try to make sure that there are tools we can collaborate on for open source projects and for manufacturers being helpful to achieve the CRA readiness. And finally, we ourselves leading uh or trying to lead by example to rolling out publicly our intention and our um our our good practices that we think could be helpful to the community. Um and yes, um thank you. And just just to give you uh a one last picture about how it's supposed to work, this is actually the famous cheese picture uh invented by the commission to represent kind of the sense of the CRA to finally fix these holes in the supply chain, right? And how it's supposed to work uh to reiterate, right? Um so we uh ah it's supposed to work but it's not. Can you help me to uh advance a little bit? Okay. Yes. So the manufacturers sell the PD to customers, right? And then uh the vulnerability found in the um in the product, right? In the commercial product. Quite obviously all the commercial products are dependent on the open source projects. And the intention is how we can let manufacturers all of these commercial companies to be responsible citizens of open source ecosystem and actually provide the fixes to open source projects. Now it's written in the CRA actually if manufacturers finds vulnerability that affects open source projects they must report back to the community. And now you can imagine that those guys are dependent on thousands of open source projects because all worlds runs on open source projects right and that's why there's uh institution of stewards introduced in the uh in the law right to help kind of being a proxy between the uh the manufacturers and open source projects. So and all are happy at the end of the day. So that's the whole intention of the of the law takeaways. Um I think this picture represents the takeaways that we tried to to deliver at today's talk. Uh but to be more precise um quality and compliance is is in the picture right the CRA is a bridge um to this good security posture right and you know we want to uh Fedora as the uh best Linux distribution ever to be you know at a good quality and a good uh posture eventually um awareness right security is it peak visibility right now uh that I call now post mythos era we are entering right so it's super important vital for Fedora and its users I'm pretty much sure community first as I mentioned our approach is to be community first we need your help to figure out how to do it better [snorts] and finally uh the voice matters join our communities if you think that you know all of these uh officials they don't listen they do they quite overwhelmed by responses but they listen so we need your help to join us to amplify the boys to join in the working groups that I'm just uh showed uh to you and help to do it better uh then you know it's probably written on the paper and opportunities now right it is now it is not tomorrow it is now okay uh I think we may have some time for questions but that's what we Uh, hi. So, like a few slides ago, you said that well, as an open-source maintainer, like I'm in under no obligation to accept someone as my steward. And that immediately popped a question in my mind like is there some possible risk in me like accepting some random person as a or random corporation as a steward would >> I can try to handle it as I two right >> is it working? >> Yes. >> Okay. So this is kind of two-way street on the on the one hand from the from the maintainers perspective you you owe nothing to anybody right from the uh corporate perspective uh this is the definition of the steward and if corporation provides some of the sustained support you know they are steward but your question more about okay I'm small open source projects and some of the big foundations for instance like Eclipse Apache something reach out to me and say you know I want to be your steward because I think your project fits well to my overall ecosystem. You have again the uh full you know ability to say no. Uh the risks to join um are are not the CRA risks I would say because again this is uh a limited liability even for for stewards and the projects in their in their portfolio. The risks would be to my perspective uh in the line of the governance. How much you will need to to give powers about your project to these foundations which is more and less nothing to do with the CRA. Therefore, I would suggest to assess this nicely and then ask the questions what I get in the return, right? What support I get in the return. So that's how I would uh respond. Yeah. So my question is from a open source project maintainer and developer employed by Red Hat. Does it change anything in the workflow whether I have to care about CRA or not? Like what if my project uh is open source but I am the sole maintainer and also what if I am just contributor to some project that is not uh maintained by redhead but suddenly will redhead become steward by default because I am contributing to that project. No, you you you you're you're good. Basically, as like let's say Redhead employed opensource developer, we from you know compliance team may come to you and ask you that we need to implement something in what you do to comply with the requirements. But this is purely manufacturers point of view. So we do it because you know we need it for our compliance. you as a contributor to open source you don't have to do anything it doesn't matter if you are employed by redhead or not you are perfectly okay unless you know I and my team will come to you and ask specifically this this is something that we need for CRA and then you can have you know two heads like your open source head and say hey I don't care because you know you don't pay me for this you know my personal project but if very likely you are paid you should probably, you know, do what you need because in the end it's your paycheck coming back from from Redhead and uh know European market is still pretty big and significant for every manufacturer to decide to leave it. >> Thank you. >> I guess my question is more practical like as someone who does packaging Fedora and in Fedora and who I guess is a policy maker now. what do you want from us or what do you expect us to do as part of this process? >> Yeah. Uh that's a perfect question. I think um I think the whole workshop yesterday was like to brainstorm what's really uh kind of can get from the partnership and what we want and the I'm just yes this one. So the one of the take away exactly this question. So first uh we need yeah open conversations which I think we all already got by opening up some tickets by uh communicating with different channels and etc. uh the next million more practical things uh first and foremost as I mentioned for the essential requirements that are you know must baseline we need together to work on the good uh cyber security policy to make sure we first align how we handle vulnerabilities and then how we communicate this process to the entire world uh in the documentation and etc. Then of course we're supposed to work on the process itself kind of aligning okay this is how we ingest reports this is how we react this is how we do all the things and this is how we put security MD file to which repos like in in all the packages or otherwise I mean this is all open questions that we I mean me personally as the person who who are not that familiar with the fedora I need to I need to collaborate on then there are going to be more technical things like asbombs and I do appreciate it's P URL discussion is already happening to include this uh package URLs um as a as an improvement to Fedora projects and then other security measures that I mentioned on some of my slides like uh salat stations. Do we need do we wanted to do this uh secure builds with the southside stations or are we sure that you know we are uh enabling uh multiffactor authentification to the platforms that we allow our maintainers with a big power to uh login and etc. So those practical steps that uh we want your help to kind of talk to us at least and then to brainstorm together on these uh items. Yeah, >> I will add one more thing. So yesterday we spent most of the time talking about this you know reporting obligations. So as a packager uh we you may be you know approached by the security team and asking you know for the vulnerability because for this know actively exploitable vulnerabilities there the reporting obligations are you need to prepare the initial report within 24 hours. So it's a pretty you know short time frame. So some people may you know approach you as manufacturer please you know help us or or sorry packager please you know help us to understand the impact of this you know vulnerability in Fedora. So yes this is something you know we we spent a lot of time yesterday on and uh we would be very like discuss it in more details. >> We are out of time. Thank you very much and sorry for my initials. >> One last from the very best person, Jeff. >> I can't refuse Jeff. >> I I have enough status to actually uh make the clock not important. Hi, I'm the Fedor project leader. Um, I will say if if you if you were in the talk right before lunch, Steph Walters talk about uh Fedora Hummingbird Linux, that is an opportunity to really nail down the specifics and minimize the burden on Fedora contributors because it takes such a CRA focused approach to all of these questions that if we get that into a sandbox and we can iterate on all of this inside of that scope, we can absolutely minimize the burden on existing contributors because we're doing net new work around all of these issues and it's t it's amazing coincidence timing that that's showing up. At the same time, we really have to focus on the CRA. So, I'm hopeful that all of that works out in a way that we are not burdening uh existing contributors at all and we can use that as a shakedown for all this process and get to the 24-hour requirement because Hummingbird's trying to do that. >> So, I'm hopeful. >> Thanks very much. >> [applause]