expertenaustausch > linux.debian.user.german

Daniel Baumann (21.09.2005, 14:50)
Daniel Leidert wrote:
> Evtl. ein Vorschlag für Euch nachdem ich 10.1 im Todo gelesen habe.
> Jarno Elonen hat ein nettes PHP-Skripts namens apt-parse-files.inc
> geschrieben, dass es gestattet, automatisch das Repository auszulesen
> und eine Übersicht zu generieren [2]. Ich habe diese Skript im Laufe der
> Zeit noch etwas erweitert [3][4]. Evtl. wäre das ja was für euch.


Danke fuer den Tipp. Sobald ich mich um die Website kuemmere, werde ich
mich umschauen.
Daniel Leidert (21.09.2005, 15:30)
Am Mittwoch, den 21.09.2005, 14:11 +0200 schrieb Daniel Baumann:
> Daniel Leidert wrote:
> > | Disclaimer: Information on this site is not part of the
> > | Debian-Project!

> Und das tut zur Sache?


Das es sich um ein inoffizielles Projekt handelt?

> > Auch hier gilt: Paket ohne Quelle, das angeblich von Opera stammt. Um
> > das zu prüfen muss die md5-Summe herangezogen werden, was apt-get nicht
> > tut.

> Macht ja auch nicht Sinn, das orig.tar.gz mit Upstream zu vergleichen.


Nö, natürlich nicht. Ich frage mich gerade, warum das bei Sponsoren so
üblich ist (.orig.tar.gz durch Upstream-Archiv austauschen und mit
dpkg-source -x ... dpkg-buildpackage neu bauen) und AFAIK allgemein zur
guten Praxis gehört. Die Reject-FAQ ist dir bekannt? Die Policy
ebenfalls? Such mal nach Aussagen zum Neupacken von Quellen. Es gib da
so einen Punkt, der das genaue Gegenteil deiner Aussage belegt.

> Der, der das Paket ins Archiv geladen hat, garantiert mit seinem Namen
> nach bestem Wissen und Gewissen dafuer, dass das Paket integer ist.


Ahja. _Das_ nenne ich Garantien, vor allem bei Binary-Paketen ohne
Quelle.

> > Ergo müsste es der User selbst tun und dann kann er sich das Paket
> > auch von der Originalquelle besorgen.

> Dann soll er das doch machen. Jedem soviel Aufwand, wie er vertraegt.


Nein: Jedem soviel Sicherheit wie ihm zusteht.

> > Nochmal: Wodurch wird das
> > Binary-Paket vertrauenswürdig?

> Darum gehts (urspruenglich) nicht.


Ach nein? Es ging um eine "vernünftige" Quelle für ein
Binary-only-Paket. Deine Aussage war, du hättest eins und ich würde es
nur nicht kennen. Ich behaupte, dass das (aus Sicherheitsgründen) nicht
der Fall ist, vor allem da du Fragen nicht beantworten willst. Gehen dir
die Argumente aus?

> Gefragt war ein Repository, das
> aktuelle Opera Pakete fuehrt und zeitnahe Updates hat.


Nein. Gefragt war "vernünftig". Was du darunter verstehst und was ich
darunter verstehe sind offenbar zwei verschiedene Paar Schuhe. Und warum
bei Binary-only-Paketen die Quelle eine Rolle spielt, kann sich jeder
mit gesundem Menschenverstand selbst ausrechnen.

> Debian Unofficial
> erfuellt dies.


Schön. Allerdings versuchst du dich offenbar um die Thematik Sicherheit
zu drücken. Das baut natürlich unheimlich Vertrauen auf, wenn man sagt:
"Vertraut uns oder lasst es sein."

> Ob mir jemand vertraut, ist mir voellig egal und ist jedem selber
> ueberlassen (und ist auch primaer nicht das Thema dieses Threads).
> Das ist eine unvollstaendige Liste von Gruenden,


Mir ging um den unterstrichenen Punkt, den ich zur Sprache bringen
wollte. Was genau willst _du_ mir sagen?

> warum ein Paket nicht
> in Debian sein kann, und darum ein moeglicher Kandidat fuer Debian
> Unofficial ist.


Was genau hat das damit zu tun, dass du Binary-only-Uploads aus
was-weiss-ich-für-Quellen erlaubst?

> Darum geht es nicht,


Nein, Fragen zu beantworten ist ganz offensichtlich nicht dein Ding.

> siehe oben. Wenn du Opera nicht traust, brauchst du
> mir auch nicht zu trauen.


Ja klar. Alibi-Argument? Ich traue Opera, aber warum soll ich dir oder
den Binary-only-Paketen in deinem Repository trauen? Wunschdenken, dass
du und alle Uploader liebe, nette Menschen sind, die niemandem etwas
böses wollen? Und das bei closed-source-Paketen? Jeder mit etwas
Verantwortungsbewusstsein, würde eine derartige Garantie deutlich von
sich weisen. Es sagt für meinen Geschmack schon viel aus, dass du dich
um die Beantwortung relevanter Fragen drückst. Nur interessehalber: Gibt
es im Projekt totalitären Führungscharakter?

