Hello Folks,
I am writing this email from Flock Fedora conference in Dresden, Germany. For those who do not know me, i work for the Red Hat Product Security Team and have been a fedora contributor for the last 8 odd years.
To keep this short, i intend to reboot the Fedora Security Team. I know its been a while since there was some active work here. Also i dont intend to keep this limited to just pinging maintainers to patch their packages.
I have proposed the following initiatives/projects during my talk at Flock this year.
1. Scan packages for security on package entry! Package reviewers already use the Fedora-PackageReview package. Red Hat Security Team is internally working on a fork of this to include basic security scanning like searching for CVEs in NIST database, checking if any unsafe calls are used etc. We will contribute this code back to upstream, once its ready. I propose we use this to ensure new packages dont security flaws.
2. Package Exit policy: Details here: https://pagure.io/fesco/issue/1935 and discussion on fedora-devel list. I spoke to some FESCO members during flock this year and it seems like they think positively about this. We also discussed sharing stats about maintainers who dont patch security issues (some sort of public shaming).
3. Scan commits for existing packages to ensure no malicious code is being introduced: Have not quite figured this out yet, but it seems this is doable.
4. Fedora Security dashboard: The intention here is to create a web dashboard, showing current status of security bugs per distros, sorted according to security impact, and other useful data. Just to show everyone where we are.
If you can think of anything else, other than the above, do let me know, i am open to ideas :)
Lastly if any one is not interested in continuing their contribution to security team, do let me know. If i dont get an email from you stating that you are still interested in the next two weeks, i will remove your name from: https://fedoraproject.org/wiki/Security_Team_Roster
The intention is to get a clear picture of who all can help with the above tasks.
I'm in!
Thanks for doing this Huzaifa, you're awesome
On 08/10/2018 04:41 PM, Huzaifa Sidhpurwala wrote:
We also discussed sharing stats about maintainers who dont patch security issues (some sort of public shaming).
After some thoughts I'm still not a big fan of the public shaming approach. There are a lot of non-Red Hat employees who are doing package maintenance on a voluntary base. Putting community members on display for not doing something for whatever reason will send the wrong signal. We want their support. Thus we should try to establish ways to support them.
- Scan commits for existing packages to ensure no malicious code is
being introduced: Have not quite figured this out yet, but it seems this is doable.
Adding additional checks should definitely be something that's considered. This could become a close cooperation with the FPC because it would be much easier if those guys are on our side.
Lastly if any one is not interested in continuing their contribution to security team, do let me know.
Well, I'm still in.
Kind regards,
Fabian
On Wed, Aug 15, 2018 at 5:58 AM, Fabian Affolter fab@fedoraproject.org wrote:
On 08/10/2018 04:41 PM, Huzaifa Sidhpurwala wrote:
We also discussed sharing stats about maintainers who dont patch security issues (some sort of public shaming).
After some thoughts I'm still not a big fan of the public shaming approach. There are a lot of non-Red Hat employees who are doing package maintenance on a voluntary base. Putting community members on display for not doing something for whatever reason will send the wrong signal. We want their support. Thus we should try to establish ways to support them
While I agree somewhat, it accomplishes a few things. It lets users and developers see what needs updating. The real hope here is it gets people to generate pull requests and fix the package, making things easier on the maintainer. It also allows users to really see a list of known issues. It is not uncommon for Fedora to have multiple packages which accomplish the same task. Perhaps knowing which packages have frequent security issues, or completely unfixed long standing security issues, users can choose an appropriate alternative. It would make a nice historical record for FESCo to review when we ask for a packge to be orphaned due to unresponsive maintainer. Finally, it would likely encourage more packages to stay on top of security issues, even though they are not on the list currently. Basically raising awareness of security in the community. And I say that as someone who will be on the list every single month, though for different CVEs each time. We don't even have to resort to direct shaming, we can leave the maintainer off of the list, just go by package name, CVE, severity. Maybe we could also include the number of days the CVE has been open. If we can also have the list send a direct email to each maintainer alerting them to their package showing up in the scan. I believe it is a tool to support maintainers for a few reasons. Packages often have several bugs open. It raises alert that one or more of those are security, and helps them know which to prioritize. It should also get other packagers actually creating fixes and filing pull requests in pagure. Public shaming is an odd term and I used it at Flock quite a bit, but simply because it is an easy summary for a process which should be a tool to help package maintainers. I am guessing that the majority of the long standing major CVE packages don't have active maintainers. It might get more people who aren't maintaining a package any longer to orphan those packages. For people not paying any attention to Fedora anymore, they may not notice, but it makes it much more effective to take those packages to FESCo and review the impact of removing them.
- Scan commits for existing packages to ensure no malicious code is
being introduced: Have not quite figured this out yet, but it seems this is doable.
Adding additional checks should definitely be something that's considered. This could become a close cooperation with the FPC because it would be much easier if those guys are on our side.
As it came up in the crypto session, we should also be scanning for crypto and hopefully adding that to the review process.
Lastly if any one is not interested in continuing their contribution to security team, do let me know.
Well, I'm still in.
Kind regards,
Fabian
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists. fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security- team@lists.fedoraproject.org/message/DL6BIUPCOQTESQVKQIAATLXJ5JPTKLHY/
Hi,
I'm +1 to this if we can come with some documentation for new contributors that are up to help (like me).
Br,
El mié., 15 ago. 2018 a las 19:09, Justin Forbes (jforbes@redhat.com) escribió:
On Wed, Aug 15, 2018 at 5:58 AM, Fabian Affolter fab@fedoraproject.org wrote:
On 08/10/2018 04:41 PM, Huzaifa Sidhpurwala wrote:
We also discussed sharing stats about maintainers who dont patch security issues (some sort of public shaming).
After some thoughts I'm still not a big fan of the public shaming approach. There are a lot of non-Red Hat employees who are doing package maintenance on a voluntary base. Putting community members on display for not doing something for whatever reason will send the wrong signal. We want their support. Thus we should try to establish ways to support them
While I agree somewhat, it accomplishes a few things. It lets users and developers see what needs updating. The real hope here is it gets people to generate pull requests and fix the package, making things easier on the maintainer. It also allows users to really see a list of known issues. It is not uncommon for Fedora to have multiple packages which accomplish the same task. Perhaps knowing which packages have frequent security issues, or completely unfixed long standing security issues, users can choose an appropriate alternative. It would make a nice historical record for FESCo to review when we ask for a packge to be orphaned due to unresponsive maintainer. Finally, it would likely encourage more packages to stay on top of security issues, even though they are not on the list currently. Basically raising awareness of security in the community. And I say that as someone who will be on the list every single month, though for different CVEs each time. We don't even have to resort to direct shaming, we can leave the maintainer off of the list, just go by package name, CVE, severity. Maybe we could also include the number of days the CVE has been open. If we can also have the list send a direct email to each maintainer alerting them to their package showing up in the scan. I believe it is a tool to support maintainers for a few reasons. Packages often have several bugs open. It raises alert that one or more of those are security, and helps them know which to prioritize. It should also get other packagers actually creating fixes and filing pull requests in pagure. Public shaming is an odd term and I used it at Flock quite a bit, but simply because it is an easy summary for a process which should be a tool to help package maintainers. I am guessing that the majority of the long standing major CVE packages don't have active maintainers. It might get more people who aren't maintaining a package any longer to orphan those packages. For people not paying any attention to Fedora anymore, they may not notice, but it makes it much more effective to take those packages to FESCo and review the impact of removing them.
- Scan commits for existing packages to ensure no malicious code is
being introduced: Have not quite figured this out yet, but it seems this is doable.
Adding additional checks should definitely be something that's considered. This could become a close cooperation with the FPC because it would be much easier if those guys are on our side.
As it came up in the crypto session, we should also be scanning for crypto and hopefully adding that to the review process.
Lastly if any one is not interested in continuing their contribution to security team, do let me know.
Well, I'm still in.
Kind regards,
Fabian
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproj...
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproj...
While I seem to have missed some of the context of the initial email somehow, I'd like to put in a few comments and ideas for the highlighted topics here.
1) Public shaming in my opinion is akin to the 'nuclear option', aka a absolute last resort.
I personally think the option given in high level by jforbes is a good starting point, however I think we might do a hybrid approach to that with a threshold, at which point public shaming becomes an option. Below I outline a template example.
Package(s) show up on the scan and are pushed to the list (and maintainer(s) explicitly via a CC/BCC. If the CVE is high enough, or a known 0Day this should elicit an immediate x-post to the packagers list and request any and all working PRs. If a maintainer refuses (not counting scheduled/announced leave etc) more than 45 days, we should start the unresponsive process internally (based on security risk), if this happens more than 3x a year or for more than 3 packages maintained by same person(s) they should be publicly removed from the p[ackagers/maintainers list and SIG and a re-review by their peers for any return requests.
2) Malicious code scans should in my opinion be worked with all needed SIGS and stakeholders and worked into the tooling.
On 8/15/18 5:16 PM, Justin Forbes wrote:
On Wed, Aug 15, 2018 at 5:58 AM, Fabian Affolter <fab@fedoraproject.org mailto:fab@fedoraproject.org> wrote:
On 08/10/2018 04:41 PM, Huzaifa Sidhpurwala wrote: > We also discussed sharing stats about maintainers who dont patch > security issues (some sort of public shaming). After some thoughts I'm still not a big fan of the public shaming approach. There are a lot of non-Red Hat employees who are doing package maintenance on a voluntary base. Putting community members on display for not doing something for whatever reason will send the wrong signal. We want their support. Thus we should try to establish ways to support themWhile I agree somewhat, it accomplishes a few things. It lets users and developers see what needs updating. The real hope here is it gets people to generate pull requests and fix the package, making things easier on the maintainer. It also allows users to really see a list of known issues. It is not uncommon for Fedora to have multiple packages which accomplish the same task. Perhaps knowing which packages have frequent security issues, or completely unfixed long standing security issues, users can choose an appropriate alternative. It would make a nice historical record for FESCo to review when we ask for a packge to be orphaned due to unresponsive maintainer. Finally, it would likely encourage more packages to stay on top of security issues, even though they are not on the list currently. Basically raising awareness of security in the community. And I say that as someone who will be on the list every single month, though for different CVEs each time. We don't even have to resort to direct shaming, we can leave the maintainer off of the list, just go by package name, CVE, severity. Maybe we could also include the number of days the CVE has been open. If we can also have the list send a direct email to each maintainer alerting them to their package showing up in the scan. I believe it is a tool to support maintainers for a few reasons. Packages often have several bugs open. It raises alert that one or more of those are security, and helps them know which to prioritize. It should also get other packagers actually creating fixes and filing pull requests in pagure. Public shaming is an odd term and I used it at Flock quite a bit, but simply because it is an easy summary for a process which should be a tool to help package maintainers. I am guessing that the majority of the long standing major CVE packages don't have active maintainers. It might get more people who aren't maintaining a package any longer to orphan those packages. For people not paying any attention to Fedora anymore, they may not notice, but it makes it much more effective to take those packages to FESCo and review the impact of removing them.
> 3. Scan commits for existing packages to ensure no malicious code is > being introduced: > Have not quite figured this out yet, but it seems this is doable. Adding additional checks should definitely be something that's considered. This could become a close cooperation with the FPC because it would be much easier if those guys are on our side.As it came up in the crypto session, we should also be scanning for crypto and hopefully adding that to the review process.
> Lastly if any one is not interested in continuing their contribution to > security team, do let me know. Well, I'm still in. Kind regards, Fabian _______________________________________________ security-team mailing list -- security-team@lists.fedoraproject.org <mailto:security-team@lists.fedoraproject.org> To unsubscribe send an email to security-team-leave@lists.fedoraproject.org <mailto:security-team-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html <https://getfedora.org/code-of-conduct.html> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://fedoraproject.org/wiki/Mailing_list_guidelines> List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproject.org/message/DL6BIUPCOQTESQVKQIAATLXJ5JPTKLHY/ <https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproject.org/message/DL6BIUPCOQTESQVKQIAATLXJ5JPTKLHY/>
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproj...
Huzaifa Sidhpurwala huzaifas@redhat.com writes:
Hello Folks,
I am writing this email from Flock Fedora conference in Dresden, Germany. For those who do not know me, i work for the Red Hat Product Security Team and have been a fedora contributor for the last 8 odd years.
To keep this short, i intend to reboot the Fedora Security Team. I know its been a while since there was some active work here. Also i dont intend to keep this limited to just pinging maintainers to patch their packages.
I welcome the initiative.
I have proposed the following initiatives/projects during my talk at Flock this year.
- Scan packages for security on package entry!
Package reviewers already use the Fedora-PackageReview package. Red Hat Security Team is internally working on a fork of this to include basic security scanning like searching for CVEs in NIST database, checking if any unsafe calls are used etc. We will contribute this code back to upstream, once its ready. I propose we use this to ensure new packages dont security flaws.
Great idea.
- Package Exit policy:
Details here: https://pagure.io/fesco/issue/1935 and discussion on fedora-devel list. I spoke to some FESCO members during flock this year and it seems like they think positively about this. We also discussed sharing stats about maintainers who dont patch security issues (some sort of public shaming).
Public shaming is a fairly radical process (treatment). This can be extremely counterproductive. There are many volunteers who are not under the Red or Blue HAT and maintain packages.
Organized help for maintainers in maintaining the security of the package through generating pull requests and fix the package from other people (volunteers) could rise number of skilled people to contribute to Fedora community.
- Scan commits for existing packages to ensure no malicious
code is being introduced: Have not quite figured this out yet, but it seems this is doable.
- Fedora Security dashboard:
The intention here is to create a web dashboard, showing current status of security bugs per distros, sorted according to security impact, and other useful data. Just to show everyone where we are.
If you can think of anything else, other than the above, do let me know, i am open to ideas :)
Lastly if any one is not interested in continuing their contribution to security team, do let me know. If i dont get an email from you stating that you are still interested in the next two weeks, i will remove your name from: https://fedoraproject.org/wiki/Security_Team_Roster
The intention is to get a clear picture of who all can help with the above tasks.
At last, I'm absolutely for in. Looking forward for new tasks to contribute Fedora community.
Kind regards
On 08/10/2018 08:11 PM, Huzaifa Sidhpurwala wrote:
Hello Folks,
I am writing this email from Flock Fedora conference in Dresden, Germany. For those who do not know me, i work for the Red Hat Product Security Team and have been a fedora contributor for the last 8 odd years.
Thank you everyone who replied to my email, both on this mailing list and privately. Please find below a short report on the overall progress since my first email, followed by replies to some of your questions:
1. https://pagure.io/fesco/issue/1935 Seems like FESCO likes this idea so far and in the next meeting it may even be approved. YAY!!
2. Fedora security dashboard: During FLOCK i sat in this very interesting talk on GSOC and outreachy. And i thought about letting students do the dashboard via one of the above projects. Good for them and us both :P
Now to answer some of the questions:
1. Nag emails: I think what myself and justin meant was more of "reminder emails", i plan to send one this monday and see what people think. The email will only say who needs to fix how many security fix and serve as a gentle reminder, no nuclear explosions intended!
2. Documentation: I realized that there was a shortage of docs for package maintainers on how to handle security flaws. I wrote this short doc at: https://fedoraproject.org/wiki/Security:HowtoSecurityBugs
This is more of a brain dump than anything else. Please feel free to edit and add more content or point my mistakes and i can correct them.
Lastly, based on all the replies i got, i am going to edit the security team page and remove all those folks who are not active. In case you are still interested do let me know, i can add you back!
On 26/08/18 16:04, Huzaifa Sidhpurwala wrote:
On 08/10/2018 08:11 PM, Huzaifa Sidhpurwala wrote:
Hello Folks,
I am writing this email from Flock Fedora conference in Dresden, Germany. For those who do not know me, i work for the Red Hat Product Security Team and have been a fedora contributor for the last 8 odd years.
Thank you everyone who replied to my email, both on this mailing list and privately. Please find below a short report on the overall progress since my first email, followed by replies to some of your questions:
Seems like FESCO likes this idea so far and in the next meeting it may even be approved. YAY!!
- Fedora security dashboard:
During FLOCK i sat in this very interesting talk on GSOC and outreachy. And i thought about letting students do the dashboard via one of the above projects. Good for them and us both :P
Now to answer some of the questions:
- Nag emails:
I think what myself and justin meant was more of "reminder emails", i plan to send one this monday and see what people think. The email will only say who needs to fix how many security fix and serve as a gentle reminder, no nuclear explosions intended!
- Documentation:
I realized that there was a shortage of docs for package maintainers on how to handle security flaws. I wrote this short doc at: https://fedoraproject.org/wiki/Security:HowtoSecurityBugs
This is more of a brain dump than anything else. Please feel free to edit and add more content or point my mistakes and i can correct them.
Lastly, based on all the replies i got, i am going to edit the security team page and remove all those folks who are not active. In case you are still interested do let me know, i can add you back!
Huzaifa,
I would suggest a very polite reminder email. Along the lines of:
Dear Package Maintainer,
This is a friendly reminder, that the package <PACKAGEHERE>, has the following outstanding unpatched CVEs/Security issues.
Question is, what to request or suggest....because I suspect that some maintainers probably need/could do with a few co-maintainers.
And we must not forget, we have many community people doing package maintenance, in their own spare time, so to alienate those lovely people would be contra-productive.
With regards to removing people from the Security Team Page, the question should be, are people not contributing, because there is too little guidance on procedures, information available and possibly SOPs (Standard Operating Procedures). I generally think, that security is such an important topic these days, across the board, that the Fedora community should set an example with guides on secure coding, secure infra advice, guides on the correct use of SElinux, including where to find good background information on its use. We ALL need to make a more concerted effort to improve the security landscape, in my very very humble opinion.
And thanks for taking a proactive role regarding this matter, really appreciate it, as surely do many others.
I will be following the progress here with great interest.
Kind regards,
Tristan
On Tue, Aug 28, 2018 at 4:13 AM, Tristan Santore tristan.santore@internexusconnect.net wrote:
On 26/08/18 16:04, Huzaifa Sidhpurwala wrote:
On 08/10/2018 08:11 PM, Huzaifa Sidhpurwala wrote:
Hello Folks,
I am writing this email from Flock Fedora conference in Dresden, Germany. For those who do not know me, i work for the Red Hat Product Security Team and have been a fedora contributor for the last 8 odd years.
Thank you everyone who replied to my email, both on this mailing list and privately. Please find below a short report on the overall progress since my first email, followed by replies to some of your questions:
Seems like FESCO likes this idea so far and in the next meeting it may even be approved. YAY!!
- Fedora security dashboard:
During FLOCK i sat in this very interesting talk on GSOC and outreachy. And i thought about letting students do the dashboard via one of the above projects. Good for them and us both :P
Now to answer some of the questions:
- Nag emails:
I think what myself and justin meant was more of "reminder emails", i plan to send one this monday and see what people think. The email will only say who needs to fix how many security fix and serve as a gentle reminder, no nuclear explosions intended!
- Documentation:
I realized that there was a shortage of docs for package maintainers on how to handle security flaws. I wrote this short doc at: https://fedoraproject.org/wiki/Security:HowtoSecurityBugs
This is more of a brain dump than anything else. Please feel free to edit and add more content or point my mistakes and i can correct them.
Lastly, based on all the replies i got, i am going to edit the security team page and remove all those folks who are not active. In case you are still interested do let me know, i can add you back!
Huzaifa,
I would suggest a very polite reminder email. Along the lines of:
Dear Package Maintainer,
This is a friendly reminder, that the package <PACKAGEHERE>, has the following outstanding unpatched CVEs/Security issues.
Question is, what to request or suggest....because I suspect that some maintainers probably need/could do with a few co-maintainers.
And we must not forget, we have many community people doing package maintenance, in their own spare time, so to alienate those lovely people would be contra-productive.
With regards to removing people from the Security Team Page, the question should be, are people not contributing, because there is too little guidance on procedures, information available and possibly SOPs (Standard Operating Procedures). I generally think, that security is such an important topic these days, across the board, that the Fedora community should set an example with guides on secure coding, secure infra advice, guides on the correct use of SElinux, including where to find good background information on its use. We ALL need to make a more concerted effort to improve the security landscape, in my very very humble opinion.
I more got the impression that people who have remained silent would be removed. Not people who have expressed any sort of interest recently. The "Security Team" has been effectively dead over the past couple of years, and some of the people who had previously expressed interest may no longer be around. Getting added back is as simple as adding yourself. It's not punitive. There is certainly a lack of guidance, and I think we are moving in the right direction for fixing that. I am also planning to work on a doc for "Procedures for creating a pull request for known CVEs" In an attempt to hopefully get more people involved, the goal being people who want to chip in can actually patch packages to fix known security issues and a pull request is generally helpful to the maintainer without stepping on toes.
Justin
And thanks for taking a proactive role regarding this matter, really appreciate it, as surely do many others.
I will be following the progress here with great interest.
Kind regards,
Tristan
-- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore@internexusconnect.net
Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at: TSantore@fedoraproject.org
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproj...
On 08/28/2018 10:13 PM, Justin Forbes wrote:
On Tue, Aug 28, 2018 at 4:13 AM, Tristan Santore tristan.santore@internexusconnect.net wrote:
On 26/08/18 16:04, Huzaifa Sidhpurwala wrote:
On 08/10/2018 08:11 PM, Huzaifa Sidhpurwala wrote:
Hello Folks,
I am writing this email from Flock Fedora conference in Dresden, Germany. For those who do not know me, i work for the Red Hat Product Security Team and have been a fedora contributor for the last 8 odd years.
Thank you everyone who replied to my email, both on this mailing list and privately. Please find below a short report on the overall progress since my first email, followed by replies to some of your questions:
Seems like FESCO likes this idea so far and in the next meeting it may even be approved. YAY!!
- Fedora security dashboard:
During FLOCK i sat in this very interesting talk on GSOC and outreachy. And i thought about letting students do the dashboard via one of the above projects. Good for them and us both :P
Now to answer some of the questions:
- Nag emails:
I think what myself and justin meant was more of "reminder emails", i plan to send one this monday and see what people think. The email will only say who needs to fix how many security fix and serve as a gentle reminder, no nuclear explosions intended!
- Documentation:
I realized that there was a shortage of docs for package maintainers on how to handle security flaws. I wrote this short doc at: https://fedoraproject.org/wiki/Security:HowtoSecurityBugs
This is more of a brain dump than anything else. Please feel free to edit and add more content or point my mistakes and i can correct them.
Lastly, based on all the replies i got, i am going to edit the security team page and remove all those folks who are not active. In case you are still interested do let me know, i can add you back!
Huzaifa,
I would suggest a very polite reminder email. Along the lines of:
Dear Package Maintainer,
This is a friendly reminder, that the package <PACKAGEHERE>, has the following outstanding unpatched CVEs/Security issues.
Question is, what to request or suggest....because I suspect that some maintainers probably need/could do with a few co-maintainers.
And we must not forget, we have many community people doing package maintenance, in their own spare time, so to alienate those lovely people would be contra-productive.
Exactly, in fact i am thinking of sending a blanked email to fedora-devel to start with, without mentioning any names etc, but just a gentle reminder for everyone to fix their pkgs, of-course mentioning the doc which just wrote.
With regards to removing people from the Security Team Page, the question should be, are people not contributing, because there is too little guidance on procedures, information available and possibly SOPs (Standard Operating Procedures). I gen
erally think, that security is such an important topic
these days, across the board, that the Fedora community should set an example with guides on secure coding, secure infra advice, guides on the correct use of SElinux, including where to find good background information on its use. We ALL need to make a more concerted effort to improve the security landscape, in my very very humble opinion.
I more got the impression that people who have remained silent would be removed. Not people who have expressed any sort of interest recently. The "Security Team" has been effectively dead over the past couple of years, and some of the people who had previously expressed interest may no longer be around. Getting added back is as simple as adding yourself. It's not punitive. There is certainly a lack of guidance, and I think we are moving in the right direction for fixing that. I am also planning to work on a doc for "Procedures for creating a pull request for known CVEs" In an attempt to hopefully get more people involved, the goal being people who want to chip in can actually patch packages to fix known security issues and a pull request is generally helpful to the maintainer without stepping on toes.
Justin
And thanks for taking a proactive role regarding this matter, really appreciate it, as surely do many others.
I will be following the progress here with great interest.
Kind regards,
Tristan
-- Tristan Santore BSc MBCS TS4523-RIPE Network and Infrastructure Operations InterNexusConnect Mobile +44-78-55069812 Tristan.Santore@internexusconnect.net
Former Thawte Notary (Please note: Thawte has closed its WoT programme down, and I am therefore no longer able to accredit trust)
For Fedora related issues, please email me at: TSantore@fedoraproject.org
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproj...
security-team mailing list -- security-team@lists.fedoraproject.org To unsubscribe send an email to security-team-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/security-team@lists.fedoraproj...
security-team@lists.fedoraproject.org
-
Bojan Jovanović -
Corey Sheldon -
Eduard Lucena -
Fabian Affolter -
Huzaifa Sidhpurwala -
Josh Bressers -
Justin Forbes -
Tristan Santore