Josh Bressers bressers at redhat.com
Thu May 19 12:57:46 UTC 2011
wrote:
> Perhaps the correct answer is to have firstboot update the system
> for a user (do it in the background so they can still login do things).
Should we do that ? I mean an update in the background without
user's knowledge, c
>if a remote root hole is found 2 days after release, what do we do?
>(the current answer is nothing)
One can suppose a re-spin is possible, given sufficient motivation.
There already exists some informal respin activity. For example, see:
http://jbwillia.fedorapeople.org/
--
test mailing li
- Original Message -
>
> 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.
>
I think it makes sense to address these prior to a relea
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
2011/5/18 Adam Jackson :
> On 5/18/11 1:14 PM, J B wrote:
>
>> So, even a local DoS could qualify for a security blocker.
>
> Denial of service is not a security issue. Full stop. Those words mean
> different things. Do not conflate them.
IMHO this is a matter of definition. It seems to me that
Hi,
2011/5/18 Adam Williamson :
> On Wed, 2011-05-18 at 19:14 +0200, J B wrote:
>> Hi,
>>
>> > I don't know if anyone
>> > would want to go as far as making DoS vulns release blocking, but speak
>> > up if you would! (Of course there is again the local/remote distinction
>> > to consider there: 'a
On Wed, 2011-05-18 at 13:45 -0400, Adam Jackson wrote:
> On 5/18/11 1:14 PM, J B wrote:
>
> > So, even a local DoS could qualify for a security blocker.
>
> Denial of service is not a security issue. Full stop. Those words mean
> different things. Do not conflate them.
Well, it's considered
On 5/18/11 1:14 PM, J B wrote:
> So, even a local DoS could qualify for a security blocker.
Denial of service is not a security issue. Full stop. Those words mean
different things. Do not conflate them.
- ajax
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.
On Wed, 2011-05-18 at 19:14 +0200, J B wrote:
> Hi,
>
> > I don't know if anyone
> > would want to go as far as making DoS vulns release blocking, but speak
> > up if you would! (Of course there is again the local/remote distinction
> > to consider there: 'all DoS vulns' would be a much tighter st
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
Hi,
> I don't know if anyone
> would want to go as far as making DoS vulns release blocking, but speak
> up if you would! (Of course there is again the local/remote distinction
> to consider there: 'all DoS vulns' would be a much tighter standard than
> 'remote DoS vulns').
I think the "use of a
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 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/test
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
16 matches
Mail list logo