> Wenn du Opera (oder jedes andere Paket aus Debian Unofficial)
> installieren willst, kannst du das auch von der Originalquelle besorgen
> und hoffen, dass du moeglichen Schadcode siehst. Wenn du nicht soviel
> Aufwand treiben moechtest oder kannst,


Sicher. Es gibt genügend Leute, die dem $User versuchen
Sicherheitsbewusstsein einzubleuen. Du tust offenbar das Gegenteil.
Warum?

> dann installierst du das Paket
> aus Debian Unofficial - denn genau dafuer ist das Repository da: das zur
> Verfuegungstellung von Paketen in einem zentralen Repository von
> Paketen, die (aus guten Gruenden) nicht in Debian sind, aber trotzdem
> viele Leute gerne haben moechten/nutzen.


Ich frage erneut: Welche Sicherheitsrichtlinien verhindern, dass über
diese Repository mit Binary-only-Paketen Unfug getrieben wird? Woran
kann ich als End-Benutzer erkennen, dass es sich um das originale Paket
des Herstellers/Autors handelt?

> Dass diese in einem einzigen,
> unabhaengigen Repository gesammelt sind, ist nur eine Frage der
> Bequemlichkeit und Dienstleistung gegenueber den Nutzern.


Weißt du, wieviele "Gimmicks" Windows bietet? Und das btw. auch
zugunsten der "Bequemlichkeit und Dienstleistung" gegenüber dem Nutzer.
Und weißt du auch, welches Verhalten für Blaster/Sasser und Konsorten
verantwortlich war?

> Falls du je mal ein Paket aus Debian benutzt hast von mir, hoffe ich,
> dass du mit genau derselben Paranoia an die Sache rangehst - auch da ist
> es ganz gut moeglich, potentiellen Schadcode einzuschleusen den
> _erstmal_ niemand entdeckt.


Das ist richtig. Der Unterschied zwischen offenen und nicht-offenen
Quellen sollte dir als Paket-Maintainer dennoch bekannt sein. Und ja,
mir ist durchaus bewusst, dass es problemlos möglich ist, dem
Debian-Projekt von innen Schaden zuzufügen. Genauso wie das für Opera
möglich wäre oder jedes andere Projekt. Deine Aussage bestätigt damit
nur eins: Es gibt keine 100%ige Sicherheit. Sie kann aber kaum als
Argument zählen, Drittquellen per se als vertrauenswürdig zu erachten.

MfG Daniel
Daniel Baumann (21.09.2005, 16:50)
Daniel Leidert wrote:
>>Und das tut zur Sache?

> Das es sich um ein inoffizielles Projekt handelt?


Inwiefern aendert das nun was daran, dass Opera ein binary-only Programm
ist, dessen Quellen man nicht oeffentlich untersuchen kann?

> Nö, natürlich nicht. Ich frage mich gerade, warum das bei Sponsoren so
> üblich ist (.orig.tar.gz durch Upstream-Archiv austauschen und mit
> dpkg-source -x ... dpkg-buildpackage neu bauen) und AFAIK allgemein zur
> guten Praxis gehört. Die Reject-FAQ ist dir bekannt? Die Policy
> ebenfalls? Such mal nach Aussagen zum Neupacken von Quellen. Es gib da
> so einen Punkt, der das genaue Gegenteil deiner Aussage belegt.


....dass apt-get das vergleicht, davon hast du gesprochen - und das macht
keinen Sinn. Der Rest ist normales Package-Handling (und ich glaube, mit
Verlaub, dass ich mehr Erfahrung im Paketieren habe als du).

>>Der, der das Paket ins Archiv geladen hat, garantiert mit seinem Namen
>>nach bestem Wissen und Gewissen dafuer, dass das Paket integer ist.

> Ahja. _Das_ nenne ich Garantien, vor allem bei Binary-Paketen ohne
> Quelle.


Das Problem liegt in der Natur der Sache, dass...

> Ach nein? Es ging um eine "vernünftige" Quelle für ein
> Binary-only-Paket. Deine Aussage war, du hättest eins und ich würde es
> nur nicht kennen. Ich behaupte, dass das (aus Sicherheitsgründen) nicht
> der Fall ist, vor allem da du Fragen nicht beantworten willst. Gehen dir
> die Argumente aus?


....binary-only Programme nicht ueberpruefbar sind. Ob das Upstream
paketiert oder jemand anderes repackt, aendert nichts daran.

Btw, kein Grund unfreundlich zu werden.

>>Gefragt war ein Repository, das
>>aktuelle Opera Pakete fuehrt und zeitnahe Updates hat.

