diff options
Diffstat (limited to 'zarb-ml/mageia-dev/2011-June/006076.html')
| -rw-r--r-- | zarb-ml/mageia-dev/2011-June/006076.html | 173 |
1 files changed, 173 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/2011-June/006076.html b/zarb-ml/mageia-dev/2011-June/006076.html new file mode 100644 index 000000000..c45a5fcc5 --- /dev/null +++ b/zarb-ml/mageia-dev/2011-June/006076.html @@ -0,0 +1,173 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] Update of backport, policy proposal + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C4E0931F8.4000504%40laposte.net%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="006048.html"> + <LINK REL="Next" HREF="006164.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] Update of backport, policy proposal</H1> + <B>andre999</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C4E0931F8.4000504%40laposte.net%3E" + TITLE="[Mageia-dev] Update of backport, policy proposal">andr55 at laposte.net + </A><BR> + <I>Tue Jun 28 03:44:24 CEST 2011</I> + <P><UL> + <LI>Previous message: <A HREF="006048.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI>Next message: <A HREF="006164.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6076">[ date ]</a> + <a href="thread.html#6076">[ thread ]</a> + <a href="subject.html#6076">[ subject ]</a> + <a href="author.html#6076">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Michael Scherer a écrit : + +>><i> However I would favour notifying those who have installed previous versions of these backports, of +</I>>><i> the availability of newer versions. +</I>><i> +</I>><i> The question is "how". +</I> +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. + +>><i> For security issues, I'm not sure that it is important how we find out. +</I>>><i> As far as responsibility, I think the main responibility should be by the packager, but it could be +</I>>><i> useful for the security team to monitor it, to find an alternate packager if necessary. +</I>>><i> (Presumably from those who have tested or installed the package.) +</I>>><i> (I don't know who monitors security issues now, I just assume the security team.) +</I>>><i> +</I>>><i> However I think that such packages should be tested as normally for backports, and then treated as +</I>>><i> security updates, to be automatically applied. +</I>><i> +</I>><i> If we place it in a repository that is enabled by default, we will +</I>><i> basically do a version upgrade for every people that have it enabled. +</I>><i> +</I>><i> If this is updates, this would violate our own policy. +</I>><i> +</I>><i> If we place in backports, it is not enabled by default. +</I> +I have a response to that below. + +>><i> This is because those who have installed the backport in question have decided to accept a higher +</I>>><i> degree of risk. However a security issue can be a much greater risk, and is something that is +</I>>><i> normally resolved automatically. So by installing a security bug fix automatically for a backport, +</I>>><i> we are essentially maintaining the level of risk already assumed by the user. +</I>><i> +</I>><i> So that basically mean "unsupported". +</I> +The intent is to support for security issues. + +><i> There is even more tricky problems : +</I>><i> Let's take a software that release soon, release often. Let's say a voip +</I>><i> software. +</I>><i> +</I>><i> Someone install version 1.0 from release. So far, so good, but he hear +</I>><i> that 1.1 is out, and he install it from backport ( after requesting ). +</I>><i> He is satisfied, then the developers of our voip software decide to +</I>><i> create a version 2.0, with a completely new interface but the ui is yet +</I>><i> unfinished and untranslated, so our user cannot use it. Yet, someone +</I>><i> request a backport, and let's assume we do it. +</I>><i> +</I>><i> With our current scheme, our user will not be affected and he doesn't +</I>><i> want to upgrade. So he keep the version 1.1. +</I>><i> +</I>><i> A security issue is discovered, in 1.X and 2.X. +</I>><i> +</I>><i> 1.0-2 is sent to release update, with security fix. +</I>><i> 2.1 is sent to backport, as the packager follow the list. +</I>><i> +</I>><i> What should be done for the user : +</I>><i> Force upgrade to the next major release ? +</I>><i> Ask him to revert to release update ? +</I>><i> Tell him "this is not supported" ? +</I>><i> +</I>><i> Or maybe we should not have upgraded to 2.0 if we knew that current user +</I>><i> would refuse it ? +</I> +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é +</PRE> + + + + + + + + + + + + + + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="006048.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI>Next message: <A HREF="006164.html">[Mageia-dev] Update of backport, policy proposal +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#6076">[ date ]</a> + <a href="thread.html#6076">[ thread ]</a> + <a href="subject.html#6076">[ subject ]</a> + <a href="author.html#6076">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |