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
|
<!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=%3C1309043079.22020.248.camel%40akroma.ephaone.org%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="006002.html">
<LINK REL="Next" HREF="006023.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Update of backport, policy proposal</H1>
<B>Michael Scherer</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Update%20of%20backport%2C%20policy%20proposal&In-Reply-To=%3C1309043079.22020.248.camel%40akroma.ephaone.org%3E"
TITLE="[Mageia-dev] Update of backport, policy proposal">misc at zarb.org
</A><BR>
<I>Sun Jun 26 01:04:38 CEST 2011</I>
<P><UL>
<LI>Previous message: <A HREF="006002.html">[Mageia-dev] Update of backport, policy proposal
</A></li>
<LI>Next message: <A HREF="006023.html">[Mageia-dev] Update of backport, policy proposal
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6022">[ date ]</a>
<a href="thread.html#6022">[ thread ]</a>
<a href="subject.html#6022">[ subject ]</a>
<a href="author.html#6022">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le vendredi 24 juin 2011 à 18:13 -0400, andre999 a écrit :
><i> Michael Scherer a écrit :
</I>><i> >
</I>><i> > This mail is about handling update on the backport repository. Either
</I>><i> > new version, or bugfix, or security upgrade.
</I>><i> >
</I>><i> > Everybody was focused on "should we do patch, or should we do more
</I>><i> > backport" issue, but the real problem is not really here.
</I>><i> >
</I>><i> > First, we have to decide what kind of update do we want to see, among
</I>><i> > the 3 types :
</I>><i> > - bugfixes
</I>><i> > - security bug fixes,
</I>><i> > - new version
</I>><i>
</I>><i> For bugfixes and new versions, that are not known to have security implications, let's treat them
</I>><i> essentially as new backports.
</I>><i> If the bug were locally reported, the reporter would be involved in the testing.
</I>><i> Such updates would be installed as any other backport.
</I>><i> However I would favour notifying those who have installed previous versions of these backports, of
</I>><i> the availability of newer versions.
</I>
The question is "how".
><i> Maybe even having a backports updates category. (But not to be installed automatically by default.)
</I>><i>
</I>><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>
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> 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>
So that basically mean "unsupported".
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 ?
--
Michael Scherer
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="006002.html">[Mageia-dev] Update of backport, policy proposal
</A></li>
<LI>Next message: <A HREF="006023.html">[Mageia-dev] Update of backport, policy proposal
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#6022">[ date ]</a>
<a href="thread.html#6022">[ thread ]</a>
<a href="subject.html#6022">[ subject ]</a>
<a href="author.html#6022">[ 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>
|