> Nein. Gefragt war "vernünftig". Was du darunter verstehst und was ich
> darunter verstehe sind offenbar zwei verschiedene Paar Schuhe. Und warum
> bei Binary-only-Paketen die Quelle eine Rolle spielt, kann sich jeder
> mit gesundem Menschenverstand selbst ausrechnen.


Du hast "vernuenftig" als etwas interpretiert, was bei binary-only
Programm gar nicht moeglich ist, auch nicht vom Hersteller.

Ich verstehe "vernuenftig" im Kontext mit binary-only als das, was ich
gesagt habe: aktuelle Paketversionen und schnelle Updates.

>> Debian Unofficial
>>erfuellt dies.

> Schön. Allerdings versuchst du dich offenbar um die Thematik Sicherheit
> zu drücken. Das baut natürlich unheimlich Vertrauen auf, wenn man sagt:
> "Vertraut uns oder lasst es sein."


Nein, es macht nur gar keinen Sinn, bei binary-only ueber Sicherheit zu
diskutieren, wie mehrmals schon gesagt: binary-only Programme sind
niemanls sicher vor Malware, weder auf der Herstellerseite noch auf
einer Seite eines Redistributors. Solange man nicht die Quellen hat,
kann man nie sicher sein. Das setzte ich als allgemein bekannt voraus,
es ist also muessig darueber zu diskutieren.

>>Das ist eine unvollstaendige Liste von Gruenden,
>> warum ein Paket nicht
>>in Debian sein kann, und darum ein moeglicher Kandidat fuer Debian
>>Unofficial ist.

> Was genau hat das damit zu tun, dass du Binary-only-Uploads aus
> was-weiss-ich-für-Quellen erlaubst?


1. Debian Unofficial gibt es u.a. deswegen, weil binary-only Programme
nicht (oder nur in Ausnahmefaellen) in Debian hochgeladen werden koennen.

2. Ich hole die original-Pakete von der Herstellerseite, alle
hochgeladenen Pakete sind signiert. Ob du mir vertraust oder nicht, ist
dir ueberlassen.

> Nein, Fragen zu beantworten ist ganz offensichtlich nicht dein Ding.


Du willst offensichtlich nur auf "binary-only-ist-unsicher" herumreiten,
obwohl das nie das Thema war. Der, der Opera installieren wollte, hat
sich mit der Thematik bereits auseinandergesetzt und wollte es
installieren, d.h. er bringt zumindest Opera SA. gegenueber ein gewisses
Vertrauen auf. Gut, du hast es jetzt wieder zur Ansprache gebracht, wir
wissen es, und die, die binary-only Software benoetigen, werden das auch
weiterhin tun.

> Ja klar. Alibi-Argument? Ich traue Opera, aber warum soll ich dir oder
> den Binary-only-Paketen in deinem Repository trauen? Wunschdenken, dass
> du und alle Uploader liebe, nette Menschen sind, die niemandem etwas
> böses wollen? Und das bei closed-source-Paketen? Jeder mit etwas
> Verantwortungsbewusstsein, würde eine derartige Garantie deutlich von
> sich weisen. Es sagt für meinen Geschmack schon viel aus, dass du dich
> um die Beantwortung relevanter Fragen drückst. Nur interessehalber: Gibt
> es im Projekt totalitären Führungscharakter?


Ich garantiere lediglich, dass nach meinem besten Wissen und Gewissen
die Pakete in ihrerer Ausgangsform identisch sind zu der, wie sie der
Upstream abliefert (von etwas anderem habe ich nie gesprochen).

Wenn du allerdings Upstream (hier Opera) vertraust, dann vertraust du
mir auch automatisch:

Jedes binary-only Paket auf debian-unofficial.org sind die Files
identisch zu Upstream: das einzige was zum Teil geandert ist, sind
Start/Stop-Scripte, Icons, Manpages, Paketbeschreibungen,
Installationspfade.

Das kannst du eindeutig ueberpruefen und ich erwarte, dass du das tust,
falls du einmal ein Paket aus diesem Repository verwendest.

> Ich frage erneut: Welche Sicherheitsrichtlinien verhindern, dass über
> diese Repository mit Binary-only-Paketen Unfug getrieben wird? Woran
> kann ich als End-Benutzer erkennen, dass es sich um das originale Paket
> des Herstellers/Autors handelt?


orig.tar.gz holen, mit Upstream vergleichen, z.B. md5sum/sha1sum benutzen...

Ausserdem muessen alle Uploads durch mich gehen, es kann niemand einfach
irgendwas hochladen.

> Das ist richtig. Der Unterschied zwischen offenen und nicht-offenen
> Quellen sollte dir als Paket-Maintainer dennoch bekannt sein. Und ja,
> mir ist durchaus bewusst, dass es problemlos möglich ist, dem
> Debian-Projekt von innen Schaden zuzufügen. Genauso wie das für Opera
> möglich wäre oder jedes andere Projekt. Deine Aussage bestätigt damit
> nur eins: Es gibt keine 100%ige Sicherheit. Sie kann aber kaum als
> Argument zählen, Drittquellen per se als vertrauenswürdig zu erachten.


