I put it in the wrong words i guess. I meant "up to date". No matter for what apache tree i decide, I want to be able to install a fixed version of it in short time. When I install a piece of server software and i can disable features that i dont want/need, i can do that at compile time. While server software in linux distributions is often build to support a broad public, you may want to build your own smaller thing. Sometimes its "security feature" against "security fix": e.g. I wanted to use the privsep option in OpenSSH, while the SuSE package was a fix of the actual version, IMHO it increased the overall security of that service. Concerning openssl i decided to use the up to date source, instead of the SuSE packages. Again: i meant "up to date" mainly patchwise. SuSE is fast with their bugfixes usually, but sometimes you want to be able to bugfix as soon as you can grab the sourcecode. Since i have to test it anyways, if it breaks something on production machines, i decided to compile and test, instead of waiting for the rpm and test. Concerning the "security fix" against "security features" issue: Depending on the thing you use your DBMS for, the new features can be considered an improvement (of the overall security, the application security, whatever). The drawback is that there is new code. But somtimes the gain of the new features outweighs the "code risk".
7.3 doesn't contain security *fixes* (AFAIK) but new security *features* and that's a different thing.
Right :). And some of them have been awaited longtime. Network security maybe one motivation. Features that enable your developers to write a more secure application DBMS wise, can increase security too. Oh and theres also this line in the changelog: Security fixes for password negotiation memory allocation (Neil) Know what that exactly means, or how relevant this is security wise? peace, Tom
participants (1)
-
Thomas Seliger