Angesichts der gegenwärtig hohen Frequenz, mit der das TYPO3 Security Team Problemmeldungen zu Dritt-Extensions herausgibt, ist bei uns gerade die Frage aufgetaucht, wie man die Wahrnehmung und die administrative Umsetzung erleichtern kann. Eine Idee dazu (neben den ohnehin im Raume stehenden Überlegungen zur Automatisierung) ist die Einführung eines “Patchday”, also eines festen periodischen Termins, zu dem Fixes veröffentlicht werden (von etwaigen Zero-Day-Exploits, also bereits aktiv ausgenutzten, einmal abgesehen.)
Was haltet ihr davon?

[...] Blog” auch schon von einem “Patch Day” die rede. Dazu sucht Ekkehard in dem aktuellen Beitrag ein wenig Feedback. Veröffentlicht von Tim Lochmüller Abgelegt unter Dev, TYPO3, Bugs, [...]
<p>Einen “offline”-Kommentar dazu habe ich gerade erhalten, und zwar: <code>”Patchday ja, aber nicht unbedingt in festgelegtem Rhythmus.”</code><br />
Auch nicht schlecht… oder?</p>
Ich finds ganz gut
lg georg
ich würde es auch begrüßen.
So läßt sich das ganze auch viel besser für Admins planen. Ich wäre aber für einen regelmäßigen Patch-Day, ansonsten schläft das ganze wieder ein. Und wenn mal zu einem Patch-Day herauskommt , das nichts zu patchen , nun gut dann ist es halt so
Hallo,
ich finde die Idee des “Patch-Day” auch sehr sinnvoll.
Wie schon erwaehnt, kann der Admin/Entwickler sich dann darauf einrichten und ggf. auch seine Kunden informieren, dass Redakteure sich an Tag X nicht einloggen koennen weil Updates eingespielt werden…
Wie gesagt, eine sehr gute Idee.
Gruss
Alex
Hi!
Einen Patch-Day fände ich eigentlich sehr sinnvoll, allerdings sollte dann eine einzelner Patch bereitgestellt werden, der die Lücken in allen betroffenen Extensions (oder auch im Core) schließt.
Darüber hinaus fände ich es sinnvoll, wenn eine T3-Installation abfragen könnte (z.B. vom TER) ob eine Extension (noch) sicher ist. Ggf. könnte eine als gefährlich erkannte Extension dann vom Admin oder sogar automatisch deaktiviert werden.
Das Kernproblem scheint mir aber zu sein, dass es nicht genügend Menschen gibt, die Extensions auf Sicherheit überprüfen (man könnte auch sagen, es gibt zu viele Extensions
…
CU
maxhb