Ueber die Debian Infrastruktur gibt es auch binary-only Pakete.

Falls du mal ein neues Argument hast, ausser der allgemeinen Tatsache,
dass "binary-only-ist-unsicher" und "besonders wenn es von Drittseiten
kommt bei denen ich zu faul bin, es zu ueberpruefen", darfst du gerne
antworten, ansonsten EOD da ich alle Fragen beantwortet habe.
Daniel Leidert (21.09.2005, 18:20)
Am Mittwoch, den 21.09.2005, 16:17 +0200 schrieb Daniel Baumann:
> Daniel Leidert wrote:
> >>Und das tut zur Sache?

> > Das es sich um ein inoffizielles Projekt handelt?

> Inwiefern aendert das nun was daran, dass Opera ein binary-only Programm
> ist, dessen Quellen man nicht oeffentlich untersuchen kann?


Das es evtl. in der Qualitätssicherung deutliche Unterschiede zu
offiziellen Projekten, die im Zusammenhang mit dem inoffiziellen Projekt
stehen, existieren?

[..]
> Der Rest ist normales Package-Handling (und ich glaube, mit
> Verlaub, dass ich mehr Erfahrung im Paketieren habe als du).


Möglich. Und? Was für ein Begriff mir zu dem Satz einfällt, behalte ich
lieber für mich.

> Das Problem liegt in der Natur der Sache, dass...
> ...binary-only Programme nicht ueberpruefbar sind. Ob das Upstream
> paketiert oder jemand anderes repackt, aendert nichts daran.


Es macht keinen Unterschied, ob ich in diesem Fall das Paket vom
Hersteller oder irgendeiner Drittseite oder (übertrieben)
File-Sharing-Pools beziehe? Ich glaube kaum. Natürlich kann auch im
Upstream ein Problem auftreten, siehe die Meldung auf Heise diese oder
letzte Woche. Aber die Wahrscheinlichkeit, dass die Archive vom
Hersteller manipuliert sind, sind geringer, als dass ein Dritter an
ihnen manipuliert hat.

> Btw, kein Grund unfreundlich zu werden.


War ich das?

> Du hast "vernuenftig" als etwas interpretiert, was bei binary-only
> Programm gar nicht moeglich ist, auch nicht vom Hersteller.


Weil? Der Hersteller hat keine Einsicht in den Quellcode? Die
Wahrscheinlichkeit ein manipuliertes Microsoft-Update auf deren
Webseiten oder in File-Sharing-Pools zu finden ist gleich groß? Sorry,
aber deine Argumentation ist fadenscheinig. Nicht jeder Hersteller ist
per se vertrauenswürdig, aber Drittquellen damit gleichzusetzen, finde
ich mehr als lächerlich.

> Ich verstehe "vernuenftig" im Kontext mit binary-only als das, was ich
> gesagt habe: aktuelle Paketversionen und schnelle Updates.
> Nein, es macht nur gar keinen Sinn, bei binary-only ueber Sicherheit zu
> diskutieren, wie mehrmals schon gesagt: binary-only Programme sind
> niemanls sicher vor Malware, weder auf der Herstellerseite noch auf
> einer Seite eines Redistributors.
> Solange man nicht die Quellen hat,
> kann man nie sicher sein. Das setzte ich als allgemein bekannt voraus,
> es ist also muessig darueber zu diskutieren.


Jetzt sprichst du offenbar von Sicherheitslücken innerhalb der Software.
_Die_ standen tatsächlich nicht zur Debatte.

[..]
> > Was genau hat das damit zu tun, dass du Binary-only-Uploads aus
> > was-weiss-ich-für-Quellen erlaubst? [..]

> 2. Ich hole die original-Pakete von der Herstellerseite, alle
> hochgeladenen Pakete sind signiert. Ob du mir vertraust oder nicht, ist
> dir ueberlassen.


Auf der Seite stand nicht, dass du der einzige Uploader bist. Im
Gegenteil. Also zeichnest du für Binary-only-Pakete verantwortlich? Das
konntest du in der letzten Mail nicht klarstellen? Und btw: Was genau
soll der Hinweis auf die Signatur hier? Dass du etwas signierst, macht
es nicht vertrauenswürdig.

> > Nein, Fragen zu beantworten ist ganz offensichtlich nicht dein Ding.

> Du willst offensichtlich nur auf "binary-only-ist-unsicher" herumreiten,


Nein, Redistribution von binary-only ist unsicher für den Endanwender,
ganz unabhängig davon, wie unsicher oder vertrauenswürdig der Hersteller
selbst ist, denn hier muss auch noch der Redistributor vertrauenswürdig
sein, da durch das Fehlen der Quellen böswillig Schadfunktionen auf
recht einfache Art und Weise untergebracht werden können. Das war die
Begründung dafür, dass es kein vernünftiges Repository für Opera gibt.
Und du kannst noch so oft mit einem ...

