Das Wiki ist umgezogen und befindet sich nun unter https://wiki.mageia.org/en/Hauptseite-de . Bitte nutzen Sie das neue Wiki.
Wenn du diese Seite verändern willst, so melde dich einfach an und klicke auf den Tabulator Bearbeiten. Betrachte auch andere Seiten verbessern und betreuen.
Inhaltsverzeichnis
Übersicht
Dies ist der erste Durchlauf zur Formalisierung von Aktualisierungsgrundsätzen für eine veröffentlichte Version. Diese Dinge sind nicht in "Stein gemeisselt", aber wir benötigen Grundsätze wie wir mit der veröffentlichung von Aktualisierungen für mag1 umgehen, und wir können den Prozess verfeinern, wenn wir Verbesserungen/Mängel finden. Meines Erachtens gibt es mindestens zwei Charakterisierungen einer Version, die wir um jeden Preis vermeiden wollen:
- Mageia ist langsam bei der Fehlerbehebung und bei der Veröffentlichung von Aktualisierungen
- Mageia veröffentlicht regelmäßig ungetestete Veröffentlichungen, die andere Dinge beschädigen
While we all know "stuff happens" and the occasional bad update gets out, we all need to do due diligence to release timely, fully QA'd updates.
Purpose
An update shall be issued to either correct a defect in an application or packaging (bug) or to address a security vulnerability. Ref: Bug Policy
Version Policy
For the most part, an update should consist of a patched build of the same version of the package released with the distribution, with a few exceptions:
- Bug fix only release. There is no point in shipping all the fixes as patches if the new version does not contain any new feature.
- Software versions that are no longer supported upstream with updates (firefox and thunderbird seem to fall into this category these days)
- Software that is version-bound to an online service (games, virus scanners?) and will only work with the latest version.
- We will make exceptions for packages that did not make it into mga1 and are additions to the distribution, provided they do not impact any other packages and can pass full QA.
Updates are not the appropriate place for packages created to satisfy certain user's urges for "the latest". These types of builds belong in backports.
Roles
Several groups are involved in the request for, creation, testing, and release of updates:
Community (anyone)
(Note: The more complete the work here, the faster we can release timely updates):
- Identification of issue.
- Report bug
- locate patches and attach to bug
- identify relevant entries in other bug databases, security issue databases
- locate POC (Proof of Concept) that illustrates the vulnerability and attach to bug
- test and provide feedback as updated packages appear in testing media
Bug Triage Team
- Review bugs for completeness
- Request additional information if needed
- Assign bug to maintainer
Maintainer (or any interested packager)
- Build updated package with fixes (if the bug is not already assigned to you, assign it to yourself, so others know you're working on it)
- If the version didn't change, leave mkrel as is and '%define subrel 1'
- If it's an update to a new version: use '%mkrel 1' without subrel
- Do at least some initial QA to check that the application/fix works, for a security update a link to the related upstream security announcement or CVE should be provided, also a proof-of-concept (POC also known as exploit) should be provided if available to check if the update fixes the security issue reproducibly
- Submit the package to updates testing. Check the mgarepo page for the procedure to submit the package.
- Write the update announcement/advisory in the bug report used to validate that update Example update advisory announcement
- Reassign the bug to qa-bugs@ml.mageia.org (add a comment in the bug with the package version/release at re-assign, should be already contained in said advisory/announcement)
- Lists ALL SRPMS needed for the update see why in bug 3949
QA Team (How to check and validate an update)
- Test that package(s) will install on all supported architectures
- Ensure that package(s) can update from the previous version(s)
- Ensure that the specific issue has been addressed and the application still performs as expected
- For a security vulnerability, if a POC is available and within QA's skills to test, test that the new version is immune to the vulnerability (QA can defer to Maintainer or Security Team for guidance or assistance)
- If a package fails QA, loop back to the bug with comments and repeat the fix/package/test cycle until we reach satisfactory results.
Security Team
- Monitor security mailing lists and other sources of security information for issues affecting supported releases, as well as Cauldron
- http://oss-security.openwall.org/wiki/mailing-lists
- http://osvdb.org/ (once you have an account, there's an aggregator that will forward you selected vendor's update announcements)
- Open bugs or notify maintainer of issues (as always, a bugzilla entry is something concrete people can work off of and ensures things don't "fall through the cracks")
- Design POC (Proof Of Concept) if necessary/possible to test whether updated build is immune to the issue
- Work with Maintainer and QA for any security specific issues with patches, application behavior.
- Participate in closed vendor-cooperation security lists and ensure we comply with embargo agreements. Maintain a presence such that we become a trusted member of the security community.
Sysadmin Team
- Push the package from updates_testing to updates, using a script
- Send mail on the list ( using a script )
- FIXME publish update announcements to web pages
- FIXME delegate to someone else this job ( proper setup of sudo, etc )
