On 05/18/2011 12:02 PM, JB wrote:
JÃhann B. GuÃmundsson <johannbg <at> gmail.com> writes:... The QA community is not a security or an risk assessment team. We leave that part up to security team which possesses the necessary skill resource and experience to correctly evaluate and assess any concern raised related security ( or lack there of ) within the project. ...That would be right from the formal point of view, as an additional or follow-up venue to discuss security problems.thus security related questions are off topic for this list and should be asked on Fedora's security mailinglist [1] instead. ...I think you are playing a censor here ... "Off-topic" ? That's a little bit a mental overstretch, considering what is affected. This discussion is off topic for this list again QA does not do security auditing on bits so it serves absolutely no purpose discussing them here we have absolutely no saying in those matters. If you think we should start another topic and we can bring that up on a meeting and if deemed relevant contact the security team and FESCO Security related matters are handled by the security team which then takes the necessary steps to deal with it either in patches, with upstream or by dealing with the issue on a more distro wide level with FESCO. You did not protest when the issue was raised here on this list in the first place, did you ? You would look foolish, methinks ... Me looking foolish that would not be for the first time and certainly not the last but the reason I have no mention that this was off topic before along with all the gnome design issues that belonged on the desktop list is simply because I've been busy this issue was discussed first on the devel list then for some odd reason it leaked or reappeared here and it got exactly the same responses. There are more DoS attack venues than just /run/user/ and /dev/shm. ( as has been stated before ) The problem ( Again as have been stated many times ) with /dev/shm is that tmpfs doesn't do quota which is the key problem here and this issue needs to be properly addressed and solved upstream ( kernel ) and /dev/shm has existed for years and the knowledge of it's weaknesses as well. Security issues, as any other issues, are part of development process, and are subject to quality assessment all the time during that process, but certainly in the final stage when release decision is made about the product. We ( QA ) certainly cant fix it by implementing some temporary hack which might or might not break something else ( nor would we ) and suddenly deciding to hold of the release now would be a bit odd since this has been known and exploitable for years. This is not even considered regression from previous behaviour your systems are no more at risk now that they have been for previous years. If a proper solution existed to this problem then either the security team would have implemented it by now or FESCO. Again we ( QA ) would have nothing to do with it. Take your issue upstream and you might convince them to put some resource into fixing this which would then appear in 2.6.40 and eventually make it's way here downstream to us. JBG |
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
