10:59 a.m.
On Jul 2, 2015, at 10:52 AM, Stefan Cornelius
<scorneli(a)redhat.com> 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