Wiki » Herzieningen-beleid-nl

Other languages Deutsch ; English ; Français ; Nederlands ;

Overzicht

Dit is een eerste poging om een ​​updatebeleid (beleid voor herzieningen) voor de uitgebrachte distributie te formaliseren. Dingen staan ​​nog niet vast, maar we hebben een beleid nodig om door te gaan met het uitbrengen van updates voor Mga-current, en we kunnen het proces verfijnen als we problemen/tekortkomingen vinden. Naar mijn mening zijn er ten minste twee karakteriseringen van de distributie die we koste wat kost willen vermijden:

• Mageia is traag met het oplossen van bugs en het uitbrengen van updates
• Mageia brengt routinematig ongeteste updates uit die dingen kapotmaken

Hoewel we allemaal weten dat er "dingen gebeuren" en er af en toe een slechte update uitkomt, moeten we met zijn allen zorgvuldigheid betrachten om tijdige, updates uit te brengen die voldoen aan de criteria voor QA (Quality Assurance, kwaliteitsgaranties).

Doel

Een update moet worden uitgegeven om ofwel een ​​defect (bug) in een applicatie of verpakking te corrigeren, danwel om een ​​beveiligingslek aan te pakken. Ref: Bugbeleid

Versiebeleid

Een update zou over het algemeen moeten bestaan ​​uit een gepatchte build van dezelfde versie van het pakket dat met de distributie is uitgebracht, met een paar uitzonderingen:

• Alleen een fout-herstel. Het heeft geen zin om alle bugfixes als patches te verzenden als de nieuwe versie geen nieuwe functies bevat.
• Softwareversies die niet langer upstream worden ondersteund met updates (Firefox en Thunderbird lijken tegenwoordig in deze categorie te vallen).
• Software die versiegebonden is aan een online-dienst (games, virusscanners?) en alleen met de nieuwste versie werkt.

Wij maken ook uitzonderingen voor pakketten die de weg niet gevonden hebben naar de nieuwste editie van Mageia (Mga current).

Updates zijn niet de juiste plek voor pakketten die zijn gemaakt om te voldoen aan de behoefte van bepaalde gebruikers aan "het nieuwste". Dit soort builds horen thuis in de rubriek backports.

Rollen

Meerdere groepen zijn betrokken bij het aanvragen, maken, testen en vrijgeven van updates:

Community (iedereen)

(Opmerking: Hoe completer het werk hier, hoe sneller we tijdige updates kunnen vrijgeven):

• Identificatie van het probleem.
• Fouten melden.
• Patches zoeken en aan de bug (foutmelding) koppelen.
• Relevante vermeldingen opzoeken in andere bug-databases en databases met beveiligingsproblemen.
• Zoek een POC (Proof of Concept, oftewel exploit) die de kwetsbaarheid illustreert en koppel deze aan de bug.
• Testen en feedback geven als bijgewerkte pakketten in testmedia verschijnen.

Bug Triage Team

• Foutmeldingen (bug reports) controleren op volledigheid.
• Indien nodig aanvullende informatie opvragen.
• De fout toewijzen aan een beheerder.

Beheerder (of een geïnteresseerde verpakker)

• Bijgewerkt pakket bouwen met oplossingen (als de bug nog niet aan u is toegewezen, wijst u deze toe aan uzelf, zodat anderen weten dat u eraan werkt).
  • Als de versie niet is gewijzigd, laat u mkrel zoals het is en '%define subrel 1'
  • Als het een update is naar een nieuwe versie: gebruik '%mkrel 1' zonder subrel

BELANGRIJK: subrel moet boven/vóór mkrel worden gedefinieerd om te werken

• Voer ten minste een eerste QA uit om te controleren of de toepassing/oplossing werkt. Voor een beveiligingsupdate moet een link naar de gerelateerde upstream beveiligingsaankondiging of CVE worden verstrekt. Ook moet een proof-of-concept (POC ook bekend als exploit) worden verstrekt indien beschikbaar, om te controleren of de update het beveiligingsprobleem reproduceerbaar oplost.
• Dien het pakket in voor updates-testing. Controleer de mgarepo pagina voor de procedure om het pakket in te dienen.
• Schrijf de update aankondiging/advies (update advisery announcement) in het bug-rapport dat is gebruikt om die update te valideren (Example update advisory announcement).
• Wijs de bug opnieuw toe aan qa-bugs@ml.mageia.org (voeg een opmerking toe in de bug met de pakketversie/release bij opnieuw toewijzen, dit zou al in bovengenoemd advies/aankondiging moeten staan). Als de update meer dan één bug oplost, wijs er dan slechts één opnieuw toe.
• Geeft ALLE SRPMS weer die nodig zijn voor de update (zie waarom in bug 3949) en ook alle RPM's, omdat QA moet weten wat er getest moet worden.

QA-team (Hoe u een update controleert en valideert)

• Test of pakket(ten) op alle ondersteunde architecturen worden geïnstalleerd.
• Zorg ervoor dat pakket(ten) kunnen worden bijgewerkt vanaf de vorige versie(s).
• Zorg ervoor dat het specifieke probleem is opgelost en dat de applicatie nog steeds presteert zoals verwacht.
• Voor een beveiligingskwetsbaarheid, als er een POC beschikbaar is en binnen de vaardigheden van QA valt om te testen, test dan of de nieuwe versie immuun is voor de kwetsbaarheid (QA kan zich tot de beheerder of het beveiligingsteam wenden voor begeleiding of assistentie).
• Als een pakket QA niet doorstaat, ga dan terug naar de bug met opmerkingen en herhaal de cyclus fixen/verpakken/testen totdat we bevredigende resultaten bereiken.

Beveiligingsteam

• Controleer beveiligings-mailinglijsten en andere bronnen van beveiligingsinformatie op problemen die betrekking hebben op ondersteunde releases, evenals Cauldron,
  • https://oss-security.openwall.org/wiki/mailing-lists
  • https://lwn.net/Alerts/
  • https://osv.dev/list
• Open een foutmelding (bug report) of informeer de beheerder over problemen (zoals altijd is een bugzilla-item iets concreets waar mensen mee aan de slag kunnen en dat ervoor zorgt dat dingen niet "door de mazen van het net glippen")
• Ontwerp een POC (Proof Of Concept) indien nodig/mogelijk om te testen of de bijgewerkte build immuun is voor het probleem
• Werk samen met de beheerder en QA voor elk beveiligingsspecifieke probleem, om het gedrag van de patches en van het pakket te onderzoeken.
• Neem deel aan besloten beveiligings(mailing)lijsten van leverancierssamenwerkingen, en zorg ervoor dat we ons houden aan embargo-overeenkomsten. Door onze aanwezigheid te laten zien, worden we een vertrouwd lid van de beveiligingsgemeenschap.

Sysadmin Team

• Het pakket pushen (doorsturen) vanuit updates_testing naar updates, met behulp van een script
• E-mail verzenden op de lijst (met behulp van een script)
• FIXME publiceert de update-aankondigingen op webpagina's
• FIXME delegeert deze taak aan iemand anders (juiste instelling van sudo, enz.)

Referenties

• Hoe een update indienen bij updates_testing
• QA-proces voor het valideren van updates