Das ist ganz genau was die linux Packager/Nutzer brauchen. Ein tool, das Pakete für eine Vielzahl von Distributionen erstellen kann. Ich hoffe, das viele die Pakete erstellen darauf setzen werden. Ubuntu/Fedora etc. haben auch ihre build tools, aber wieder nur für die eigene Distribution. Deshalb, dies ist genau der richtige Ansatz. Weiter so!
(ja, ich habe einen account und ja ich habe damit pakete erstellt - und muss sagen: Begeisternd!)
Und was ist mit der Sicherheit? Woher weiß ich - rein theoretisch - dass Du kein Cracker bist und dass Deine Pakete in Ordnung sind? Und komme mir nicht mit dem Sourcecode. Der Debian-Opennssl-Bug zeigt zur Genüge, dass die Community nur sehr selten selbst den Sourcecode liest. Bis solche Angriffe auffallen, dauert es also mitunter ein Jahr und länger.
Was ist das denn für eine Logik? Du kannst bisher ja auch irgendwelche Pakete basteln und ins Netz legen. Jetzt geht's halt nur schneller... Außerdem ist es für den einzelnen wesentlich praktischer sich sein eigenes Paket zu schnüren
OpenSuse 11.1 wurde ja auch mit dem Buildservice erstellt. Trotzdem sind die Pakete signiert und es ist nachvollziehbar, wer für welches Paket verantwortlich ist. Was ich meine, sind die Pakete, die über das OpenSuse-Interface zugänglich sind. Sie sind mit diesem Buildservice erzeugt, werden auf OpenSuse-Servern angeboten, allerdings wird das Sicherheitsproblem auf die Nutzer verlagert. Wie behältst Du denn hier im Hinblick auf signierte rpm-Pakete den Überblick? http://download.opensuse.org/repositories/home:/ http://download.opensuse.org/repositories/ Hat hier jeder Ersteller seinen eigenen gpg-key? Werden alle diese Pakete "kontrolliert"? Nein? So etwas nicht zu tun, ist "logisch"?
Selbst mit Apt4Suse lief das früher "logischer" ab. Wenn hier jemand XFce-Pakete für Suse erstellte, signierte er sie mit seinem eigenen gpg-key. Auch Debian macht das. Vielleicht habe ich das ja übersehen, aber der Buildservice kommt anscheinend mit einem einzigen gpg-key für alles: rpm --import http://download.opensuse.org/openSUSE-Build-Service.asc Das ist mir in punkto Sicherheit zu "wenig".
Gibt es da eine Liste, die über die verwendeten gpg-keys Auskunft gibt? Mir persönlich würden natürlich auch Angaben wie z.B. hier genügen: http://download.opensuse.org/distribution/11.1/repo/oss/
Die Schlüssel sind im jeweiligen Repository in /repodata/repomd.xml.key, z.B für http://tinyurl.com/dyfx5n ist der Schlüssel http://tinyurl.com/ce7z9t (bei dem von dir angegebenen Link sinds einfach die gpg-pubkey....asc).
Was du lokal akzeptiert hast lässt sich mit "rpm -qa gpg-pubkey*" anzeigen und mit "rpm -qi gpg-pubkey......" auslesen.
> Hat hier jeder Ersteller seinen eigenen gpg-key?
Ja. Jedes Repository hat seinen eigenen GPG-Key mit welchem die Pakete signiert werden.
Diese müssen VOR der Installation eines Paketes vom Endnutzer als root importiert werden - genauso wie bei apt4suse.
YaST (yast2 repositories) bietet auch eine GUI für die Verwaltung der Keys.
> Werden alle diese Pakete "kontrolliert"?
Grundsätzlich: nein.
Pakete unterhalb von http://download.opensuse.org/repositories/home:/ kann und soll jeder einzelne Packager anlegen. Betrachte die Pakete unterhalb von "home:" als das, was auf einem Server in "/home" liegt. Sicherlich möchtest du als Admin auch nicht alle "/home/*/bin/" Verzeichnisse im PATH haben...
Den Paketen in den einzelnen Projekten jedoch kommt durchaus erhöhte Aufmerksamkeit und Kontrolle zugute. Dort arbeiten meist mehrere Entwickler zusammen an einem Projekt - und wo mehrere Augen hinschauen, da ist die Möglichkeit eines Fehlers generell geringer.
Einzelne Projekte, wie z.B. openSUSE:Factory, werden sogar noch restriktiver kontrolliert. Hier gibt es eine eigene "Review-Crew", die Änderungen in JEDEM einzelnen Paket reviewen, bevor es für das Repository akzeptiert wird.
Aber natürlich macht man sich beim Buildservice schon länger Gedanken darüber, wie man die "Qualität" und damit auch Sicherheit einzelner Repositories gegenüber Endnutzern besser Sichtbar machen kann.
Danke für Deine Hinweise. Was diese "home"-repositories anbelangt, so ist es natürlich recht schwer, etwas zu finden, dessen Existenz man gar nicht vermutet. So wäre ich ohne die KDE 2.2.2-OpenSuse 11.1-LiveCD nie dahintergekommen, dass ein "privates" OpenSuse 11.1-Repository für KDE 2.2.2 existiert. Ich habe hier einen älteren Rechner herumstehen, der alle "Kraft" für das Basissystem und Firefox3 benötigt. Da kommt mir eine voll ausgestattete, aber dennoch recht "leichte" Umgebung wie KDE 2.2.2 gerade recht. Das Problem sind natürlich mögliche ungefixte Sicherheitslücken. Da ich aber keine KDE 2.2.2-Applikation im Internet verwende (nur lokal den Dateimanager), sehe ich dieses Problem nicht als so schwerwiegend an.
Die Entwickler von geeqie 1 (weiterentwicklung von gqviev) nutzen diesen Dienst. Fuer die Distros gibt es YUM/APT/YAST... Repros 2. Ich als Nutzer mag es sehr.
Von Felix Schwarz am Fr, 10. April 2009 um 14:46 #
Das ist ganz genau was die linux Packager/Nutzer brauchen. Ein tool, das Pakete für eine Vielzahl von Distributionen erstellen kann. Ich hoffe, das viele die Pakete erstellen darauf setzen werden. Ubuntu/Fedora etc. haben auch ihre build tools, aber wieder nur für die eigene Distribution. Deshalb, dies ist genau der richtige Ansatz. Weiter so!
Vorweg: Ich finde den Build Service auch gut.
Aber: Die Idee, dass man unter Linux ein Paket für verschiedene Distributionen bauen kann, halte ich für falsch/naiv. Wenn man wirklich eine gute Integration in die verschiedenen Distributionen haben will, muss man jeweils unterschiedliche Pakete bauen.
Der Build Service bietet aus meiner Sicht genau einen Vorteil: Das man nicht alle Distributionen selbst installieren muss, für die man Binärpakete anbieten will.
Da ist z.B. im Repository "filesharing/openSUSE_Factory" die Version 0.7.2b, in "filesharing/openSUSE_11.0" die Version 0.8.0b und in "home:miniwark:GNUnet/openSUSE_11.0" die Version 0.8.0c. Ausserdem gibts noch in "home:pikerhog/openSUSE_Factory die Version 0.7.3...
Kann mir jemand erklaeren, warum ausgerechnet in "Factory" die aelteste Version ist ?
Die ganzen "filesharing Repositories" sind nicht viele verschiedene sondern ein einziges das für mehrere Versionen gebaut wird (11.0, 11.1, Factory, ...) und warum die neuere Version für Factory nicht gebaut wurde ist aus den Logfiles ersichtlich welche hier erhältlich sind:
(Ja du brauchst ein Login aber das vom Wiki, Forum, Bugtracker, etc. funktioniert)
Die Versionen in den home: Repositories sind von irgendwelchen Leuten die anscheinend lieber ihr eigenes Süppchen kochen anstatt an der Version in "filesharing" zusammenzuarbeiten. Was im übrigen ziemlich einfach ist: http://en.opensuse.org/Build_Service/Collaboration
Und ja, dass Pakete x-fach dupliziert in verschiedenen home: Repositories existieren weil es den Eigentümern wurscht ist, ist in der Tat verbesserungswürdig. Das liegt aber weniger am Build Service selbst, als an den Deppen die meinen die Welt bräuchte unbedingt noch eine 16. Version eines veralteten Pakets anstatt zusammenzuarbeiten :/
Deshalb, dies ist genau der richtige Ansatz. Weiter so!
(ja, ich habe einen account und ja ich habe damit pakete erstellt - und muss sagen: Begeisternd!)
have fun!
Woher weiß ich - rein theoretisch - dass Du kein Cracker bist und dass Deine Pakete in Ordnung sind?
Und komme mir nicht mit dem Sourcecode.
Der Debian-Opennssl-Bug zeigt zur Genüge, dass die Community nur sehr selten selbst den Sourcecode liest.
Bis solche Angriffe auffallen, dauert es also mitunter ein Jahr und länger.
Trotzdem sind die Pakete signiert und es ist nachvollziehbar, wer für welches Paket verantwortlich ist.
Was ich meine, sind die Pakete, die über das OpenSuse-Interface zugänglich sind. Sie sind mit diesem Buildservice erzeugt, werden auf OpenSuse-Servern angeboten, allerdings wird das Sicherheitsproblem auf die Nutzer verlagert.
Wie behältst Du denn hier im Hinblick auf signierte rpm-Pakete den Überblick?
http://download.opensuse.org/repositories/home:/
http://download.opensuse.org/repositories/
Hat hier jeder Ersteller seinen eigenen gpg-key?
Werden alle diese Pakete "kontrolliert"?
Nein?
So etwas nicht zu tun, ist "logisch"?
Selbst mit Apt4Suse lief das früher "logischer" ab. Wenn hier jemand XFce-Pakete für Suse erstellte, signierte er sie mit seinem eigenen gpg-key. Auch Debian macht das.
Vielleicht habe ich das ja übersehen, aber der Buildservice kommt anscheinend mit einem einzigen gpg-key für alles:
rpm --import http://download.opensuse.org/openSUSE-Build-Service.asc
Das ist mir in punkto Sicherheit zu "wenig".
Mir persönlich würden natürlich auch Angaben wie z.B. hier genügen:
http://download.opensuse.org/distribution/11.1/repo/oss/
Was du lokal akzeptiert hast lässt sich mit "rpm -qa gpg-pubkey*" anzeigen und mit "rpm -qi gpg-pubkey......" auslesen.
Damit weiß ich ein bisschen mehr Bescheid.
Ja. Jedes Repository hat seinen eigenen GPG-Key mit welchem die Pakete signiert werden.
Diese müssen VOR der Installation eines Paketes vom Endnutzer als root importiert werden - genauso wie bei apt4suse.
YaST (yast2 repositories) bietet auch eine GUI für die Verwaltung der Keys.
> Werden alle diese Pakete "kontrolliert"?
Grundsätzlich: nein.
Pakete unterhalb von http://download.opensuse.org/repositories/home:/ kann und soll jeder einzelne Packager anlegen. Betrachte die Pakete unterhalb von "home:" als das, was auf einem Server in "/home" liegt. Sicherlich möchtest du als Admin auch nicht alle "/home/*/bin/" Verzeichnisse im PATH haben...
Den Paketen in den einzelnen Projekten jedoch kommt durchaus erhöhte Aufmerksamkeit und Kontrolle zugute. Dort arbeiten meist mehrere Entwickler zusammen an einem Projekt - und wo mehrere Augen hinschauen, da ist die Möglichkeit eines Fehlers generell geringer.
Einzelne Projekte, wie z.B. openSUSE:Factory, werden sogar noch restriktiver kontrolliert. Hier gibt es eine eigene "Review-Crew", die Änderungen in JEDEM einzelnen Paket reviewen, bevor es für das Repository akzeptiert wird.
Aber natürlich macht man sich beim Buildservice schon länger Gedanken darüber, wie man die "Qualität" und damit auch Sicherheit einzelner Repositories gegenüber Endnutzern besser Sichtbar machen kann.
Marko Jung, seines Zeichens Debian-Entwickler und Linuxtag Organisator, schreibt dazu gerade seine Diplom Arbeit. Einige Auszüge davon gibt es bereits:
http://en.opensuse.org/Build_Service/Concepts/Trust
Vorschläge sind ihm immer willkommen.
Was diese "home"-repositories anbelangt, so ist es natürlich recht schwer, etwas zu finden, dessen Existenz man gar nicht vermutet.
So wäre ich ohne die KDE 2.2.2-OpenSuse 11.1-LiveCD nie dahintergekommen, dass ein "privates" OpenSuse 11.1-Repository für KDE 2.2.2 existiert.
Ich habe hier einen älteren Rechner herumstehen, der alle "Kraft" für das Basissystem und Firefox3 benötigt. Da kommt mir eine voll ausgestattete, aber dennoch recht "leichte" Umgebung wie KDE 2.2.2 gerade recht. Das Problem sind natürlich mögliche ungefixte Sicherheitslücken. Da ich aber keine KDE 2.2.2-Applikation im Internet verwende (nur lokal den Dateimanager), sehe ich dieses Problem nicht als so schwerwiegend an.
1 http://geeqie.sourceforge.net/
2 http://download.opensuse.org/repositories/home:/nadvornik:/geeqie/
Deshalb, dies ist genau der richtige Ansatz. Weiter so!
Vorweg: Ich finde den Build Service auch gut.
Aber: Die Idee, dass man unter Linux ein Paket für verschiedene Distributionen bauen kann, halte ich für falsch/naiv. Wenn man wirklich eine gute Integration in die verschiedenen Distributionen haben will, muss man jeweils unterschiedliche Pakete bauen.
Der Build Service bietet aus meiner Sicht genau einen Vorteil: Das man nicht alle Distributionen selbst installieren muss, für die man Binärpakete anbieten will.
fs
Und genau deswegen gibt es die %if switches: http://en.opensuse.org/Build_Service/cross_distribution_package_how_to
Außerdem ist es auch kein Problem für jede Distribution ein seperates .spec zu benutzen (ob das wiederum Sinn macht ist ne andere Frage ... ;D)
Ein Negativbeispiel ist GNUnet: openSUSE Buildservice:GNUnet
Da ist z.B. im Repository "filesharing/openSUSE_Factory" die Version 0.7.2b, in "filesharing/openSUSE_11.0" die Version 0.8.0b und in "home:miniwark:GNUnet/openSUSE_11.0" die Version 0.8.0c. Ausserdem gibts noch in "home:pikerhog/openSUSE_Factory die Version 0.7.3...
Kann mir jemand erklaeren, warum ausgerechnet in "Factory" die aelteste Version ist ?
https://build.opensuse.org/package/show?package=GNUnet&project=filesharing
(Ja du brauchst ein Login aber das vom Wiki, Forum, Bugtracker, etc. funktioniert)
Die Versionen in den home: Repositories sind von irgendwelchen Leuten die anscheinend lieber ihr eigenes Süppchen kochen anstatt an der Version in "filesharing" zusammenzuarbeiten. Was im übrigen ziemlich einfach ist: http://en.opensuse.org/Build_Service/Collaboration
Und ja, dass Pakete x-fach dupliziert in verschiedenen home: Repositories existieren weil es den Eigentümern wurscht ist, ist in der Tat verbesserungswürdig. Das liegt aber weniger am Build Service selbst, als an den Deppen die meinen die Welt bräuchte unbedingt noch eine 16. Version eines veralteten Pakets anstatt zusammenzuarbeiten :/
Also finger weg von SuSE Linux.