Kevin Kofler wrote:
> The "heaps" of users do not install Fedora the day of the release.
> Only very few very enthousiastic and very impatient early adopters do that
> (and I blame them for needlessly swamping our mirrors).
If they are so very few, how can they swamp a couple hundred big FTP archi
Adam Williamson wrote:
> # There must be no known remote code execution vulnerability which could
> be exploited during installation or during use of a live image shipped
> with the release
If the installer would download packages during the installation, and an
attacker could trick it into downl
On Thu, 2011-05-19 at 10:00 +0800, Eugene Teo wrote:
> I say, local privilege escalations with publicly available exploits, and
> remotely triggerable vulnerabilities. If such an issue is known before
> Final, we should attempt to address it before releasing.
Note, a release criterion would have
Adam Jackson wrote:
> On 5/18/11 4:49 PM, Kevin Kofler wrote:
>> The thing is, if we block the release for each and every known security
>> issue, considering the time passing between notification and public
>> availability of a fix, we will never be able to release anything. We have
>> to draw th
Simo Sorce wrote:
> Is it unthinkable to respin the images with those fixes ?
> Usually the patches are quite simple to backport, and we are talking
> about a limited set of bugs (remote root exploit on install) after all.
Then we'd need a second (or third, if the Features repo finally happens)
u
On Wed, 2011-05-18 at 22:49 +0200, Kevin Kofler wrote:
> The thing is, if we block the release for each and every known security
> issue, considering the time passing between notification and public
> availability of a fix, we will never be able to release anything. We have to
> draw the line s
Tomas Mraz wrote:
> Also note that targeting the heaps of poor users that are eager to try
> the newly shipped Fedora release would be probably much more easy and
> efficient than targeting one user installing the Fedora here or there a
> few months later.
Huh? The "heaps" of users do not install
On 5/18/11 4:49 PM, Kevin Kofler wrote:
> The thing is, if we block the release for each and every known security
> issue, considering the time passing between notification and public
> availability of a fix, we will never be able to release anything. We have to
> draw the line somewhere, and the b
On Wed, 2011-05-18 at 15:43 -0500, dr johnson wrote:
>
> Few questions here:
>
> What does this scope include? Is it merely the LiveCD for GNOME and
> KDE? Does it also include the DVD install selections for both of
> these packages? (They are different)
Well, that's part of the discussion I
Adam Jackson wrote:
> It's a rationally argued position, but argued from an initial state that
> does not reflect reality.
>
> I mean, the conclusion from that line of reasoning is that all releases
> are futile: any sufficiently severe bug unknown at release time could be
> discovered later, and
Few questions here:
What does this scope include? Is it merely the LiveCD for GNOME and KDE?
Does it also include the DVD install selections for both of these packages?
(They are different)
What about clearly vulnerable areas, like "Web Sever" that is push-button
selectable on install?
Do we ma
Adam Jackson wrote:
> The difference between a known and an unknown security bug is that, if
> _you_ know about it, it's virtually certain that someone malicious
> already does too.
>
> We can't avoid unknown risk exposure. You're arguing for ignoring known
> risk exposure entirely. Seems a touc
On Wed, 2011-05-18 at 14:02 -0400, Adam Jackson wrote:
> On 5/18/11 1:44 PM, Adam Williamson wrote:
> > On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
> >> On 5/18/11 1:22 PM, Kevin Kofler wrote:
> >>> Adam Williamson wrote:
> # There must be no known remote code execution vulnerabili
On Wed, 2011-05-18 at 14:40 -0400, Simo Sorce wrote:
> Is it unthinkable to respin the images with those fixes ?
> Usually the patches are quite simple to backport, and we are talking
> about a limited set of bugs (remote root exploit on install) after all.
Unthinkable, no, but there are various
On Wed, 2011-05-18 at 10:44 -0700, Adam Williamson wrote:
> On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
> > On 5/18/11 1:22 PM, Kevin Kofler wrote:
> > > Adam Williamson wrote:
> > >> # There must be no known remote code execution vulnerability which could
> > >> be exploited during inst
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote:
> Hey, all. The topic of whether and which security issues should block
> releases has come up several times before. While we haven't actually had
> many really serious security issues to worry about since the
> introduction of the current
On Wed, 2011-05-18 at 19:22 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Hey, all. The topic of whether and which security issues should block
> > releases has come up several times before.
>
> Indeed it has. The decision was always that it's not a good idea. I don't
> see how the situ
On 5/18/11 1:44 PM, Adam Williamson wrote:
> On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
>> On 5/18/11 1:22 PM, Kevin Kofler wrote:
>>> Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could
be exploited during installation or during use
On Wed, May 18, 2011 at 10:44:16AM -0700, Adam Williamson wrote:
> Well, I think his point is that it's almost certain that some 'unknown'
> exposures will become 'known' during the life cycle of a release, at
> which point the live images we release three months previously are
> vulnerable to a kn
On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
> On 5/18/11 1:22 PM, Kevin Kofler wrote:
> > Adam Williamson wrote:
> >> # There must be no known remote code execution vulnerability which could
> >> be exploited during installation or during use of a live image shipped
> >> with the release
On 5/18/11 1:22 PM, Kevin Kofler wrote:
> Adam Williamson wrote:
>> # There must be no known remote code execution vulnerability which could
>> be exploited during installation or during use of a live image shipped
>> with the release
>
> This is just completely and utterly moot considering that th
On 05/18/2011 05:18 PM, Adam Miller wrote:
> On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote:
>> On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote:
>>> On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
>>> Given that we ship selinux on by default shoul
Adam Williamson wrote:
> Hey, all. The topic of whether and which security issues should block
> releases has come up several times before.
Indeed it has. The decision was always that it's not a good idea. I don't
see how the situation has changed to warrant beating that dead horse again.
> # Th
On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote:
> On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote:
> > On 05/18/2011 03:57 PM, Adam Williamson wrote:
> >> Feedback please! Thanks:)
> > Given that we ship selinux on by default should this proposal only be
> > applicable to exp
On 5/18/11 11:57 AM, Adam Williamson wrote:
> # There must be no known remote code execution vulnerability which could
> be exploited during installation or during use of a live image shipped
> with the release
Seems reasonable at first glance.
One anecdotal experience: FC5 (wow) shipped with an
On Wed, 2011-05-18 at 16:28 +, "Jóhann B. Guðmundsson" wrote:
> On 05/18/2011 03:57 PM, Adam Williamson wrote:
> > Feedback please! Thanks:)
>
> Given that we ship selinux on by default should this proposal only be
> applicable to exploits/vulnerability that selinux cant catch and prevent
>
On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote:
> On 05/18/2011 03:57 PM, Adam Williamson wrote:
>> Feedback please! Thanks:)
> Given that we ship selinux on by default should this proposal only be
> applicable to exploits/vulnerability that selinux cant catch and prevent
> which leaves us
On Wed, May 18, 2011 at 08:57:17 -0700,
Adam Williamson wrote:
>
> # There must be no known remote code execution vulnerability which could
> be exploited during installation or during use of a live image shipped
> with the release
>
> Points to consider:
I think there may be some remote expl
On 05/18/2011 03:57 PM, Adam Williamson wrote:
> Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be
applicable to exploits/vulnerability that selinux cant catch and prevent
which leaves us with https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote:
> # There must be no known remote code execution vulnerability which could
> be exploited during installation or during use of a live image shipped
> with the release
>
> Points to consider:
One more 'point to consider' that I forgot: for
Hey, all. The topic of whether and which security issues should block
releases has come up several times before. While we haven't actually had
many really serious security issues to worry about since the
introduction of the current release criteria system, I think it's
certainly something we should
31 matches
Mail list logo
