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