1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
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>
|
