[Mageia-dev] Update of backport, policy proposal

andre999 andr55 at laposte.net
Tue Jun 28 03:44:24 CEST 2011


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é


More information about the Mageia-dev mailing list