 I think it's time, which means I should probably start. So I'm going to talk a little bit about why Fedora needs a security team. My name is Hudefa. I am a principal software engineer with Z Hat. I am a part of Z Hat Product Security, which was formerly known as security-responsive. And now we are responsible for the security of products which Z Hat sells, which includes things like, you know, Vell and JBoss and stuff like that. I am a part of various upstream security teams. I have been involved with Mozilla, LibreOffice, PHP, Python, Samba, Exol, Apache, OpenSSL. I've been involved with the different security groups and security teams these upstream projects have. In various capacities, I have been contributing to Fedora in various ways. I used to do some infrastructure work long time back. I maintain around 28 security packages in Fedora right now. I speak a lot about open source and security at all conferences. So how many people have seen this news? I think this is like two weeks back or three weeks back. Recently Arch Linux was compromised. One of the user accounts was hacked and it seems that the attacker was able to commit to their repository and he was able to add a back door to the accurate package which they have. And luckily it seems it did not spread a lot. Someone noticed that, you know, the checksum is a little bit different. The back door was not very intelligent. What the back door basically did was it tried to collect machine information like username and the version of the kernel which is running and stuff like that. But basically bad things could happen. So I spoke with one of my colleagues and what he has done is he has made a document which lists all the various distros which have been compromised in the last 10 years. And the document contains like 50 or 60 different incidents. And it basically tells us that just because you have an open source distribution it does not mean that you are immune to these kinds of security incidents. So that brings me back to the question which I had. Why does Fedora need a security team? And a lot of people would say that doesn't Fedora already have a security team? So if you click on these links, I think around five or six years back a couple of my colleagues and some of the contributors they decided to form a security team and if you read one of these wiki ppgs, I think around 15 odd people signed up which included myself and out of that I think three or four decided to really contribute. The kind of contribution which these guys normally did was ping package maintainers on IRC or email or some kind of thing and asked them to patch security bugs. And a lot of times package maintainers say that I am busy today, I will do it tomorrow. This week I have some project I am working on and I won't be able to do it. Probably I will do it next month or I will do it month after that. And this is really a thankless job because if you are a technical contributor all you are doing is you are pinging people and you are asking them to patch their packages. So it started with a lot of enthusiasm. I think weekly meetings if I am not wrong they had weekly meetings for a couple of years and then people started backing out because it was not really exciting thing to do. The current state is it's not really a functional team, they only exist on the wiki. They don't have meetings for the last one year or one and a half year if I remember correctly I think Jared was involved as well. They don't have meetings at all and I am not sure if anybody is really functional. What I really want to do is I want to reboot the Fedora security team. When I say reboot it doesn't mean that we do what we previously used to do. I don't want to do the dumb job of pinging people on RRC and telling them why don't you patch CCVE because people normally don't respond. As I said contributors quickly lost interest because there are a lot of technical people on the team and technical people are not really good with people skills. So the current stress is slightly distressing. I think yesterday I ran a report on Fedora bug-bugzilla on the CV bugs which are open against Fedora bug-bugzilla and I think I saw 993. So the current version of Fedora which we have suffers from 993 security flaws and I think out of that 13 or 14 are against image magic. So the state right now is a little bit distressing. I am sure at least 10 or 20% of those CV flaws cannot be fixed or it was already fixed because we revealed the package but the package maintainer was probably too lazy or he did not have any time to probably close the CV or whatever. Currently we have 993 CV flaws which are open against packages in Fedora. So what my suggestion is and what I really want to do at this point is do something which is more exciting than as I said pinging people on RRC. The first thing which I want to do is security scan packages on entry. So we currently have a solid package review process and when I talk with my colleagues at Z Hat I normally tell them that Z Hat has got a lot to learn from the package review process which Fedora has. Our process is not even 10% of the package review process which Fedora has. So we have an excellent package review process. What is missing though is try to see if we can integrate some kind of automated security scan on the Fedora package review project and I am going to talk a little bit about that because we are doing some work on this at Z Hat as well. One more thing which I propose to Fesco I think a couple of weeks back and they are still discussing is trying to figure out if they can be a package exit process as well. And I am going to talk a little bit about that as well. Third thing is try to have a mechanism to see if it is possible to scan commits. So one thing very difficult in Fedora is to get a new package inside the distribution because you need to go through the review process and things like that. But like my colleagues in security now normally say we are hard on the outside but we are soft and mushy on the inside. What it basically means that once you get a package inside Fedora, once I have commit access if I am a proven packageer then I basically have access to any of the packages. It is very easy for me to introduce a back door. So I went to one of the security conferences I think last year or year before that and I spoke with this person and I told him that I am a Fedora contributor and he asked me if I have, he asked me if I have proven package access and I told him that I do have and then he tells me that would I be willing to introduce a back door in some of the Fedora packages because I have proven package access. So it is not impossible. It may be a little bit difficult. So it may not be impossible. There are a lot of companies. So I talked with a lot of Google security researchers. Google has this mechanism in which whatever commit you make to the Chromium depository there is a heuristic script which runs at the back end probably as one of the githubes and the heuristic script tries to figure out if you are doing something malicious or not. So I don't have access to the code which actually does it but they are probably looking at key keywords or your code writing mechanism or whatever. So these are the three things which I really want to introduce now. So that had basically uses the Fedora package interview project internally. So this is a project which I started around two or three months back. We have forked the Fedora package interview process internally. We do a lot of security scanning with Fedora package interview project. We are still writing a lot of code. The code is not good enough to be sent back to upstream but we are still working on it. What I really want to do is probably six months down the line make sure the code is good enough and try to send it upstream to Fedora project or Fedora package interview project. There are a lot of things which you can do for free. The first thing which you can do is you can scan the NIST CVE depository. So NIST maintains a depository of all the CVE issues which it has assigned. So if a person wants to introduce a new package in Fedora what you can do is you can take the package name and you can do a grep against the XML which they have and see if there are any CVs which are opened. If there are any CVs which are opened then the package maintainer is required to fix those CVs first before we actually go and introduce that package in Fedora. You can run a lot of static analyzers which are available free of cost and they are open source. It can be done for free as well. You can use ZHAT XML RPC infrastructure to query if there are any open bugs against that particular package in ZHAT or if there are any open bugs in Debian or if there are any open bugs against open Sususuzhe. This is something which ZHAT product security does internally. So when we have a new package we check if the Debian bugzilla, open Sususuzhe, bugzilla if any of these distribution bugzillas has any open security issues and if there are any then we ask the maintainers to fix them first. So there are a lot of things which you can do. One thing very important over here is not all package reviewers are technical enough to know security so we want to ensure that this can be automated and when you run the Fedora package review tool that will tell you that this particular package which you are trying to review has got three CVs which are opened against it. And this is the link to where you can find the patches and please ask the person who wants to introduce this package to first fix all of these CV issues. So this is one thing which is missing a lot. I have noticed a couple of packages which were introduced and they had open security issues which is really really bad. So like I said if any open security issues are found then we ask the maintainers to fix them first before we are able to introduce that package in Fedora. Package exit. This is the link of the FaceFaceCo proposal which I introduced. There has been a lot of discussion on Fedora Devil as well. A lot of people have made me personally as well. Some of these people are offensive as well. I am not sure why. So I wrote that I am disturbed by the large amount of packages which Fedora has. I think the last talk which I went to Paul just said that we have 21,000 plus packages in Fedora. And this guy made me back saying that why are you not disturbed about obsolete versions of PHP and Bash and stuff which you have in there. So there are a few people which are offensive as well but basically what I want to do is I find a lot of package maintainers are package maintainers in Fedora because they have a university project to do or they have interest in astronomy or they have interest in something and they want to introduce their package into Fedora and a lot of these package maintainers live say in six months or one year or two years or something like that their project is done or they are no longer interested or their job pressure is too much. So a lot of package maintainers live. And I have noticed that the package will keep on building in the next versions of Fedora. So I mean there is an automated rebuild against F27 and F28 and F29 and so on and so forth. Though the package maintainer is no longer a contributor or is probably dead or whatever. So that keeps on happening a lot. And what basically happens is that the CDE issues which were filed against that particular package some time back they used to be closed because the distribution is end of life. They are no longer close now. They are carried over to the next version of Fedora but in the end we end up with a lot of CDE issues against a particular package. So there has been a lot of discussion on this my initial proposal was to wait for two release cycles like you know if there are a lot of CDE against Fedora X we wait till Fedora X plus 2. We probably try to have a way in which we can ping the maintainer probably do it in an automated way and if the maintainer does not respond then we try to exit the package by using FTBS. So a similar process to what FTBS has as the maintainer can always reintroduce the package back like you know if you are on some vacation for one year or something like that when you are back you see that your package has been removed you can always try to fix these issues and get the package back. My proposal also included having a list of critical RPMs which cannot be removed like you know probably have RPM or DNF or one of these Bin Bin Utils or you know these RPMs which are really essential to the distribution like if you remove them from the distribution then Fedora wouldn't build so I have a list of critical RPMs which cannot be removed I was thinking about you know what to do with these RPMs like image magic right so I think last I checked image magic had some 53 security issues out of that I think only 12 are currently open but image magic is usually a package which has got like 100 CDs in a year or something like that and a lot of people in Fedora surprisingly use image magic a lot right so we can probably have a gray list of RPMs which like you know which cannot be removed because people use it a lot but we published a gray list on the Wiki saying that these RPMs has got a lot of security issues so you know we have not removed them from Fedora but if you really want to use it then you know please use it on your own and yeah I don't think I have anything more so those are the things which I really wanted to talk about a lot of these things are in process right now like you know the Fesco ticket yes so a couple things one the Fedora security list it's been completely dead there was an email in March of this year and I think it was a year before that was the last email I had it's not happening I think everything you bring up here is some great ideas but there's perhaps even ways we can take it further if we decide to really reboot Fedora security to be what it should be these are all great products but I wouldn't change any of them I think they're great but we also have the way that this ticket is run now I'm impatient we have the ability to instead of harassing somebody and saying hey fix your CV I mean they should just see the bug and fix it that's not happening instead of harassing them we could actually just do a pull request in their package we file a pull request and then you could actually then have an automated script that goes through and checks all the pull request and if it's not merged within a week two weeks whatever then a proven package could actually just go in and do the merge themselves and rebuild and get rid of that issue the issue of packages where the maintainer is gone and it's kind of ridiculous to have a proven package or having to continuously basically they're taking out maintenance on that product so there would be a way to report if the version is completely out of date if we've got package X version Y and they're on version Z point whatever upstream that's under the bump that's a problem right so maybe we do want to drop the package but it's a way that we could hopefully close a lot of the security bugs without you know with the maintainers who are not willing to do the work themselves right I think the big chunk of problem over here is a lot of these CV issues are related not only it's a lot of these CV issues don't have patches which are directly applicable I think the ones which I was talking about a lot of them are a little bit more complicated than trying to backboard the patch from upstream or trying to re-base the package a lot of these PHP packages for example like the sub packages which PHP or Ruby gems they required a little bit of more technical and component know-how to try to figure out if this CV issue does really affect the way PHP works in Fedora or the way PHP works or the way Ruby gems works in Fedora because what product security basically does is we file a bug against Fedora but I'm not sure if they have enough time to you know probably look at how the version of PHP in Fedora is different from Zell and you know whether this one would really affect or not Right on the kernel side we get the same thing we get in fact there was one today that was, or yesterday there was a bug it was fixed in 4.148 we fixed it a long time ago that's great I sort of get the notification and look and say yes we're covered then not getting a notification at all but I mean there's for the ones that can be so let's say we get rid of 300 of those 900 and something I mean that still puts us in a better position right Definitely though I think the wiki says that you know it's the responsibility of the package maintainer to patch the security flaws probably you know if the package maintainer is away on vacation or you know he's probably not well or he's too busy then you know he can probably try doing that but in my opinion it should not give a false it should not give a false signal to package maintainer that you know if you don't fix your security flaws we will do it which is very important in my opinion yeah I mean plus if the package is really really important like if it is open SSL or if it is new TLS or something like that which is a really really important package and you know it really needs to be fixed then you know we can have someone from proven packages but I have seen a lot of these CVEs which are open against games which we have Yeah Would it make sense to somehow label packages with open and known CVEs in Pakistan in software management tools such as Chrome software or DNF or something so you are trying to update system and it tells you you have those packages on your system installed and there are known CVEs for them just to create the pressure for the package maintainer or just that people actually see it that this package is broken In my opinion that probably needs a lot of work so I was thinking of doing something like this for the grey grailist packages which I was talking about like image magic and stuff like that which has a lot of CVEs open but people still use it a lot so probably it would be easier to list those packages on the wiki saying that you know this is the list of unsafe or uninsured packages Yeah but nobody reads that though Yes definitely, definitely What if we did it so I mean it is a simple query in bugzilla to find the CVE and even some non-CVE security bugs they are all tagged with security right so it is a fairly simple query What about publishing that list with package owner and package and you publish that list say once a month Yes because to finordabelle places like that and so that way people can see and hopefully there is a little bit of public shaming there to the point of if your name and those CVEs have been on that list for five or six months you know people might start to give you a hard time too and there is some peer pressure there I mean that can be automated where you just run the script and send the output to the list So one small sub-project which I wanted to do is we have this internal dashboard in product security which we use which will tell me what are the different bugs which I have in my queue So one internal thing which I wanted to do is to have a dashboard kind of thing which feeds its data from the bugzilla quickly right and the dashboard tells you that against which distribution you have how many critical, important moderate and low flow which are open right that's not only going to put pressure on the maintainer but it's going to put a pressure on people also like probably fesco or you know what I was saying that Fedora 28 has got say five critical and 28 important issues and you know people start asking questions like you know why these issues are not being fixed and then when you click on the graph it will tell you against which component it probably goes to a sub-page and it tells you against which component how many issues are open and which maintainer has the worst record of trying to address the security probably this is a sub-sub-project which I wanted to do but I did not bring up over here because it was not that big enough and it's not very difficult right I mean you read data from bugzilla and you parse it and you know you make a graph of stuff it's not very difficult there is a community aspect and you know people don't want to to be seen as the guy who doesn't address security right and package maintainers who are showing up in a monthly email too and I don't think it needs to be more frequently than monthly but you know people are showing up there consistently maybe they'll get some peer pressure to all of a sudden fix them whether it's on the maintainer or it's on the upstreams because I've seen myself several upstreams who have not been updated for 10 years in tournaments and you have a package it has CVs but as a maintainer what will they do will they take over, maintainers with packets sure they can of course you can but you will not do nobody did well why should I maintain a package that has upstreams that's been there for 10 years what's the value I asked the same person they asked me because I'm only using Fedora they should it's not the policy of Fedora to remove these packages it's not such a process or guideline and that's what part of what the Pesco ticket asks but part of it is if I'm a maintainer of this package to care about it enough I should, if nobody else is going to fix it I mean clearly somebody published a CD so somebody is researching it should be able to I go fix it and if I can't go fix it then you might close the bug as won't fix and here's one I've got a list of kernel bugs right now because the first thing I do every morning is check the kernel CD it's also the last thing I do before there's 20 some on kernel bugs right now there's one researcher who's been going through and they're all a crafted file system of this if you might have well either you've got root or you've got physical access to USB so they're really a little priority issues and the one, I mean all the major file systems have been fixed but there's like HFS there's J2FS things like that when somebody gets through them then I'll push them but if someone wants to ask me the status of the CD I can tell them the status of the CD and if the CD is not a huge deal then the maintainer of this old package should be able to say well I can't fix this but I can tell you it's not a huge deal and perhaps market as such in the bug and closes won't fix and at least then if somebody's looking they can see alright this CD was here this is the package maintainer's response and it's been closed at least we know it's been seen and addressed in some way one of the main things from the 993 CDs which I looked at I think 10% of them were already addressed but they were not closed I don't know why they were not closed around 20% of them were CDs which cannot be addressed like there is no upstream patch or the patch is too too inclusive or like you know somehow some of the reasons like that so all I ask for a maintainer is to update the bug saying that this is the reason why this particular CD cannot be addressed plus the policy proposal which I have basically has got different criteria for different security levels of the bug so if you have a critical bug which is open against your package for the last 3 months you probably remove it in X plus 1 if you have a low priority bug if you have 20 bugs then you keep it for X plus 2 but then if you have for 40 bugs then you probably want to really look at what is happening the proposal has got a different policy for a different number of bugs and you know it is probably open for discussion it may also really depend on the package which we really want to talk about like if it is open SSL probably a moderate level flaw is something which should be immediately fixed but if it is like PHP or something like that if it is a game then probably a moderate level flaw is something which we may want to hang around for 1 2 really cycle or 2 really cycle or something like that the policies make sense to me but I definitely wouldn't remove anything automatically I would just compose a list of candidates and bring it to Fesco I think it would be just like following the unresponsive maintainer process or similar to that whereas you file the bugs there has been no response then you file a request to remove there is no response from the maintainer for an individual but it takes too long that's okay well it's better than now let it take long because some of these packages have been sitting here for 6 years if it takes a month that's fine and Fesco does not need to review individual packages so you can kind of wait for but there are certain packages that have open CVE for ages and we still cannot remove them because just how important they are so those would be a part of the critical package set which cannot be removed but if the CVE has if the CVE has been sitting on it for so long probably it does make sense for the package maintainer to comment why the CVE has not been fixed why he cannot fix it that's what the public shaming email comes with and then hopefully they come in and fix it sometimes that's acceptable it can't be fixed for this reason and closed won't fix so then it no longer shows up as an open CVE but it's a why as you mentioned the exploit or the exploiting vector over here is not strong enough if you really need USB access or physical access to a machine if you have an exploit which is extremely difficult to pull it's something which we really don't want to fix the whole operating system model which we have right now is not based in a way that when we had meltdown in spectre there was a lot of a lot of you and cry but then when the next version of spectre came out when we had spectre to spectre feed people were not that interested because by that time they realized that this is not something exploiting or something like that it can be difficult to remotely exploit really it's more obviously we're closing those as quickly as we can but they're not really a concern for the fedora user because of what's required to set up that attack you have to be a serious target serious targets are running well they're not running fedora but we still close them as quickly well on monday anything we decided to to discuss it here but i'm the only one so maybe at the wrong table discussions i think tomorrow we'll be doing that so cbe's are one thing but it's with things like you should be configuration prior that maybe has some wrong things or maybe you label some tires in the wrong way or put it with the wrong access rights into the wrong directory this is not reviewed at the moment right doesn't the package the review tool figured out but the packaging reviews more like the functional thing and not like non-functional things like i think it ensures that the packaging standards are being followed if you install a file if the rp installs the file in the wrong place then i think the package the review tool does tell you that this file is being installed at the file system permissions are long so the process is not meant to cover this that is a good point if somebody introduces a package let's say it's running a listener service of some sort and that's like completely exposed to root by the default config or something there's nothing in the package review process that's going to say that so how do we audit fedora and bring up suggested changes this isn't a CD it's just a suggested config and change about the question i don't know how they answer to it but it's about the question yeah we see this a lot also with docker containers at the moment where we say okay we don't build a docker container on our own how can we be sure that all the communication that is going out and in from the container is really as it should be so it's the same thing actually so even if the software is free of any known flaws maybe the one who composed the container or built the package make some kind of mistake can happen to everyone of us here a review process would be very valuable we have a review process for packages but they focus more on functional level well in the theory is you trust the package but the reality behind it is a lot of times the packageer is a packageer and not a they're interested in actually pushing that out there but they're a packageer and they're not really a developer on it so they don't understand what they've done and there's nothing wrong with that other than if we had a way to audit it security that would be great yeah so when i spoke about introducing security reviews in the package or any tool i wanted to ensure that most of it is done in an automated way because security is hard right and packages reviews probably don't understand security well so like you know probably try to try to automate as much as the tool can and point of purchase and stuff like that but the thing was because you mentioned the thing you build a backdoor on your own into the packageer into the package this must not be or cannot be must not be related to a CDE or something like that maybe it's just some kind of a small backdoor that you write into the app though and that's maybe would be covered then well it might be good to write a basic tool that would scan scan open ports as a result of the package so you know it spins it up in a VM and once it started is it exposing anything you know check for security, security things like that and it's kind of like right now when you're in our PMLint it spits out a bunch of warnings and then errors well this just spits out as just kind of a warning hey this is opening up this port or this has these said UID said GID and as part of the review process you can say well they're just warnings and here's why they're there you explain why they're there or you don't they're just completely unaware at the moment it's not improved in the review process but it's a more difficult problem detecting a backdoor from what we are actually proposing something that can be done today detecting a backdoor is a much more complex problem but if you do it I think this sandboxing approach I think it's a good idea because then you don't have to analyze the static code or something like that you have just your black box and you see what is the black box doing I think that's passed away to find out is there something which does not behave compared to the last test as example I'm not sure if this is doable or how you do it within rel if you have something like this for your packages in rel rel process is a little bit more complicated because a lot of times we need code right so I mean if there is a really really important package which we need to introduce and it's a demon and it's probably running as root or you know some other user then the review process includes you know trying to read through each line of code and you know trying to see if something malicious is being done or you know run a fuzzle or something like that on that but this process is really difficult to do with Fedora because like each one of packages which we have plus second thing is each package reviewer may not be that technical enough to you know try to understand the nuances of the language like you know how big an int is and you know what will happen if there is an integer overflow and is there a potential heat buffer overflow you know all of the reviewers may not be that technical enough they may not have enough time as well to you know to try to go to each so we need to we need to ensure that at least the basic set of functional performance and most of those functionalities are automated and warnings which it gives are you know probably laying are in plain English so that you know the package reviewer will understand there is a place that actually we can do a lot of this that I hadn't thought about until just now so the CI process the one that's supposed to be getting everything and is turned off now but will eventually be turned back on the CI process could actually run a basic script because it is installing and testing that that RPM when it's built so it could run a script and say alright well that RPM is open these ports and you know it's got these you know it does the check and it just dumps it into it does the check as far as installing the RPM it doesn't necessarily start a day with everything well it should I mean doesn't yet it should but that's more complicated each package has its own test set that's right once once people run the test the problem is the same people that aren't going to be able to close their CDs that aren't going to run tests we have some people we have some people who are very interested in writing tests and putting full request in for those so if it's not any effort other than click a button then hopefully they'll get taken that's right I guess it is I apologize I don't know if you guys already talked about this but my two comments are not all CDs are created equal and some are obviously more important to fix than others and I would like from a Fesco perspective or my own personal take on what I think Fesco should do is I would love to see what are the top 10 or top 20 packages especially those that are in critical path that have high or critical CDs and let's start from the Fesco side pushing let's have a hit list of maybe it's the top 10 to begin with let's go through those and try to get those fixed fix the things like image magic that need a little love there's probably others in there as well but in the critical path that we need to fix and then we're going to add from the top home developers to work out from the bottom we were talking about doing a public shaming email to develop once a month as well with these packages with open TVs and that way when the same ones keep showing up month after month maybe they'll get some peer pressure can we make sure that those are that there's a list sorted by developers no reason not to not to make sure I did mine clean up I don't know about anybody else one other question I did have so you've talked about basically we want to reboot your security team where what's the process for actually rebooting this you've got great ideas that you want to implement but as far as I mean there's a mailing list that hasn't been used in a month we can apply that back up or we're going to go back to meetings what's the next step these three projects which I just described I want to use the mailing list to actually talk about those projects and see if there's really anybody that's interested like the ideas which you said we kind of send once in a month to say we work on this dashboard thing which I was trying to talk about so I want to use the mailing list as a forum to discuss things so the basic concept is to do things which are more interesting than trying to ping maintainer trying to patch trying to backcode patches and stuff like that to do a writing which are a little bit more interesting I am obviously waiting for Fesco to try to figure out if you really want to implement the package in this important process if there's something else which we really want to do but there really needs to be a way of trying to work with these packages which have like CV is open for five years or six years or something like that probably because upstream is there or the maintainer is no longer active or something like that I want wanted to do a distribution comparison as well so I don't have the figures right now but I was able to only finish Fedora, Debian and I think open Suze and I found that Debian has got the least number of open CVs which are open and open Suze is probably Fedora is probably one and a half times what we have in Fedora so Debian has got a really good security process and I am not sure what they do with packages which are which have open CVs but you know they really they are able to probably in some way they are really able to address the CV issues or close the bugs which cannot be addressed so I want to use the mailing list to start our discussion on you know what and once we have the packages which we can which product security can send back to upstream we want to see if these systems can be can be patched into Fedora's review and you know if package reviewers can start using the new package of Fedora's review to see if we can do security scans as well so that's what plus I want to remove names from the website for people who are probably no longer interested I think right now we have some 15 names or 20 names last I checked a lot of these guys are probably no longer interested so maybe we should remove names as well that's another great topic for the mailing list just say hey people who are interested reply to the mailing list if you are still interested in that the list is still there it just doesn't get posted too plus we are also internally trying to have a mechanism in which Embargoal security information can be transmitted confidentially to probably one or two members I'm not sure if it is supposed to include a Fesco member but probably we are trying to see if we can give a heads up saying that next week there is going to be a big issue so make sure that your billing structure is okay so that because we need to package in a few hours and make sure it is pushed to the depositories so in previous instances I think during heart bleed or shell shock I had to ping Dennis Gilmore and I had to tell him that there is this new open SSL package which is going to come in next 5 hours and make sure it goes to all the bidders in the next 2 hours and he used to tell me that this is not really how my manager works he probably did it well and he started to push he started a syn script and things like that but that's really a big problem and we had instances in which currently we used to do it for sentos much faster than we used to do it for Fefephi because the way our infrastructure is so we are going to soon have a mechanism in which we can give this information and under some kind of non disclosure agreement or something and make sure that infrastructure is ready for the packages to be built in deployments and stuff like that so there are a lot more smaller things which are happening in the backend as well I was thinking that when we have a list of open CVS for a package I think that the option would be before this package comes into the next fedora version thus bugs has either be closed as well as fixed or whatever and then we simply also see if the maintainer is really interested and continues to maintain this package or if someone else will take it out I think that's a great idea as long as we filter the CVS and say if they are higher critical if we get a trivial CVS that's not exploitable and it's very low risk it brings up the interesting point though of the packages where the maintainer has been gone for years and the package has been abandoned it just wasn't only abandoned so if we have that sort of a process say at branch point or right before branch point or whatever and say give us a response you do have the issue of you can't just pull packages that are depth for other packages it has to be at least now but that would at least give us a point to ping maintainers and say hey respond to this it won't get branched or if you don't respond it won't get branched now they can manually go create the branch but then there would be some sort of positive they've now said hey I'm maintaining this package right I think that's a great idea you can actually in the email get the instructions on how to manually create the branch if they missed it because people do go on vacation or whatever but that would be a great way to automatically weed out some things like that so that's why the proposal says that we want to remove it from X plus 2 right so if the issue is open against Fedora X we probably depending like you said depending upon the security impact of the flow if it's a low or something like that then we probably won't care a lot if it's a moderate or an important one we really want to make sure we fix it as soon as so that's why we wait for Fedora X plus 2 so like if the package maintainer is on vacation or he's not well or he's really busy or something like that probably 2 the least cycle should be more than enough time for him to either respond by saying that you know I am going to fix or I don't care or I'm no longer a contributor or something like that but if that process is affected to the critical path or to not in the critical path or to link packages then the most important package you would actually continue because the most important are the but the most important packages are the ones who actually probably have maintainers they're just not addressing the CVE so they can close it right but right so that the the public shaming bit there will hopefully help with that in those cases the maintainers typically still there there's still a big impact they just they're not addressing bugs which happens you got some process to notify him Luke is going to delete it if he doesn't do this he's going to do it maybe but I mean there's no teeth to it because you can't actually remove it if he doesn't do it you can always move no you can't just like we had a policy that we were going to turn off the I636 kernel if there were build issues and the state didn't fix them and as soon as we did we realized that we broke building anything so we had to work around that and it did there's no teeth to it now there are because we separated hurdle headers but until then so basically we'll have something like the FTPFAS same like if the package is no longer building and go live so one point in time we'll have the same thing for security issue so someone commented on the let's go take it saying that we use the FTBS process similar to that to try to remove the package because that would kind of send a mail to the maintainer as well saying that we are going to remove the package or something and that would probably easier than to have some other mechanism to try to remove the package so probably some something similar to that okay