On 10/25/2012 06:47 PM, Adam Williamson wrote:
On Thu, 2012-10-25 at 10:17 +0000, "Jóhann B. Guðmundsson" wrote:
On 10/25/2012 12:06 AM, Adam Williamson wrote:
What do folks think of this? Anyone want to tweak what severity issues
we block for when, or think the approach is bad? Thanks! We might not
want to start at Alpha, on the basis that Alpha is supposed to be for
testing *only* and should never have sensitive data committed to it, for
instance: we could combine the proposed Alpha criterion into the Beta
one.
I'm not so sure we want to add security related clause to the criteria
since security flaws are just bugs
I'm not quite sure what you mean...all blocker bugs are 'just bugs',
some bugs are important enough that we shouldn't make releases with
those bugs in them. We can't really claim that security bugs violate any
of the existing criteria because the existing criteria are focused on
functionality, not security. A flaw which would let anyone on the
internet read all your data does not, so far as I can see, violate any
of the existing criteria (unless you use the 'escape clause' of 'any
high severity bug in a critpath package is a blocker, but in practice,
we have never really applied that). I think it should constitute a
blocker...if others agree, then we need a criterion to express that,
since we don't currently have one.
but if people insist that we add one I think we should only apply that
security criteria only to final so we wont release the distribution
with *known* security fiaw.
Yeah, I did consider that; it's a viable line to say that Alpha and Beta
are test releases so security flaws are not really that significant, you
should be using them only for test purposes and trusting no valuable
data / systems to them. I think that may well be plausible for Alpha.
For Beta it's a bit more problematic, because in practice, 'testing a
Beta' can involve giving it at least some exposure to sensitive
data/processes. Say you run Fedora on 1,000 client boxes (I don't know
if anyone does, but just supposing...) at your
school/enterprise/whatever, with a central server containing important
data. I think 'testing' Fedora XX Beta is probably going to involve
deploying it on one 'test' client in your setup...which is probably
going to interact with your actual 'production' network in some way. So
I think it might be hard to maintain that we don't need to care about
security at all for the Beta.
Beside the obvious point that a "regular" bug risk doing just that as
well and we already have an policy that is in place to deal with
security updates in general, what are we supposed to do if upstream does
not provide security fixes for a particular release, and if backporting
the fix would be impractical,delay the release indefinitely until they do?
I've cc the Releng community to get their input on this + I think we
discuss and decide to stay away from security related criteria in the past.
JBG
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