> obwohl das nie das Thema war.


.... kommen. Genau das _war_ das Thema. Vielleicht solltest du mal meine
erste Antwort an dich noch einmal lesen.

> Der, der Opera installieren wollte, hat
> sich mit der Thematik bereits auseinandergesetzt und wollte es
> installieren, d.h. er bringt zumindest Opera SA. gegenueber ein gewisses
> Vertrauen auf.


Wie kommst du dazu, das Vertrauen in den Hersteller mit dem Vertrauen in
den Redistributor gleichzusetzen?

> Gut, du hast es jetzt wieder zur Ansprache gebracht, wir
> wissen es, und die, die binary-only Software benoetigen, werden das auch
> weiterhin tun.


Ich frage mich gerade, was dich vom File-Sharing-Pool unterscheidet.

[..]
> Ich garantiere lediglich, dass nach meinem besten Wissen und Gewissen
> die Pakete in ihrerer Ausgangsform identisch sind zu der, wie sie der
> Upstream abliefert (von etwas anderem habe ich nie gesprochen).


Das garantierst du? Für alle Pakete? Bist du bereit, das schriftlich
niederzulegen? Z.B. auf der Projekt-Seite?

[..]
> orig.tar.gz holen, mit Upstream vergleichen, z.B. md5sum/sha1sum benutzen....
> Ausserdem muessen alle Uploads durch mich gehen, es kann niemand einfach
> irgendwas hochladen.


Und du testest und führst die angesprochenen Maßnahmen durch? Ich frage
mich gerade, welche Pflichten deine obige Garantie so nach sich ziehen
würde.

> Ueber die Debian Infrastruktur gibt es auch binary-only Pakete.


Habe ich noch nicht gesehen. Beispiele?

> Falls du mal ein neues Argument hast, ausser der allgemeinen Tatsache,
> dass "binary-only-ist-unsicher" und "besonders wenn es von Drittseiten
> kommt bei denen ich zu faul bin, es zu ueberpruefen"


Na, da kann ich nur hoffen, dass du nicht zu "faul" bist, die Pakete
immer ordentlich zu überprüfen. Vor allem wenn das Projekt wachsen
sollte. Bei Gelegenheit wirst du dann vielleicht an deine "Garantie"
denken.

> , darfst du gerne antworten


FYI: Ich glaube nicht, dass ich von dir die Erlaubnis dazu bräuchte.

> , ansonsten EOD da ich alle Fragen beantwortet habe.


Schon klar.

*kopfschüttelnd*
MfG Daniel
Daniel Baumann (21.09.2005, 19:50)
Daniel Leidert wrote:
> Das es evtl. in der Qualitätssicherung deutliche Unterschiede zu
> offiziellen Projekten, die im Zusammenhang mit dem inoffiziellen Projekt
> stehen, existieren?


Koennte man vermuten, ist aber nicht so.

> Weil? Der Hersteller hat keine Einsicht in den Quellcode? Die
> Wahrscheinlichkeit ein manipuliertes Microsoft-Update auf deren
> Webseiten oder in File-Sharing-Pools zu finden ist gleich groß? Sorry,
> aber deine Argumentation ist fadenscheinig. Nicht jeder Hersteller ist
> per se vertrauenswürdig, aber Drittquellen damit gleichzusetzen, finde
> ich mehr als lächerlich.


Auf der einen Seite haben wir den Upstream, auf der anderen Seite der
Redistributor.

Das, was Upstream macht (immer bei binary-only jetzt) koennen wir
aussenstehende nicht kontrollieren. Das, was der Redistributor (in
diesem falle hier ich) mache, kann man kontrollieren.

Da man meine Pakete kontrollieren kann, ob die Dateien darin identisch
sind wie die vom Upstream, sind sie also *genau* gleich betroffen von
potentiellem Schadcode; *nicht* mehr und *nicht* weniger.

> Jetzt sprichst du offenbar von Sicherheitslücken innerhalb der Software.
> _Die_ standen tatsächlich nicht zur Debatte.


Nein, ich spreche immer von irgendeiner Art Schadcode, ob das sich in
Form einer Sicherheitsluecke oder in Spyware, Viren, $whatever aeussert,
ist erstmal egal.

> Auf der Seite stand nicht, dass du der einzige Uploader bist. Im
> Gegenteil. Also zeichnest du für Binary-only-Pakete verantwortlich? Das
> konntest du in der letzten Mail nicht klarstellen? Und btw: Was genau
> soll der Hinweis auf die Signatur hier? Dass du etwas signierst, macht
> es nicht vertrauenswürdig.


Auf der Website siehst du eine Danksagung, das sagt nichts darueber aus,
wer was hochgeladen hat oder auch nicht.

