Unresponsive maintainers - start discussing!

[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

[David Cafaro]

>  On Jul 2, 2015, at 10:52 AM, Stefan Cornelius
> <scorneli(a)redhat.com&gt; wrote:
>  <snip stuff>
>  
>  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. 

In general I like this idea, it’s something I’m more likely to work on vs a general proven
packager (which I’m not).  But, some issues to worry about:

1. Work load, this could get very heavy if there are only a few security cleaners.
2. Code base, this group of people would need to have some comfort in just about EVERY
computer language out there.  I’ve already had to deal with things written in C, C++,
Ruby, Python, PHP.  It can be one thing to package an rpm from someone else's source
and build instructions, it’s a bigger task to back port patches to the code.


>  
>  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. 

We’ve had a little discussion on both how long do we wait for someone to respond and what
to do when something goes orphaned.  I would argue that if we have to even handle a fix
once ourselves the non-responsive maintainer process should start.  Bigger question is how
long do we give a maintainer to respond.  My guess is that time will depend on how
critical the security bug is.  Possible time lines:

1. Critical: 4 days
2. Important (remote exploit): one week
3. Important (non-remote): three weeks
4. Moderate: 1 month
5. Everything else: 2 months

There will be exceptions where a critical active exploit that’s in the wild hitting things
might require only waiting 1 day or less.  And there are chances this time limit will hit
and the maintainer will respond shortly after.  There will have to be some flexibility,
but if the policy is clear it will give us authority to act with out having to explain
ourselves or second guess ourselves.

In addition to policy like the above and the group of security cleaners handling emergency
patches, dnf (and possibly yum for redhat/centos packages) will need an update to handle
alerts as you mentioned.  Sparks started some discussion on this already as well.  

https://sparkslinux.wordpress.com/2015/03/26/for-discussion-orphaned-pack...


>  
>  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
>  _______________________________________________
>  security-team mailing list
>  security-team(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/mailman/listinfo/security-team