Criterion proposal: security

["Jóhann B. Guðmundsson"]

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