Alle Pakete sind ausschliesslich von mir gemacht (ausser die zwei
Ausnahmen welche auf der Danksagungs-Seite erwaehnt sind). Wie allgemein
aus dem .dsc ersichtlich ist, sind alle Pakete im Archiv mit meinem Key
signiert, d.h. ich habe alle kontrolliert. Ein nicht signiertes Paket
resp. mit dem falschen Key signiertes Paket kann nicht von Debian
Unofficial kommen. Leider mekert apt aus Sarge das nicht, falls es nicht
stimmen wuerde (falls, hypotehtischerweise, jemand in den Server
einbricht und kurzfristig ein Paket unterjubeln/austauschen wuerde). Du
darfst aber gerne Apt 0.6 verwenden, der diese Verifikation uebernimmt.

> Nein, Redistribution von binary-only ist unsicher für den Endanwender,
> ganz unabhängig davon, wie unsicher oder vertrauenswürdig der Hersteller
> selbst ist, denn hier muss auch noch der Redistributor vertrauenswürdig
> sein, da durch das Fehlen der Quellen böswillig Schadfunktionen auf
> recht einfache Art und Weise untergebracht werden können. Das war die
> Begründung dafür, dass es kein vernünftiges Repository für Opera gibt.
> Und du kannst noch so oft mit einem ...


....wie gesagt, ueberpruef es.

> Wie kommst du dazu, das Vertrauen in den Hersteller mit dem Vertrauen in
> den Redistributor gleichzusetzen?


Weil es ueberpruefbar ist, welche Aenderung ich allenfalls gemacht habe.
Tust du das bei jedem Paket nachkontrollieren, koennte sich eventuell
nach einer gewissen Zeit sogar Vertrauen gegenueber mir einstellen.

> Das garantierst du? Für alle Pakete? Bist du bereit, das schriftlich
> niederzulegen? Z.B. auf der Projekt-Seite?


Natuerlich. Schlag mir einen ensprechenden Text vor.

> Und du testest und führst die angesprochenen Maßnahmen durch? Ich frage
> mich gerade, welche Pflichten deine obige Garantie so nach sich ziehen
> würde.


Natuerlich mach ich das. Falls etwas mit einem Paket nicht stimmt,
faellt das auf mich persoenlich zurueck. Deshalb ueberpruefe ich die
Pakete ensprechend.

>>Ueber die Debian Infrastruktur gibt es auch binary-only Pakete.

> Habe ich noch nicht gesehen. Beispiele?


blender (nur woody), nvidia driver, div. firmware pakete.. es sind
ziemlich viele.

> Na, da kann ich nur hoffen, dass du nicht zu "faul" bist, die Pakete
> immer ordentlich zu überprüfen. Vor allem wenn das Projekt wachsen
> sollte. Bei Gelegenheit wirst du dann vielleicht an deine "Garantie"
> denken.


Wenn dus mir nicht glaubst, was dein gutes Recht ist, kann ich dich nur
nochmals aufforden, es zu ueberpruefen.
gerhard (22.09.2005, 00:40)
Am Mittwoch 21 September 2005 15:27 schrieb Daniel Leidert:
> Ja klar. Alibi-Argument? Ich traue Opera, aber warum soll ich dir
> oder den Binary-only-Paketen in deinem Repository trauen?
> Wunschdenken, dass du und alle Uploader liebe, nette Menschen sind,
> die niemandem etwas böses wollen? Und das bei closed-source-Paketen?
> Jeder mit etwas Verantwortungsbewusstsein, würde eine derartige
> Garantie deutlich von sich weisen. Es sagt für meinen Geschmack schon
> viel aus, dass du dich um die Beantwortung relevanter Fragen drückst.
> Nur interessehalber: Gibt es im Projekt totalitären
> Führungscharakter?


Warum traust Du bitte Opera? Hast Du schon mal über Vertrauen und
Totalitarismus nachgedacht, oder über binary only?

Hier gibt jemand als Service ein binary eines Fremdherstellers als
Service an Leute weiter die Ihm vertrauen - ist doch super. Du mußt das
Angebot ja nicht nutzen. Manipulieren ja alle an binary-only Paketen
herum.

Zugegebenermaßen ist es ja gerade deswegen in debian nicht enthalten,
was ja auch gut ist - Daniel hat das ja übrigens auch schon gesagt.
Ich würde auf meinem production server auch kein opera installieren.

ciao

Gerhard
Daniel Leidert (22.09.2005, 14:20)
Am Donnerstag, den 22.09.2005, 00:19 +0200 schrieb gerhard:
> Am Mittwoch 21 September 2005 15:27 schrieb Daniel Leidert:
> Warum traust Du bitte Opera?


Persönlicher Erfahrungswert.

> Hast Du schon mal über Vertrauen und
> Totalitarismus nachgedacht, oder über binary only?


Worauf willst du hinaus?

