On Fri, 2012-10-26 at 09:35 +0000, "Jóhann B. Guðmundsson" wrote: > 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 ) You're derailing again. The fact is that we don't release official updates of the install images and therefore bugs in the install path cannot be fixed via updates. If this changes then obviously we could consider changes to the release criteria and validation process, but right now, it's a *fact*: we do not release installer updates, therefore we have to maintain the distinction between bugs that can be fixed with updates and bugs that cannot. Discussion of whether we _ought_ to release updated installer images is fine and good, but it should be separate from this. > 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. I don't think it really needs reiterating, but again, it is inarguably the case that it is possible for there to be security issues we cannot fix with updates. All code is potentially vulnerable to security issues, we ship code that cannot be changed by our update process, ergo there is a possibility of security issues we cannot fix with updates. QED. Specific examples of this are just examples. > 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! Again I don't really see the relevance to this debate. That has been discussed before and it's been decided that it does not constitute a security bug in Fedora as it's an intentional configuration choice where we made the tradeoff between convenience and security in the direction of security. Whenever you're building something as complex as a distribution there will be occasions where you have to decide between convenience and security; when these are properly considered and the decision is made on the side of convenience, that does not constitute a security bug. Even if you want to reanimate the question of whether this particular decision is correct, it really doesn't impact on the question of whether we should consider security bugs as blocker bugs in some circumstances, so far as I can see. It's just yet another tangent. > 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. No, I think you're misrepresenting things there. There is a debate about whether this is actually a 'bug' or not, which really just means it's another case of what I mentioned above: we're considering an issue and deciding the trade-off between security and convenience. I am not proposing this criterion with the intent that, if it's accepted, I will post to the bug 'HAHA we just added a security criterion therefore this is a blocker bug and you can't argue!'. That's not the idea at all. Whether we decide to take security bugs as release blockers or not does not answer the question of _whether this is considered a 'bug' or not at all'. That would still be up for debate. But, theoretically speaking, if we were to accept that this was a security bug, then under the proposed criteria it may count as a blocker bug. Without any criteria it definitely wouldn't. I was proposing the criterion not because I want to use it as a stick to beat anaconda with, but simply because I wanted to raise the question of whether it makes sense in general to hold our releases for some security bugs. Right now we have no capacity to do that. > 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 )... Okay, so if we boil it down, your position is that we shouldn't ever block the release for security issues, even if they're critical and not fixable with updates, we should just make 'best effort' to fix them, i.e. take them as NTH? Roger. > 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. I don't think having security criteria really complicates the release process that much, especially if we go towards only considering really bad issues that can't be fixed with updates as blockers. As Vincent says, if you look through history, there really aren't a lot of those, it's not like we'll be inundated with blockers. My expectation is we'd get maybe one or fewer per cycle. It's really just a safety valve, I'm a bit worried about the case where we find some huge security vuln in anaconda the day before go/no-go. It could happen. Again, this is absolutely not an attempt to do an end-around the specific anaconda bug I cited here. That's not the idea at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
