Unresponsive maintainers - start discussing!
by Stefan Cornelius
[this has been in my drafts folder for some time. But since this topic
came up again in today's meeting, and seeing that others had similar
ideas (I think mhayden or d-caf; already forgot :/), I think it's time
to send it]
So, I thought a bit more about the unresponsive maintainers problem.
The current process, as described in [1] has some obvious problems:
* takes too long
* not fun to chase people around
* wastes time that we can probably make better use of
The provenpackager page [2] lists some rough mechanisms that should take
care of unresponsive maintainers. That looks good initially, but has
shortcomings:
* just shifts the problem from chasing unresponsive maintainers to
semi-responsive provenpackagers.
* looks and feels more like a band-aid solution for a problem that
"shouldn't happen", not like a proper process (for security issues,
at least). The truth is that it's not working, or we simply wouldn't
see the stagnation we're currently seeing.
So, we need to get away from chasing 3rd parties for fixes to doing
fixes ourselves. There should be a quick and easy (by easy I mean no
unnecessary hoops to jump through. Candidates obviously need to proof
that they have the necessary understanding and skills to do this task)
route into a group similar to provenpackagers, but that's allowed to
solely focus on security issues without having any other provenpackager
responsibilities. This idea is scary to people because we may end up
breaking stuff in the process. But think about it: We already have
mechanisms to catch the worst stuff (like the 3 positive ratings
thing). Also, how much worse than an insecure package can it really
be? Mind you, you can still downgrade to the insecure but working
version if things are really messed up badly ... so bottom line, I
don't see a big reason to be concerned.
Presuming that such a policy exists, there may still be problems:
* it can be the case that it's impossible to do a security fix safely
due to ABI changes or other annoyances
* we end up fixing the same unmaintained packages over and over again
So, we need to find a way to deal with those. One option in the
distant future could be something like: If we have to fix an
unmaintained package with security issues X times in a row - add it to
a list. If we have no good way of fixing it, add it to the same list. A
dnf plugin could then compare existing packages or packages about to be
installed to the list of flagged packages and warn the user with a
reason as to why it's a bad idea to install this and that it needs a
new maintainer. Users could still choose to override this, but on their
own risk. Also, this is displayed to actual, active users of the
package, so maybe there is a slim chance that one of them cares enough
to step up as maintainer. If nobody cares ... well, then I guess it
simply wasn't important enough and will just be orphaned.
Now, I'm not saying that anything of this is the ultimate solution,
neither do I expect it to be. I just want a discussion that hopefully
leads us to something better than we have now (and then reiterate).
[1]
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
[2]
https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages
Thanks,
--
Stefan Cornelius / Red Hat Product Security
8 years, 10 months
New Meeting Time
by Eric Christensen
In this week's meeting we decided to change the meeting time to accommodate
more people. In our poll it was seen that two hours per week had the least
amount of friction. It was decided that our new meeting time will be:
Tuesdays at 00:01 UTC (Use our handy HowTo to determine your local time[0])
Hope to see you all there!
[0] https://fedoraproject.org/wiki/UTCHowto
--Eric
8 years, 10 months
Re: sparks's meeting titled "Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings" ended in #fedora-meeting
by Major Hayden
Kudos to smilner and bkabrda for crushing some CVE's over the past couple of weeks! :)
--
Major Hayden
On 07/09/2015 09:46 AM, notifications(a)fedoraproject.org wrote:
> ======================================================================================================
> #fedora-meeting: Security Team Meeting - Agenda: https://fedoraproject.org/wiki/Security_Team_meetings
> ======================================================================================================
>
>
> Meeting started by Sparks at 14:00:03 UTC. The full logs are available
> at
> http://meetbot.fedoraproject.org/fedora-meeting/2015-07-09/fedora_securit...
> .
>
>
>
> Meeting summary
> ---------------
> * Roll Call (Sparks, 14:00:10)
> * Participants are reminded to make liberal use of #info #link #help
> in order to make the minutes "more better" (Sparks, 14:05:12)
>
> * 90-Day Challenge (Sparks, 14:05:19)
> * 90-Day Challenge has a goal to close all 2014 and prior Important
> CVEs in Fedora (Sparks, 14:05:25)
> * It's all done! (Sparks, 14:05:30)
> * As of 2015-07-09, of the 38 target bugs 16 have been closed, 4 is
> On_QA, and 18 are Open (Sparks, 14:05:36)
>
> * Outstanding BZ Tickets (Sparks, 14:10:59)
> * Thursday's numbers: Critical 0 (0), Important 51 (+8), Moderate 355
> (-20), Low 151 (-12), Total 517, Trend -68 (Sparks, 14:11:06)
> * Current tickets owned: 89 (~17%) (Sparks, 14:11:10)
> * Tickets closed: 348 (+20) (Sparks, 14:11:16)
> * LINK:
> http://i.dailymail.co.uk/i/pix/2013/09/22/article-0-18297CEF00000578-775_...
> (mhayden, 14:22:37)
>
> * New Meeting Time (Sparks, 14:25:37)
> * LINK: http://whenisgood.net/98rtz7p/results/eyz7qkh (Sparks,
> 14:25:46)
> * ACTION: Sparks to advertise new meeting time (Sparks, 14:35:57)
> * New meeting time will be Wednesdays at 0001 UTC (Tuesday at 8PM US
> Eastern) (Sparks, 14:37:20)
>
> * Open floor discussion/questions/comments (Sparks, 14:37:53)
> * New meeting time will be Tuesdays at 0001 UTC (Monday at 8PM US
> Eastern) (Sparks, 14:44:35)
>
> Meeting ended at 14:45:51 UTC.
>
>
>
>
> Action Items
> ------------
> * Sparks to advertise new meeting time
>
>
>
>
> Action Items, by person
> -----------------------
> * Sparks
> * Sparks to advertise new meeting time
> * **UNASSIGNED**
> * (none)
>
>
>
>
> People Present (lines said)
> ---------------------------
> * Sparks (64)
> * mhayden (29)
> * pjp (28)
> * zodbot (7)
> * scorneli (4)
> * pjones (3)
>
>
>
>
> Generated by `MeetBot`_ 0.1.4
>
> .. _`MeetBot`: http://wiki.debian.org/MeetBot
>
> https://meetbot.fedoraproject.org/fedora-meeting/2015-07-09/fedora_securi...
>
> --
> You received this message due to your preference settings at
> https://apps.fedoraproject.org/notifications/fmnmeetingminutes.id.fedorap...
> _______________________________________________
> meetingminutes mailing list
> meetingminutes(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/meetingminutes
>
8 years, 10 months
Meeting Notes from 2015-07-02
by Major Hayden
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hey folks,
Here are the notes from today's Fedora Security Team meeting:
Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2015-07-02/fedora_securit...
Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2015-07-02/fedora_securit...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2015-07-02/fedora_securit...
Meeting summary
- ---------------
* Roll Call (mhayden, 14:01:02)
* Participants are reminded to make liberal use of #info #link #help
in order to make the minutes "more better" (mhayden, 14:05:08)
* 90-Day Challenge (mhayden, 14:05:19)
* LINK: https://ethercalc.org/90-day-challenge (mhayden, 14:05:33)
* 90-Day Challenge has a goal to close all 2014 and prior Important
CVEs in Fedora (mhayden, 14:05:39)
* Outstanding BZ Tickets (mhayden, 14:08:18)
* LINK:
https://lists.linuxcontainers.org/pipermail/lxc-devel/2015-June/011898.html
(mhayden, 14:11:18)
* LINK:
https://fedoraproject.org/wiki/LXC_Template_Security_Improvements
(mhayden, 14:14:20)
* Open floor discussion/questions/comments (mhayden, 14:22:51)
* LINK:
http://meetbot.fedoraproject.org/fedora-meeting/2015-06-11/fedora_securit...
(d-caf, 14:23:22)
* For non-responsive maintainers at redhat.com email addresses, reach
out to scorneli (mhayden, 14:24:28)
* ACTION: Check in with Fabio0live about the non-responsive maintainer
process automation (mhayden, 14:24:51)
* Biggest barrier to closing security bugs is non-responsive
maintainers (mhayden, 14:25:12)
* IDEA: Possibly use provenpackers in FST to tackle high priority
security bugs on non-responsive maintainer packages -- needs more
discussion (mhayden, 14:29:36)
* Provenpackager access has been used in the past for critical bugs
(thanks d-caf) (mhayden, 14:30:20)
* LINK: https://www.youtube.com/watch?v=a9lE9Urr6AQ (mhayden,
14:32:49)
* LINK: Super Privileged Containers- >
https://www.youtube.com/watch?v=dM2Fc53Dtd4 (mhayden, 14:33:21)
Meeting ended at 14:35:34 UTC.
Action Items
- ------------
* Check in with Fabio0live about the non-responsive maintainer process
automation
Action Items, by person
- -----------------------
* **UNASSIGNED**
* Check in with Fabio0live about the non-responsive maintainer process
automation
People Present (lines said)
- ---------------------------
* mhayden (85)
* d-caf (37)
* scorneli (6)
* revskills (4)
* zodbot (3)
* jrusnack (2)
* striker (1)
- --
Major Hayden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVlU0NAAoJEHNwUeDBAR+xWegP/iYioJCEU2HxtWj8zMQdG0Wo
RKMwdbrn2MiyAJsy3HViJdv01906SOYBChPxR/M42Km/evxMezrrCu7R42R6eDjB
oInvmYmdmWip8uZa6I7IJyT2kmL0Rj/FE+4tFbuTOhqNSxRsyddCvAUMzaBC5u0L
lBS9AeCVksMNMtNh+hGxiqvBkoIxjGYGnauHQ2CsEHahaPgHfxmnX29HFAkYBhuD
7vAJ0DNH2vb6icpJ7B92lXXeXFaOzpzaV32tsXau7WNStS+jEqRYYLiMhYr1Vkqp
9qnXqlK1A5HlKvpRC6G2aDYVM8k0l23W2RptOcHGzVssjW0DIq73kzDhelJ8poBg
9C31ainVfT6MtLc6SMY4QRne3ODiRKOu1zQK3iro/U7kpBlcLr/3QXm5eJsJKCk6
GbJLRDKmGG19qmlwBdcuX4na9ZabNWI76rv0srBEy8QK4VQiB69TZuh2X6iVZcBx
ia+tSGJQs8SP4EIwMeQOljAPwrzF09ybNXhPRubKIt+e8tZD9LOLtqoRrgBrQSbO
lBJRalPJ+ZJjyWH/hTfVDcGHAcv2jN94QB3aKM051jRzrAwp7p3y+lM6Ah/ZNBgQ
ujO+tZLjLDG6dK0AOsPOj6wD0Xxt7DB3KyX+UgtUObHQiQI3NItkO7sKQJvlrg+l
1acLTnrSoQsQ5E8U2Hkr
=j35b
-----END PGP SIGNATURE-----
8 years, 10 months
