Ticket #440 (closed task: fixed)
Improve updates process to avoid "windows of doom"
|Reported by:||drago01||Owned by:|
|Cc:||rdieter, jsmith, ianweller, rhughes||Blocked By:|
A recent PackageKit? updated moved the packagekitd binary to a different location and thus breaking the selinux label.
The result is that packagekitd silently fails to start and thus users who updated to this version will no longer receive update notifications and thus potentially render a lot of systems vulnerable as they stop getting updates.
The bug has been fixed in a recent selinux-policy package, but this does not really help the users that updated in this period aka the "window of doom" ... they will just don't get any update notification and presume that they just aren't any.
The package in question has gone through the new updates process but we still failed to detect this major flaw; a breaking the update infrastructure should be avoided at all cost as it dealing with it afterwards is always troublesome and in some cases even "unfixable".
The problem in this specific case it does only happen when selinux is in enforcing mode; which leads to the conclusion that the "proventesters" did test on a non standard configuration (we default to selinux on).
There are two problems here; the doomed users that where affected by that update and the fact that we let it happen.
I am afraid the former can't really be fixed the best we can do is to issue some statement and hope that it gets some attention from the press so that at least some of the affected users become aware of the issue.
As for avoiding it from happening again we proventesters should be educated that they should (must) test using some standard default configuration and probably go a step further and demand that they should not only ack an update with "works for me" but provide information on what exactly they tested and on which system configuration that allows the maintainer to judge whether his/her package got enough testing on a wide range of system configuration and seeing what tests where actually made is a way better deciding base than "works for me".
QA Proventesters, maybe the board / FPL for the "press statement"; package maintainers