Diese Seite enthält eine Auflistung von Teams, Gruppen und Einzelpersonen innerhalb des FreeBSD Projects und beschreibt deren Rolle und Verantwortungsbereiche innerhalb des Projekts. Außerdem finden Sie hier Tätigkeitsbeschreibungen sowie Kontaktinformationen. Um Missverständnissen vorzubeugen, wurden die Bezeichnungen der Teams und Gruppen nicht übersetzt.
Das FreeBSD Core Team bildet den "Vorstand" des Projekts. Es legt fest, in welche Richtung sich das FreeBSD Project entwickelt und verwaltet zusätzlich verschiedene Bereiche des Projekts. Das Core Team wird von den aktiven FreeBSD-Entwicklern gewählt.
Das FreeBSD Documentation Engineering Team legt die Vorgaben für die Committer des Documentation Projects fest und kontrolliert auch deren Einhaltung. Die Doceng Team Charter beschreibt die Aufgaben und Verantwortungsbereiche dieses Teams ausführlich.
Hauptaufgabe des FreeBSD Port Management Teams ist es, dafür zu sorgen, dass die FreeBSD-Port-Entwickler eine funktionierende, stabile, aktuelle und umfangreiche Ports-Sammlung bereitstellen. Dazu koordiniert das Team die Arbeit der Entwickler, die an der Ports-Sammlung arbeiten. Die Portmgr Team Charter beschreibt die Aufgaben und Verantwortungsbereiche dieses Teams ausführlich.
Die Hauptaufgabe des FreeBSD Port Security Teams ist die rasche Reaktion auf Sicherheitsprobleme, die in der FreeBSD Ports-Sammlung auftreten. Sie informieren die Anwender über Bugs, Sicherheitslücken, bekannte Angriffe und andere Risiken. Lesen Sie bitte die entsprechende Wiki-Seite für weitere Informationen.
Das Primary Release Engineering Team erstellt und
veröffentlicht die Zeitpläne für die
Bereitstellung der offiziellen FreeBSD-Releases, verfügt
"Code Freezes" und wartet die verschiedenen
releng/*-Zweige. Die Release Engineering Team
Charter beschreibt die Aufgaben und Verantwortungsbereiche
dieses Teams ausführlich.
Das FreeBSD Builders Release Engineering Team ist für den Bau von FreeBSD-Releases auf allen unterstützten Plattformen verantwortlich.
Das FreeBSD Donations Team kümmert sich um Spendenangebote, legt fest, wie mit Spenden umgegangen wird und koordiniert die angebotenen Spenden mit den FreeBSD-Entwicklern. Eine ausführliche Beschreibung der Aufgaben des Donations Teams finden Sie auf der Seite FreeBSD Donations Liaison.
Das FreeBSD Security Team (das vom Security Officer geleitet wird) ist dafür verantwortlich, die FreeBSD-Gemeinde über neu entdeckte Bugs und Sicherheitslücken im src- und ports-Quellcodebaum zu informieren und Informationen für den sicheren Betrieb eines FreeBSD-Systems zur Verfügung zu stellen. Außerdem sorgt es dafür, dass neu entdeckte Sicherheitslücken geschlossen werden und die Anwender durch Sicherheitshinweise informiert werden. Die FreeBSD Security Officer Charter beschreibt die Aufgaben und Verantwortungsbereiche des Security Officers ausführlich.
&os; Vendor Relations ist für die Bearbeitung der E-Mails von Hard- und Softwareverkäufern verantwortlich. An Vendor Relations geschickte E-Mails werden zusätzlich an das &os; Core Team sowie die &os; Foundation weitergeleitet.
Der FreeBSD Core Team Secretary ist ein nicht-stimmberechtigtes Mitglied des Core Teams. Er organisiert und dokumentiert die Arbeit des Core Teams, stellt den Kontakt zwischen dem Core Team und den FreeBSD-Entwicklern her und agiert als Schnittstelle zum Admin Team bei der Aufnahme neuer Committer oder beim Anlegen neuer Benutzerzugänge. Außerdem ist der Core Team Secretary für die Erstellung monatlicher Statusberichte zuständig, in denen die FreeBSD-Entwickler über aktuelle Tätigkeiten und Entscheidungen des Core Teams informiert werden.
Der FreeBSD Port Management Team Secretary ist ein nicht-stimmberechtigtes Mitglied des Port Management Teams. Er dokumentiert die Arbeit von portmgr@FreeBSD.org, führt Buch über durchgeführte Abstimmung und agiert als Schnittstelle zu anderen Teams, insbesondere zu den Admin und Core Teams. Außerdem ist er für die Erstellung monatlicher Statusberichte zuständig, in denen die FreeBSD-Entwickler über aktuelle Tätigkeiten und Entscheidungen des Port Management Teams informiert werden.
Das Accounts Team legt nach Rücksprache mit dem jeweiligen Team Benutzerzugänge für neue Committer an. Neue Zugänge werden ausschließlich nach erfolgter offizieller Zustimmung des betroffenen Teams angelegt.
E-Mails, die an das Accounts Team gesendet werden, werden derzeit an die Cluster-Administratoren weitergeleitet.
Die Backups Administrators kümmern sich um die Datensicherung auf dem FreeBSD-Cluster.
E-Mails, die an das Backups Administrators Team gesendet werden, werden derzeit an die Cluster-Administratoren weitergeleitet.
Bugmeister sind dafür verantwortlich, dass die Software zur Verwaltung von Problemberichten einwandfrei funktioniert, neue Einträge korrekt kategorisiert und ungültige Einträge entfernt werden.
Cluster-Administratoren warten die Server und Dienste, die für die Kommunikation innerhalb des Projekts und für die verteilte Arbeit am &os; Project benötigt werden. Fragen zur Projektinfrastruktur oder zur Einrichtung neuer Systeme sollten an die Cluster-Administratoren gerichtet werden. Das Team wird vom Lead Cluster Administrator geleitet, dessen Aufgaben und Verantwortung in der Cluster Administration Charta ausführlich beschrieben werden.
DNS Administrators verwalten DNS und verwandte Dienste.
E-Mails, die an das DNS Administrators Team gesendet werden, werden derzeit an die Cluster-Administratoren weitergeleitet.
Das Forum Administrators Team betreut das Internetforum des &os; Projects unter https://forums.freebsd.org/ und leitet auch das Moderatorenteam, um Qualität und Relevanz der geposteten Beiträge zu gewährleisten.
Das GitHub Automation Team überwacht den Export des &os; Quellcoderepositories an die (read-only)-Instanzen auf GitHub.
Jenkins-Administratoren sind für die kontinuierlichen Quellcodebau- und Integrationstests verantwortlich. Zu ihren Aufgaben gehören die Wartung der Jenkins-Instanz und aller Build- und Testjobs.
FTP/WWW Mirror Site Coordinators koordinieren die Arbeit der Administratoren von FTP/WWW-Spiegelservern, damit diese stets aktuelle Softwareversionen anbieten können. Sie prüfen, ob die Spiegelserver die Kapazität haben, auch große Updates zu verwalten und machen es Anwendern einfach, den nächstgelegenen FTP/WWW-Spiegelserver zu finden.
E-mails an das Mirror Site Coordinators Team wird derzeit an die Cluster-Administratoren weitergeleitet. Und zusätzlich an:
Das Phabricator Administrators Team ist für die Funktion der &os;-Instanz des Phabricator-Online-Codereviewsystems unter https://reviews.freebsd.org/ verantwortlich:
Bei Problemen mit Phabricator erstellen Sie bitte einen Problembericht. Wählen Sie zuerst die Kategorie "Services" und danach "Code Review".
Das Postmaster Team sorgt für die korrekte Zustellung von E-Mails, betreibt die Mailinglisten und ergreift Maßnahmen gegen Trolle, Spam und Viren.
Das FreeBSD Subversion Team ist für die korrekte Funktion der Subversion Repositories verantwortlich.
E-mails an das Subversion Administration Team werden derzeit an die Cluster-Administratoren weitergeleitet.
Das FreeBSD Webmaster Team ist für den reibungslosen Betrieb der Webseiten des FreeBSD Projects verantwortlich. Zu den Aufgaben dieses Teams gehören insbesondere die Konfiguration des Webservers und der CGI-Skripte sowie der Betrieb der Suchmaschinen für Webseite und Mailinglisten. Das Team kümmert sich um alle technischen Fragen, ausgenommen um Probleme innerhalb der Dokumentation.
E-Mails an das Webmaster Team werden derzeit an das Documentation Engineering Team weitergeleitet, und zusätzlich an:
Das FreeBSD Wiki Team ist für den Betrieb, das allgemeine Design sowie die Struktur des FreeBSD Wiki verantwortlich.
Melden Sie Sicherheitsprobleme in FreeBSD direkt an das Security-Team oder, falls eine höhere Vertraulichkeit erforderlich ist, PGP-verschlüsselt an das Security-Officer-Team (verwenden Sie dazu den öffentlichen PGP-Schlüssel des Security Officers).
Sicherheitsprobleme, die die Ports-Sammlung betreffen, sollten hingegen an das FreeBSD Ports Security Team gemeldet werden.
Wenn Sie ein Problem melden, geben Sie bitte mindestens folgende Informationen an:
Versuchen Sie dabei soweit als möglich die entsprechenden Vorlagen für Sicherheitshinweise und Problemhinweise zu verwenden, um Ihre Umgebung, die Beschreibung des Problems, dessen Auswirkungen sowie (falls vorhanden) einen Workaround zu dokumentieren.
Der Security-Officer oder ein Mitglied des Security-Officer-Teams wird Sie ansprechen, nachdem Sie ein Problem gemeldet haben.
Aufgrund des hohen Spam-Aufkommen durchlaufen alle an die Hauptadresse des Security-Teams gerichteten E-Mails einen Spam-Filter. Können Sie den FreeBSD Security Officer oder das FreeBSD Security Team nicht erreichen, weil Ihre E-Mail vom Spam-Filter verworfen wird (oder falls Sie vermuten, dass dies der Fall ist), so senden Sie Ihre E-Mail bitte an die Adresse security-officer-XXXX@FreeBSD.org, wobei Sie XXXX durch 3432 ersetzen. Beachten Sie, dass diese Adresse regelmäßig geändert wird. Alle E-Mails, die Sie an diese Adresse senden, werden an das FreeBSD Security Officer Team weitergeleitet.
Damit Sicherheitsprobleme schnell bearbeitet werden, werden E-Mails an den Security-Officer Alias <security-officer@FreeBSD.org> an folgende Personen weitergeleitet:
| &a.gordon.email; | Security Officer |
| &a.emaste.email; | -Deputy Security Officer | -
| &a.remko.email; | Deputy Security Officer |
| &a.delphij.email; | Security Officer Emeritus |
| &a.des.email; | Security Officer Emeritus |
Der Security-Officer wird vom FreeBSD Security Team (<secteam@FreeBSD.org>), einer von ihm ausgewählten Gruppe von Committern, unterstützt.
Generell veröffentlicht der Security-Officer nach einer angemessenen Zeit alle Informationen über ein Sicherheitsproblem. Diese Zeitspanne erlaubt eine sichere Analyse und die Behebung des Sicherheitsproblems und dient auch zum Testen der Korrektur sowie der Koordination mit anderen Betroffenen.
Der Security-Officer wird einen oder mehrere der Administratoren des FreeBSD-Clusters über Sicherheitsprobleme informieren, die Ressourcen des FreeBSD Projects unmittelbar bedrohen.
Der Security-Officer kann weitere FreeBSD-Entwickler oder externe Entwickler hinzuziehen, wenn dies zur Beurteilung oder Lösung des Sicherheitsproblems notwendig ist. Ein diskretes Vorgehen verhindert die unnötige Verbreitung des Sicherheitsproblems. Alle hinzugezogenen Experten handeln entsprechend den Richtlinien des Security-Officers. In der Vergangenheit wurden Experten wegen ihrer immensen Erfahrungen mit komplexen Komponenten des Systems, wie dem FFS, dem VM-System und dem Netzwerkstack, hinzugezogen.
Wenn gerade ein Release erstellt wird, kann der FreeBSD Release-Engineer ebenfalls über das Sicherheitsproblem und dessen Ausmaße unterrichtet werden. Damit können fundierte Entscheidungen über den Ablauf der Release-Erstellung und die Auswirkungen der Sicherheitsprobleme auf das kommende Release getroffen werden. Auf Anfrage gibt der Security-Officer nur die Existenz des Sicherheitsproblems und dessen Schwere an den Release-Engineer weiter.
Der Security-Officer arbeitet eng mit anderen Organisationen zusammen. Dazu zählen Dritthersteller, die Quellcode von FreeBSD benutzen (OpenBSD, NetBSD, DragonFlyBSD, Apple und andere Hersteller, die Software auf Basis von FreeBSD vertreiben, sowie die Linux-Vendor-Security Liste) und Organisationen, die Sicherheitsproblemen und Sicherheitsvorfällen nachgehen, beispielsweise das CERT. Oft haben Sicherheitsprobleme Auswirkungen, die über FreeBSD hinausgehen. Sie können auch (wenngleich vielleicht weniger häufig) große Teile des Internets betreffen. Unter diesen Umständen wird der Security-Officer andere Organisationen über das Sicherheitsproblem informieren wollen. Wenn Sie das nicht wünschen, vermerken Sie das bitte explizit beim Melden eines Sicherheitsproblems.
Besondere Anforderungen an den Umgang mit den eingereichten Information müssen ausdrücklich angegeben werden.
Wenn die Veröffentlichung des Sicherheitsproblems mit dem Einsender und/oder anderen Lieferanten abgestimmt werden soll, so muss dies ausdrücklich beim Einreichen des Problems angegeben werden. Ist dies nicht vermerkt, legt der Security-Officer einen Zeitplan für die Veröffentlichung des Problems fest. Der Zeitplan berücksichtigt die möglichst schnelle Veröffentlichung und die zum Testen von Lösungen benötigte Zeit. Wenn das Problem schon in öffentlichen Foren (wie Bugtraq) diskutiert wird und ausgenutzt wird, kann der Security-Officer einen anderen als den vorgeschlagenen Zeitplan verwenden. Dies dient dem maximalen Schutz der Benutzergemeinde.
Eingesendete Sicherheitsprobleme können mit PGP geschützt werden. Auf Wunsch werden die Antworten ebenfalls mit PGP geschützt.
Index: head/de_DE.ISO8859-1/htdocs/security/security.xml =================================================================== --- head/de_DE.ISO8859-1/htdocs/security/security.xml (revision 52958) +++ head/de_DE.ISO8859-1/htdocs/security/security.xml (revision 52959) @@ -1,212 +1,256 @@ - + ]>Bei FreeBSD wird Sicherheit groß geschrieben: Wir arbeiten ständig daran, das Betriebssystem so sicher wie möglich zu machen. Diese Seite erklärt, was Sie tun müssen, wenn Ihr System von einer Sicherheitslücke betroffen ist.
Melden Sie Sicherheitsprobleme im Basissystem direkt an das FreeBSD Security Team oder, falls eine höhere Vertraulichkeit erforderlich ist, PGP-verschlüsselt an das Security-Officer-Team (verwenden Sie dazu den öffentlichen PGP-Schlüssel des Security Officers). Weitere Informationen finden Sie auf der Seite FreeBSD Sicherheitsprobleme melden.
+ + +Für jedes gemeldete Problem wird eine interne Trackingnummer + erzeugt. Es sei denn, es handelt sich eindeutig nicht um ein + Sicherheitsproblem. Wir verwenden die folgende Checkliste, um + zu entscheiden, ob ein Security Advisory nötig ist (oder nicht):
+ +Privilege + escalation vulnerability)?
unassisted + jailbreak vulnerability)?
Für Probleme, die unter eine dieser Kategorien fallen, wird vermutlich + ein Security Advisory veröffentlicht werden. Sonstige Probleme werden + weiter analysiert, um zu entscheiden, ob ein Security Advisory oder ein + Errata Notice veröffentlicht wird (oder nicht).
+ +Nachdem entschieden wurde, dass ein Security Advisory erforderlich ist, + wird eine CVE-Nummer zugewiesen. Falls diese noch nicht exisitiert, wird + eine Nummer aus dem für FreeBSD bereitstehenden Pool dafür verwendet.
Eine vollständige Liste aller bekannten Sicherheitslücken des Basissystems finden Sie hier.
Sicherheitshinweise werden an die folgenden FreeBSD-Mailinglisten versendet:
Eine Liste aller bisher veröffentlichten Sicherheitshinweise findet sich auf der Seite FreeBSD Security Advisories.
Sicherheitshinweise werden immer mit dem PGP-Schlüssel des FreeBSD-Security-Officers signiert und gemeinsam mit den zugehörigen Patches auf dem Server http://security.FreeBSD.org/ in den Unterverzeichnissen advisories sowie patches archiviert.
Der FreeBSD-Security-Officer gibt Sicherheitshinweise für die FreeBSD-Entwicklungszweige -STABLE und Security heraus. Für -CURRENT (der sich primär an &os;-Entwickler wendet), werden hingegen keine Sicherheitshinweise herausgegeben.
Die -STABLE-Zweige haben Namen wie stable/10. Auf diesen Zweigen erstellte Versionen tragen Namen wie FreeBSD 10.1-STABLE.
Jedes FreeBSD-Release besitzt einen Sicherheits-Zweig. Die Tags der Sicherheits-Zweige haben Namen wie releng/10.1. Die daraus gebauten FreeBSD-Versionen tragen Namen wie FreeBSD 10.1-RELEASE-p4.
Sicherheitshinweise für die FreeBSD Ports-Sammlung werden auf der Seite FreeBSD VuXML veröffentlicht.
Benutzer, die eine Binärversion von &os; (beispielsweise &rel.current; oder &rel2.current;) installiert haben, können ihr System einfach wie folgt aktualisieren:
# freebsd-update fetchSollte dieser Weg fehlschlagen, folgen Sie bitte den Anweisungen des jeweiligen Sicherheitshinweises.
Beachten Sie, dass diese Art der Aktualisierung nur möglich ist, wenn Sie eine Binärversion von &os; installiert haben. Haben Sie Ihr System hingegen aus dem Quellcode gebaut, müssen Sie Ihren Quellcodebaum aktualisieren und das System neu bauen.
Jedes Release wird nur eine bestimmte Zeit vom Security Officer unterstützt.
Die folgende Tabelle enthält die Bezeichnungen und erwartete Lebenszeit aller aktuell unterstützten Entwicklungszweige (und deren Releases). Die Spalte Erwartetes EoL (end-of-life) gibt den frühestmöglichen Zeitpunkt an, an dem die Unterstützung für einen bestimmten Zweig eingestellt wird. Beachten Sie, dass dieser Zeitpunkt (falls nötig) auch nach hinten verschoben werden kann.
Ältere Versionen werden nicht mehr unterstützt und wir empfehlen allen Benutzern dringend, ihr System auf eine unterstützte Version zu aktualisieren:
| Zweig | Release | Typ | Releasedatum | Erwartetes EoL |
|---|---|---|---|---|
| stable/12 | n/a | n/a | n/a | 30. Juni 2020 (TBD) |
| releng/12.0 | 12.0-RELEASE | n/a | 11. Dezember 2018 | 12.1-RELEASE + 3 Monate |
| stable/11 | n/a | n/a | n/a | 30. September 2021 |
| releng/11.2 | 11.2-RELEASE | n/a | 28. Juni 2018 | 11.3-RELEASE + 3 Monate |
Während der Entwicklung eines Releases werden -BETA- und -RC-Releases veröffentlicht. Diese Releases werden nur (im Rahmen der Möglichkeiten) für einige Wochen unterstützt und werden daher nicht auf dieser Seite aufgeführt. Wir raten Benutzern dringend davon ab, diese Versionen auf einem Produktivsystem einzusetzen.
Beginnend mit &os; 11.0-RELEASE wurde das Supportmodell angepasst, um einerseits eine schnellere Entwicklung zu ermöglichen und andererseits weiterhin zeitnahe Sicherheitsupdates für alle unterstützten Versionen bereitstellen zu können.
Unter dem aktuellen Supportmodell wird jede Hauptversion explizit für 5 Jahre unterstützt, während jede Unterversion nur noch 3 Monate nach Erscheinen der folgenden Unterversion unterstützt wird.
Diese Entscheidung wurde im Februar 2015 getroffen. Die Gründe dafür können in der offiziellen Ankündigung nachgelesen werden.