On 10/25/2012 09:16 PM, Adam Williamson wrote:
Sure, that's the reason for the potential distinction between bugs that
_can_ be fixed with updates and those that_can't_. This discussion was
prompted by a specific bug -
https://bugzilla.redhat.com/show_bug.cgi?id=868519 - which can't be
fixed with an update, because it's an issue in anaconda. Just like any
bug in anaconda, we can't fix it with a post-release update.
For the first we could fix this with an post-release update but as you
know certain people did not want that even if there was sufficient man
power that was willing to maintain and do that from the community
( fedora-unity )
it although I agree with vincent in c14 this is not a bug as I read it
this is working as they intend it...
C3... "This is working as we intend it."
C5... "kickstart does not allow for expressing encrypted passphrases,
and we have no plans to add that."
From my pov they simply should not store the password line et all.
The bottom line is we already have an policy with regards to security
updates which worst case scenario would be pulled in with an
post-release 0 day update and security updates they themselves can bring
a plethora of brokenness with them just like any other bug.
To give you an example install of an another security issue we have been
knowingly shipping for years off the dvd install sshd is enabled by
default exposing it to bruteforce attacks immediately out of the box (
how long to think it's going to take with an cloud and if the host is on
edubandwith ) while having no means of notifying the end user when it's
happening. We allow that!
Anaconda developers can always make the case since the file is owned and
readable by root that the end user has an bigger issue to deal with if
someone can access it ( classic case of security theater )...
So now you want to create/tighten a security criteria because of an
political debate with the maintainers and this hits
"what are we supposed to do if upstream does not provide security fixes
for a particular release" as I mentioned before.
In the end of the day in the release process we need to treat security
bugs as NTH as in we pull them if....
a) we know about
b) it does not break anything
c) cant be fixed with an 0 day update
instead of delaying the release indefinitely ( best effort approach )...
Personally I dont think we should have security release criteria to
complicated the release process and that Anaconda implementation debate
should be address by FESCO after all they exist for that exact purpose
and they are the once that approved the newUI feature even when it was
no way ready ( and still is not ) so they just get to eat their own dog
food.
JBG
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
