Stefan Kunze wrote:
Am Mittwoch, 5. August 2015, 23:17:46 schrieb Bjoern Voigt:
My personal opinion: Having 'bleeding edge' packages is a good
strategy in relation to security. I prefer bleeding edge packages
over back-ported security patches.
This is basically security by (version) numbers. In the end it does not really matter if its backported or new Versions. The only thing missing in backported versions are new features (and even those can in exceptions be backported)
It depends. The reasons why I prefer bleeding edge software over old software with backported security patches are: - Sometimes the security patch has dependencies to other code changes. A good distribution maintainer with enough time sees the dependencies and handles them right. But who has enough time? - Usually more upstream developers tested a new release compared with an old release with backported patches. - Automated security testing software often does not detect the backported patches. The testing software often only evaluates the version numbers. This produces false positives. - An upstream developer sometimes does not see, that he fixed a security hole during development of new releases. Package maintainers have no good changes to detect such problems, if the upstream developer or other people do not detect them. - Not every security improvement fixes a real security bug. In my example (Sendmail with or without SSL 3) the Ubuntu maintainers did not provide any solution for disabling SSL 3 on Sendmail. openSUSE provides a solution (Sendmail 8.14.9 has options to disable SSL 3), but does not automatically deactivate SSL 3 on openSUSE <= 13.2. So I think, that distribution maintainers estimate Sendmail with SSL 3 as a low severity problem, - Security improvements on base libraries like OpenSSL often can not be backported, because too much packages have dependencies to them and testing and fixing all the dependent software is too much work. Things become difficult, if the security library patches change the ABI.
If course security is not the only objective for a Linux
distribution. Functionality, stability, the amount of packages etc.
are important too. I liked the old development model of openSUSE.
So did I. But if I can't be maintained what is the point?
Some years ago we had 4 openSUSE releases each year.
I'm following openSUSE since 2006 and we never had 4 Releases in a year
I use SuSE/openSUSE since around 1996/1997. I think, we had 4 release a year around 2000 but I am not sure.
openSUSE Tumbleweed and Leap are both big steps in opposite directions.
Currently I am not happy with both for production systems.
Tumbleweed on Productionsystems I can understand but Leap - we are not even in the first Beta Version and you already judge it as insufficient?
Of course I currently could not judge the quality of Leap. But I heard that the decision to go for Leap is made. The community can not change the decision, but we probably can influence the details. (For instance I heard, that the community has prevailed, that openSUSE Leap will use Kernel 4.1 instead of an old 3.x Kernel lile SLES 12. Of course Kernel 4.1 will be old too at the Leap 42.1 release date.) Personally I would recommend to think about using bleeding edge security software (libraries and applications). Currently I simulate this with additional repositories like [server:mail] or [server:database]. I hope that we can use such (good maintained and relatively stable) repositories on Leap too.
On my
personal desktops I will probably go to Tumbleweed.
So do I
Good. Greetings, Björn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org