PHP-bronpatch voor 7.4, 8.0 en 8.1 uitgelegd

Een PHP-bronpatch is een wijziging voor de broncode van PHPPHP is de programmeertaal waarmee veel websites, zoals WordPress-sites, hun pagina's maken op het moment dat een bezoeker erom vraagt. die een beheerder verwerkt in een eigen build, voordat die installatie wordt gebruikt.

Zoek je naar een PHP 7.4 backport patch, dan wil je waarschijnlijk weten wat je nu kunt doen. Begin bij degene die PHP voor jouw website beheert. Vraag of die een gepatcht pakket kan leveren of zelf een build onderhoudt.

Alleen weten dat er een patch bestaat, beantwoordt nog niet hoe jouw website die reparatie krijgt.

De aankondiging op php.net vermeldt dat het PHP-securityteam minimale bronpatches voor PHP 7.4, 8.0 en 8.1 publiceerde. Sommige distributies en LTS-leveranciers leveren eigen gepatchte versies. De bronpatch is dus één mogelijke route.

Lees PHP backpatchenPHP backpatchen betekent dat je een beveiligingsfix laat terugzetten naar een oudere PHP-versie, zonder direct naar een nieuwe versie over te stappen. om die route naast een pakketupdate en een upgrade te leggen.

Wat publiceerde het PHP-team?

Het vastgelegde feit gaat over minimale wijzigingen in de broncode voor drie oude PHP-versies. Het noemt geen nieuwe reguliere release voor die versies. Presenteer de patch daarom niet als een nieuw versienummer dat iedere hoster klaar heeft staan.

Vraag je beheerder welke vorm van de reparatie voor jouw installatie beschikbaar en controleerbaar is.

Oude versies bereiken end of lifeEnd of life (EOL) betekent dat de maker een versie van software niet meer bijwerkt, ook niet als er een beveiligingsprobleem wordt gevonden.. PHP 8.1 en ouder krijgen volgens dezelfde feitenbron geen updates meer van het PHP-project. De genoemde bronpatches veranderen die supportstatus niet in een toezegging voor toekomstig onderhoud.

CISA adviseert systemen met PHP 8.1 of ouder offline te houden totdat ze zijn gepatcht of bijgewerkt. De beveiligingsstatus geeft de vastgelegde stand weer.

Een backportEen backport is een oplossing uit een nieuwe versie van software die ook in een oudere versie wordt gezet, zodat je die niet hoeft te vervangen. gaat over een gerichte reparatie op een oudere basis. Vraag je beheerder daarom welk probleem zijn voorgestelde build oplost en wat buiten de opdracht valt. Houd het gesprek bij de fix, het gebruikte materiaal en de controles.

Je hoeft daarvoor geen aanval na te bouwen of details over misbruik te verzamelen.

Voor wie past zelf bouwen?

Kies deze route alleen als een beheerder het bouwen en het onderhoud kan dragen. Vraag vooraf wie de broncontrole uitvoert, wie de testomgevingEen stagingomgeving is een afgeschermde kopie van je website waarop je updates uitprobeert voordat ze live gaan. beheert en wie de wissel terug kan draaien. Laat die afspraken vastleggen.

Als niemand die taken wil uitvoeren, ga dan terug naar de pakketroute of bespreek een upgrade.

Heb je alleen een hostingaccount, gebruik dan de hostergidsen om je huidige versie vast te stellen. Stuur je hoster vervolgens een gerichte vraag over de beschikbare route. Een eigen build is geen klus om tussen andere wijzigingen door te proberen.

Spreek apart af wat er wordt onderzocht en wanneer iemand een besluit voorlegt.

Eerst de herkomst controleren

Laat de beheerder het materiaal vanaf www.php.net ophalen. Laat de handtekening controleren volgens de GPG-informatie van PHP. Vraag om het resultaat van die controle in het werkverslag.

Ga bij een onduidelijke herkomst of mislukte controle niet door naar installatie: laat de beheerder eerst dat punt oplossen.

Bewaar welke broncode en welke patch zijn gebruikt, samen met de datum en de verwijzing naar php.net. Vraag de beheerder uit te leggen waarom deze combinatie past bij jouw installatie. Daarmee kan een volgende beheerder begrijpen wat er is gebouwd.

Een losse bestandsnaam zonder herkomst geeft daarvoor te weinig houvast.

Naast de bestaande installatie bouwen en testen

Laat de build in een eigen prefix maken, een aparte installatieplek naast de bestaande installatie. Spreek vooraf af hoe de beheerder kan terugvallen. Laat de huidige installatie tijdens het uitproberen intact.

Dit artikel geeft bewust geen bouwopties: de beheerder moet het plan voor jouw omgeving onderbouwen en controleren.

Laat eerst een testkopie van de website op de nieuwe build beoordelen. Maak samen een korte lijst van wat moet werken. Denk aan inloggen, zoeken, formulieren en de belangrijkste beheertaken.

Laat de uitvoerder de uitkomsten opschrijven. Een test met alleen de homepage is niet het hele gebruik van je website.

Plan daarna pas een eventuele wissel. Benoem wie de wijziging mag uitvoeren en wie de website direct erna controleert. Leg vast bij welke uitkomst de beheerder terugvalt en hoe hij daarover rapporteert.

Laat na de wissel ook bevestigen welke installatie het domeinEen domeinnaam is het webadres waarmee bezoekers jouw website vinden, zoals jouwbedrijf.example. nu gebruikt. Bewaar dat antwoord bij het testverslag.

Maak ook een onderhoudsplan

Vraag wie de eigen build na deze reparatie onderhoudt. Spreek af wanneer je opnieuw beoordeelt of deze route nog past. Gebruik de ondersteunde PHP-versies voor het gesprek over een volgende versie.

Een afgeronde bouwklus is een ander besluit dan langdurig op dezelfde basis blijven.

Wil je die overstap voorbereiden, bespreek dan een PHP-upgrade met je beheerder. Vraag bij je aanvraag welke informatie nodig is om de site te beoordelen. Houd de bouwgegevens beschikbaar, zodat de volgende beheerder niet hoeft te raden wat er is veranderd.

Zo sluit het upgradeplan aan op de installatie die werkelijk draait.

Niet zeker welke route past?

Begin met de PHP exposure check. Gebruik daarna het hulpformulier en vermeld je versie, hoster en wie de server beheert. Geef aan of er al een pakket of eigen build is voorgesteld.

Deel geen inloggegevens; het eerste doel is een uitvoerbare route kiezen.