Michael Scherer a écrit :
However I would favour notifying those who have installed previous versions of
these backports, of
the availability of newer versions.
The question is "how".
Good question :)
We could send emails to those who have contributed to the backport issue (bugzilla or
madb), including the requester and packager. The latter may not be the same as packaged
the previous backport.
We could also add a mechanism in rpmdrake and/or urpmi which gives a user the choice of
opting in to notification when they install a backport.
For security issues, I'm not sure that it is important how we find out.
As far as responsibility, I think the main responibility should be by the
packager, but it could be
useful for the security team to monitor it, to find an alternate packager if
necessary.
(Presumably from those who have tested or installed the package.)
(I don't know who monitors security issues now, I just assume the security
team.)
However I think that such packages should be tested as normally for backports,
and then treated as
security updates, to be automatically applied.
If we place it in a repository that is enabled by default, we will
basically do a version upgrade for every people that have it enabled.
If this is updates, this would violate our own policy.
If we place in backports, it is not enabled by default.
I have a response to that below.
This is because those who have installed the backport in question have decided
to accept a higher
degree of risk. However a security issue can be a much greater risk, and is
something that is
normally resolved automatically. So by installing a security bug fix
automatically for a backport,
we are essentially maintaining the level of risk already assumed by the user.
So that basically mean "unsupported".
The intent is to support for security issues.
There is even more tricky problems :
Let's take a software that release soon, release often. Let's say a voip
software.
Someone install version 1.0 from release. So far, so good, but he hear
that 1.1 is out, and he install it from backport ( after requesting ).
He is satisfied, then the developers of our voip software decide to
create a version 2.0, with a completely new interface but the ui is yet
unfinished and untranslated, so our user cannot use it. Yet, someone
request a backport, and let's assume we do it.
With our current scheme, our user will not be affected and he doesn't
want to upgrade. So he keep the version 1.1.
A security issue is discovered, in 1.X and 2.X.
1.0-2 is sent to release update, with security fix.
2.1 is sent to backport, as the packager follow the list.
What should be done for the user :
Force upgrade to the next major release ?
Ask him to revert to release update ?
Tell him "this is not supported" ?
Or maybe we should not have upgraded to 2.0 if we knew that current user
would refuse it ?
All these points you raise are interesting. After reflexion, I think this will
work :
1) A condition of backports is that the backport packager commits to packaging any
security updates that arise. (s/he could designate an alternate.)
(I would expect that most backports would not be very vulnerable, but of course any
dealing with Internet access or arbitrary 3-party files are more likely to be.)
2) Backports would not be removed from repos when a newer backport arrives, except those
affected by security updates.
This allows reverting to previous backports if a user finds a problem with a backport on
their system.
3) Security fixes must be created for all affected backports.
This means that if 4 backports exist for an application, and all 4 are affected by the
security problem, we have to make 4 security fixes. If only 2 of 4 are affected, those
2 would require security fixes.
4) Security fixes would be applied automatically by the security update
mechanism.
Only the corresponding update repo need be activated for this to happen.
However, security fixes from backports would only be applied to specific
backports.
So for version 1.0 in release, and versions 1.1 , 1.2 and 1.3 in backports,
with a security fix 1.0-1 for release,
we would also create fixes 1.1-1 , 1.2-1 , and 1.3-1
to be applied to backports 1.1 , 1.2 and 1,3 respectively (assuming all are
affected).
These security fixes for backports could be in the backport repo if properly tracked by
the security update mechanism.
This means that there has to be a modification of the security update mechanism to
ensure that the updates to backports are only applied to the appropriate backport.
Does this sound workable ?
--
André
