9:41 a.m.
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.
--
Huzaifa Sidhpurwala / Red Hat Product Security Team
11:06 a.m.
I'm in!
Thanks for doing this Huzaifa, you're awesome
--
JB
On Fri, Aug 10, 2018 at 7:41 AM, Huzaifa Sidhpurwala <huzaifas(a)redhat.com>
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.
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.
--
Huzaifa Sidhpurwala / Red Hat Product Security Team
_______________________________________________
security-team mailing list -- security-team(a)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(a)lists.fedoraproject.org/message/P3AHRBMISHM5Q75APTMXJLFRAJZOW756/
5:58 a.m.
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.
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.
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
4:16 p.m.
On Wed, Aug 15, 2018 at 5:58 AM, Fabian Affolter <fab(a)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.
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(a)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(a)lists.fedoraproject.org/message/DL6BIUPCOQTESQVKQIAATLXJ5JPTKLHY/
7:31 p.m.
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(a)redhat.com>)
escribió:
On Wed, Aug 15, 2018 at 5:58 AM, Fabian Affolter
<fab(a)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.
>
> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to
> security-team-leave(a)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.fedorap...
>
>
_______________________________________________
security-team mailing list -- security-team(a)lists.fedoraproject.org
To unsubscribe send an email to
security-team-leave(a)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.fedorap...
--
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
8:48 p.m.
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(a)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
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.
> 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(a)lists.fedoraproject.org
<mailto:security-team@lists.fedoraproject.org>
To unsubscribe send an email to
security-team-leave(a)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.fedorap...
<https://lists.fedoraproject.org/archives/list/security-team@lists.fedorap...
_______________________________________________
security-team mailing list -- security-team(a)lists.fedoraproject.org
To unsubscribe send an email to security-team-leave(a)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.fedorap...
--
Corey W Sheldon * USMC * KN4FTO
M: +1 (571).707.0261
VoIP: +1 (310).909.7672 (hangouts)
Freelance IT Consultant, Multi-Discipline Tutor * Ameridea co-Founder
PluralSight, Mentor/Evangelist * Fedora & Mozilla Contributor (linuxmodder)
CERT & Medical Response Corps (Fairfax County, Va) * Team Rubicon (Regions 3 & 1)
sheldon.corey(a)gmail.com * kn4fto(a)gmail.com * csheldon(a)ameridea.net
linuxmodder(a)fedoraproject.org * l1nuxm0dd3r(a)keybase.io
PGP:
0x5678CE79EB9CD6CC FP: AA3AA62E06771842B6DA53A05678CE79EB9CD6CC
0xC2B852053E58CCEA FP: 762114B31ADB0999EF84BD1DC2B852053E58CCEA
6:50 p.m.
Huzaifa Sidhpurwala <huzaifas(a)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.
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.
Great idea.
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).
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.
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.
At last, I'm absolutely for in.
Looking forward for new tasks to contribute Fedora community.
Kind regards
--
Bojan Jovanović
9:04 a.m.
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!
--
Huzaifa Sidhpurwala / Red Hat Product Security Team
4:13 a.m.
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:
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!
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
--
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile +44-78-55069812
Tristan.Santore(a)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(a)fedoraproject.org
11:43 a.m.
On Tue, Aug 28, 2018 at 4:13 AM, Tristan Santore
<tristan.santore(a)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:
>
> 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!
>
>
>
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(a)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(a)fedoraproject.org
>
> _______________________________________________
> security-team mailing list -- security-team(a)lists.fedoraproject.org
> To unsubscribe send an email to security-team-leave(a)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.fedorap...
9:55 p.m.
On 08/28/2018 10:13 PM, Justin Forbes wrote:
On Tue, Aug 28, 2018 at 4:13 AM, Tristan Santore
<tristan.santore(a)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:
>>
>> 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!
>>
>>
>>
> 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(a)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(a)fedoraproject.org
>
> _______________________________________________
> security-team mailing list -- security-team(a)lists.fedoraproject.org
> To unsubscribe send an email to security-team-leave(a)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.fedorap...
_______________________________________________
security-team mailing list -- security-team(a)lists.fedoraproject.org
To unsubscribe send an email to security-team-leave(a)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.fedorap...
--
Huzaifa Sidhpurwala / Red Hat Product Security Team
2065
days inactive
2084
days old
security-team@lists.fedoraproject.org
10 comments
8 participants
participants (8)
-
Bojan Jovanović -
Corey Sheldon -
Eduard Lucena -
Fabian Affolter -
Huzaifa Sidhpurwala -
Josh Bressers -
Justin Forbes -
Tristan Santore