| |
|
Osterei im Debian-mICQ (Details-Update) |
|
|
Veröffentlicht durch XTaran am Mittwoch 19. Februar, 18:49
Aus der Kleine-Schweinereien Abteilung
|
|
|
|
|
Die Debian Weekly News von gestern weisen uns auf eine Diskussion auf der Debian-Entwickler-Mailingliste hin, in der es darum geht, ob mICQ (und in Zukunft auch andere Software mit gleichen Problemen) wegen nicht vertrauenswürdigen (Upstream-) Autoren komplett aus Debian entfernt werden soll. Auslöser dafür war, daß der Debian-Maintainer von mICQ beim Aktualisieren des Debian-Paketes übersehen hatte, daß die Autoren von mICQ ein Osterei eingebaut hatten, welches nur bei der Kompilation für Debian einkompiliert wird, verhindert, daß mICQ startet und noch einen Rant des aktuellen mICQ-Autors ausgibt.
|
|
|
|
< Swisscom: ADSL-Leistung wird gesteigert | Druckausgabe | Flexible Solarzellen aus Chip-Ausschuß > | |
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
Von Anonymer Feigling am Wednesday 19. February, 19:25 MEW (#1)
|
|
|
|
|
Osterei?
Oder doch eher Backdoor/Trojaner?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Auf der Debianliste wird von einem "Easter Egg" gesprochen, was üblicherweise ein neutraler Begriff für versteckte Programmteile ist, die nur unter Umständen ausgeführt werden.
In diesem Fall handelt es sich "nur" um einen Kleinkrieg zwischen dem Maintainer und den Autoren der verhindert, daß mICQ korrekt startet, außerdem gibt er noch einen kleinen Rant aus.
Ich update am besten grade mal den Artikel...
--
Einer der Gnutella-Klone heißt Gnutoka, und ich frag mich, wann Gnusspli rauskommt...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 20. February, 07:47 MEW (#3)
|
|
|
|
|
Der kluge Mann compiliert selber.
|
|
|
|
|
|
|
|
|
|
|
|
|
Und der kluge Maintainer kooperiert mit dem ursprünglichen Entwicklerteam - und kompiliert/testet den Code selbst, bevor er ihn weitergibt.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 20. February, 10:32 MEW (#6)
|
|
|
|
|
...hat der "kluge" maintainer auch getan, nur war das osterei so praepariert, dass es bei ihm nicht ausbrach.
|
|
|
|
|
|
|
|
|
|
|
|
|
Und der kluge Maintainer kooperiert mit dem ursprünglichen Entwicklerteam
ACK
und kompiliert/testet den Code selbst, bevor er ihn weitergibt.
NACK
Tja... Dummerweise war das Osterei folgendermassen gestrickt:
<code style="obfuscated">
wenn $DISTRO ist Debian
und $USERNAME ungleich Maintainer,
dann zeige $RANT und breche ab
</code>
...sprich für den Maintainer durch compilieren und starten nicht zu entdecken. Zudem war der Code virenähnlich getarnt, sprich ein "grep -ri Debian" , "grep -ri $MAINTAINER" oder "grep -ri $RANT" liefert genau null Treffer. Gerade die hinterhältige Tarnung des Codes zeigt nach üblicher Rechtsauffassung das Schuldbewusstsein des Programmauthors, ist ein Indiz für den vom Maintainer geäusserten Verdacht der geringen Vertrauenswürdigkeit des Programmauthors. Zitat: "Was kommt als nächstes, vielleicht ein 'rm -fr /'?". Fakt ist: Wenn der Package-Maintainer permanent Mist macht, haette ein schlichtes:
<code style="human-readable">
wenn EXTRA_VERSION nicht gesetzt,
dann zeige Fehlermeldung und breche ab
</code>
voll und ganz zur seriösen Problembehebung ausgereicht.
Was hingegen den Maintainer gerettet hätte, wäre ein einfaches "diff -ru micq-previous-version micq-new-version". Dieser Befehlt hätte ein paar Ungereimtheiten zu Tage gefördert: Wie etwa einen kleinen Programmfehler und halt diesen kryptifizierten Rantcode. Tja, irgendwie ist ein Package-Maintainer, der diesen grundlegenden Schritt der Qualitätsicherung nicht durchführt dann doch suspekt.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Thursday 20. February, 11:52 MEW (#8)
|
|
|
|
|
ehrlich gesagt das kannst du auch von einem upstream maintainer nicht 100% verlangen, schoen ist es aber sicher wenn er das macht! einige package maintainer haben mehr als genug packages die sie sich kuemmern muessen. und wie du sicherlich auch weisst wollen die user alle neuen packages so schnell wie moeglich.
ein package zu kreieren ist auch nicht eine sehr einfache aufgabe. obwohl ein update unterumstaenden schnell gemacht ist. jedoch sollte man dem eigentlichen autor trauen koennen!
was auch noch ist alle neuen packages kommen in unstable und erst nach einigen wochen ohne bug report kommt es in den testing und hier bleiben die bis zum release. damit auch genau solche sachen nicht beim normalen user nicht passieren.
von dem her gesehen bin ich absolut der meinung vom autor!
|
|
|
|
|
|