[Mageia-dev] Update of backport, policy proposal

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é
+