> Hier gibt jemand als Service ein binary eines Fremdherstellers als
> Service an Leute weiter die Ihm vertrauen


[ironie]Machen Swen und Co doch auch.[/ironie] In deinem Satz steckt
etwas, was so generell nicht als gegeben angesehen werden kann bzw.
darf: "(unverändert) weitergeben". Um das zu bestätigen muss ich jedes
mal das komplette Paket gegen das des Herstellers prüfen. Im Gegensatz
dazu steht die Möglichkeit: Ich hole mir die Software beim Hersteller -
was ich ja sowieso tun muss, damit ich das Redistributor-Paket
überprüfen kann. Dann habe ich gar nicht erst das Problem, dass
Manipulationen von Seiten Dritter vorgenommen werden könnten. Als
Beispiel, wie ich beides vereinen kann, sei das fglrx-installer-Paket
genannt (und schau mal auf die Warnhinweise auf Flavios Seite). Da wird
konsistent das Paket vom Hersteller geholt und in den Prozess des
Paketebaus eingebunden. Vorausgesetzt, man versteht auch die Patches,
ist der gesamte Bau des Pakets absolut konsistent. Sollte das bei
debian-unofficial irgendwann mal der Fall sein, dass ich konsistent die
Quelle und das Verarbeiten der Binaries anhand der Quellen
nachvollziehen kann, wird sich meine Meinung zu binary-only-Paketen aus
diesem Repository vielleicht ändern. Aber momentan sehe ich nur
entpackte Quellen, die zugegeben zum aktuellen Zeitpunkt einer
Überprüfung mittels MD5-Summen standhalten.

> - ist doch super. Du mußt das
> Angebot ja nicht nutzen.


Nicht nur das, ich empfehle es aus hinreichend dargelegten Gründen auch
generell niemandem.

MfG Daniel
Marc Blumentritt (22.09.2005, 14:50)
Daniel Baumann schrieb:

> deb sarge main contrib non-free
> restricted


Die Seite kannte ich noch nicht.
Danke
Marc
Daniel Baumann (22.09.2005, 15:10)
Daniel Leidert wrote:
> Als
> Beispiel, wie ich beides vereinen kann, sei das fglrx-installer-Paket
> genannt (und schau mal auf die Warnhinweise auf Flavios Seite). Da wird
> konsistent das Paket vom Hersteller geholt und in den Prozess des
> Paketebaus eingebunden. Vorausgesetzt, man versteht auch die Patches,
> ist der gesamte Bau des Pakets absolut konsistent.


Installer-Pakete haben drei Nachteile:

0. waehrend er Paketinstallation muss eine Internetverbindung vorhanden
sein (die meisten Installerpakete unterstuetzen es nicht, dass man das
Upstreamfile lokal angeben kann).

1. auf dem Zielsystem muessen dev-Pakete installiert sein, damit das
Paket gebaut werden kann. Je nachdem ist das nur debhelper/fakeroot etc.
oder eine komplette Build-Umgebung (z.B. fglrx, nvidia etc.).

2. mehr Aufwand, sowohl zeitlich gesehen als auch von den eingesetzen
Ressourcen.

> Sollte das bei
> debian-unofficial irgendwann mal der Fall sein, dass ich konsistent die
> Quelle und das Verarbeiten der Binaries anhand der Quellen
> nachvollziehen kann, wird sich meine Meinung zu binary-only-Paketen aus
> diesem Repository vielleicht ändern.


Obwohl ich keine Installer-Pakete mache, kann man das trotzdem sehr
einfach ueberpruefen.

> Aber momentan sehe ich nur
> entpackte Quellen, die zugegeben zum aktuellen Zeitpunkt einer
> Überprüfung mittels MD5-Summen standhalten.


Siehst du, Ziel erreicht. Mehr will und tu ich doch gar nicht ;)
Daniel Leidert (22.09.2005, 15:50)
Am Donnerstag, den 22.09.2005, 14:33 +0200 schrieb Daniel Baumann:
> Daniel Leidert wrote:
> Installer-Pakete haben drei Nachteile:


Das Installer-Paket war ein Beispiel.

> 0. waehrend er Paketinstallation muss eine Internetverbindung vorhanden
> sein (die meisten Installerpakete unterstuetzen es nicht, dass man das
> Upstreamfile lokal angeben kann).
> 1. auf dem Zielsystem muessen dev-Pakete installiert sein, damit das
> Paket gebaut werden kann.


JFTR: Es benötigt keine dev-Pakete, um ein Archiv zu holen, zu entpacken
und daraus das Paket zu bauen.

> Je nachdem ist das nur debhelper/fakeroot etc.


In dem Fall zusätzlich wget und gzip/bzip2/rpm - je nach Archiv.

> oder eine komplette Build-Umgebung (z.B. fglrx, nvidia etc.).
> 2. mehr Aufwand, sowohl zeitlich gesehen als auch von den eingesetzen
> Ressourcen.


