Solar @ Dongen: http://solar.searchy.net/ - Penpal International: http://ppi.searchy.net/
Security-fixes wel, functionele fixes niet volgens mij.
| Olympus OM-D EM10 mk2 | m.Zuiko 14-42mm f/3.5-5.6EZ | m.Zuiko 40-150mm f/4-5.6 R | m.Zuiko 60mm f/2.8 | 2x Godox v860 | Godox X1 |
Is er rede dat ze als het ware onafhankelijk van het php team php aanpassen?
Ik kan me voorstellen dat ontwikkelaars van php erg veel energie erin steken om hun software op orde te hebben. Het lijkt me dan extra dubbel op als maintainers van in dit geval debian er nog een schepje bovenop doen voor hetzelfde werk.
Ik kan me voorstellen dat ontwikkelaars van php erg veel energie erin steken om hun software op orde te hebben. Het lijkt me dan extra dubbel op als maintainers van in dit geval debian er nog een schepje bovenop doen voor hetzelfde werk.
Solar @ Dongen: http://solar.searchy.net/ - Penpal International: http://ppi.searchy.net/
Dat is omdat Debian 6 stable is. M.a.w., het verandert niet of er moet een héél fucking goede reden voor zijn.
All my posts are provided as-is. They come with NO WARRANTY at all.
Security heeft wat dat betreft niet zo heel veel met stable te maken... Dat word veel vaker geupdate, ook terwijl het Stable is.
Even niets...
http://www.debian.org/security/faq#oldversion:
Q: Why are you fiddling with an old version of that package?
The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. This is especially true in case of libraries: make sure you never change the Application Program Interface (API) or Application Binary Interface (ABI), no matter how small the change is.
This means that moving to a new upstream version is not a good solution, instead the relevant changes should be backported. Generally upstream maintainers are willing to help if needed, if not the Debian security team might be able to help.
In some cases it is not possible to backport a security fix, for example when large amounts of source code need to be modified or rewritten. If that happens it might be necessary to move to a new upstream version, but this has to be coordinated with the security team beforehand.
Dat is omdat een beveiligingsprobleem een heel fucking goede reden is om iets te updaten. Maar dat zijn altijd patches om het probleem op te lossen, of in een enkel geval (als het niet anders kan) functionaliteit uit te schakelen.FireDrunk schreef op vrijdag 09 december 2011 @ 11:34:
Security heeft wat dat betreft niet zo heel veel met stable te maken... Dat word veel vaker geupdate, ook terwijl het Stable is.
Je zult in een security update verder in principe geen functionele wijzigingen krijgen, of andere versienummers, etc. Zo wel is dat een ontzettende uitzondering.
[ Voor 4% gewijzigd door CyBeR op 09-12-2011 15:57 ]
All my posts are provided as-is. They come with NO WARRANTY at all.
Misschien nog wel interessant, speciaal over PHP en Debian:
Wel handig om te weten.
Bron: http://wiki.debian.org/PHP#Notes_on_PHP_and_securityquote: PHP - Debian WikiNotes on PHP and security
It's highly recommended that you read README.Debian.security in /usr/share/doc/php*.
In short, security support for PHP places a high load on the package maintainers, because of the volume of security-related issues and the difficulty of working with the upstream authors in finding the fixes. As such, PHP security issues are typically triaged with different priorities based on the particulars of the issue.The Debian PHP maintainers work fairly closely with the Debian security (esp. secure-testing) teams, as well as the Ubuntu PHP maintainers, so you can be generally assured that properly reported bugs tagged as security-relevant will be handled as promptly and transparently as possible.
- issues involving features that are broken as designed (safe mode, register globals, etc) are completely ignored
- issues that require a malicious local user (unless there are compelling reasons otherwise) are ignored.
- issues involving unsafe application usage (applications not filtering input before passing to certain functions) are usually given a low priority or sometimes even ignored in favor of reporting bugs against the offending applications
- issues involving remote code execution (buffer overflows, code inclusion, etc) are given the highest priority
As of version 5.2.4-1 the suhosin patch is enabled by default in Debian PHP5 packages.
Wel handig om te weten.
Pagina: 1