Nein. definitiv nicht. Du benötigst so oder so das Quellpaket, eine
Internetverbindung und entpacken musst du es auch. Woher soll der
Mehraufwand an Resourcen kommen? Es benötigt sicherlich etwas mehr Zeit,
das zu skripten.

Der große Vorteil aber: Mehr Konsistenz, einfachere Überprüfung ohne
dass ich 2 Pakete/Archive entpacken und gegeneinander vergleichen muss.

> Obwohl ich keine Installer-Pakete mache, kann man das trotzdem sehr
> einfach ueberpruefen.


Definiere "einfach". Man benötigt: dein Paket, das Hersteller-Paket,
Hashsummen. Mit Download der Quellen vom Hersteller ohne Umweg benötige
ich nur dein Quellpaket, um zu verifizieren, was du tust. Und mit ein
wenig Willen, kann man sogar in den Paket-Dateien eine
Hashsummen-Prüfung unterbringen, um das heruntergeladene Archiv zu
verifizieren. Mehr Konsistenz, mehr Sicherheit. Zusätzlicher Vorteil:
Das Quellpaket selbst wäre nur sehr klein.

> > Aber momentan sehe ich nur
> > entpackte Quellen, die zugegeben zum aktuellen Zeitpunkt einer
> > Überprüfung mittels MD5-Summen standhalten.

> Siehst du, Ziel erreicht.


Welches Ziel? Eine Momentaufnahme für ein Paket in einem Repsoitory zu
erstellen? Das ist keine Garantie. Und außerdem hat der Leser eigentlich
keinen Grund, mir zu vertrauen. Er müsste es selbst prüfen.

MfG Daniel
Daniel Baumann (22.09.2005, 18:40)
Daniel Leidert wrote:
> JFTR: Es benötigt keine dev-Pakete, um ein Archiv zu holen, zu entpacken
> und daraus das Paket zu bauen.


Kommt aufs Paket an.

>>2. mehr Aufwand, sowohl zeitlich gesehen als auch von den eingesetzen
>>Ressourcen.

> Nein. definitiv nicht. Du benötigst so oder so das Quellpaket, eine
> Internetverbindung und entpacken musst du es auch. Woher soll der
> Mehraufwand an Resourcen kommen? Es benötigt sicherlich etwas mehr Zeit,
> das zu skripten.


Installer Pakete fuer Kernel-related Dinge (z.b. nvidia/fglrx)
benoetigen eine Komplette Build-Umgebung (kernel-header, build-essential).

Alternativ dazu kann man einfach das ensprechende Modul-Paket
installieren, das das vorkompilierte Modul enthaelt. Das ist deutlich
weniger Aufwand, sowohl persoenlicher Zeitaufwand, Rechenzeit, Bandbreite..

(Der Vollstaendigkeithalber: nvidia/fglrx habe ich noch nicht gemacht.
Gleiches gilt aber fuer ipw2{1,2}00, welche seit geraumer Zeit im Archiv
sind).

> Der große Vorteil aber: Mehr Konsistenz, einfachere Überprüfung ohne
> dass ich 2 Pakete/Archive entpacken und gegeneinander vergleichen muss.


Man kann nicht alles haben. Wie *mehrmals* gesagt, ist es sehr einfach
zu ueberpruefen, ob ich die Binaries verglichen mit Upstream veraendert
habe oder nicht.

>>Obwohl ich keine Installer-Pakete mache, kann man das trotzdem sehr
>>einfach ueberpruefen.

> Definiere "einfach". Man benötigt: dein Paket, das Hersteller-Paket,
> Hashsummen.


und was ist daran schwierig? Stimmt, man sollte man md5sums gelesen
haben und ein kleinwenig mit einer Shell umgehen koennen.

> Mit Download der Quellen vom Hersteller ohne Umweg benötige
> ich nur dein Quellpaket, um zu verifizieren, was du tust. Und mit ein
> wenig Willen, kann man sogar in den Paket-Dateien eine
> Hashsummen-Prüfung unterbringen, um das heruntergeladene Archiv zu
> verifizieren.


Nutzlos.. woher weist du dann, dass meine Pruefsumme stimmt? Ergo musst
du es sowieso selber ueberpruefen mit einer Pruefsumme, die du selbst
kontrolliert hast.

> Mehr Konsistenz, mehr Sicherheit. Zusätzlicher Vorteil:
> Das Quellpaket selbst wäre nur sehr klein.


Nachteile: siehe oben.

> Welches Ziel? Eine Momentaufnahme für ein Paket in einem Repsoitory zu
> erstellen?


Was ist ein 'Repository' denn sonst?

> Das ist keine Garantie. Und außerdem hat der Leser eigentlich
> keinen Grund, mir zu vertrauen. Er müsste es selbst prüfen.


Ja, das hoffe ich instaendig.

Wir drehen uns im Kreis. Die Diskussion ist fuer mich beendet.

Ähnliche Themen