# Wenn bezahlte Hacker BUGS in opensource einschleusen ?

## artbody

Eine theoretische Frage mit katastrofalen Folgen im Falle daß

 bezahlte Hacker BUGS in opensource einschleußen .

Wie schützt sich die Opensource Gemeinde vor sowas?

Gibt es da Mechanismen?

Mir ist dies insofern wichtig, da es in letzter Zeit zu immer mehr "Systemausfällen" (für Desktopuser) kommt. Dies z.B. mal wegen einer Maus die nicht geht,  wie am letzten WE.

NVIDIA mal wieder SCHEISSSSSSE macht und nicht startet.... erst mal wieder neu emergen und eselect... 

ein emerge --sync 

emerge -euDN world vieleicht....

ZEITZEITZEIT:::::::GRRRRRRR

Egal ---

aber zurück zur Frage

Was wenn da bezahlte Absicht dahinter steckt.

 :Evil or Very Mad: 

Was wenn M$, S a p und alle Helfershelfer den Konkurrenten Linux auf diese Weise aus dem Spiel werfen.

----------

## ChrisJumper

Hi artbody!

Also ich denke nicht das das so viel ändern würde. Denn eigentlich ist das ja schon der Fall ;)

Aber das was du meinst sind keine Bugs sondern Fehler die sich für exploits ausnutzen lassen.

Und dafür gibt es definitiv einen Schwarzmarkt auf dem sich bestimmt auch Geld bewegt.

Allerdings betrifft dies nicht nur OpenSource sondern auch die restliche Software. Generell ist es alles eine Frage des Vertrauens. Ich denke nicht das ein Unternehmen freiwillig solche Lücken einbaut. Auszuschließen ist es aber nicht. Dies gilt aber genauso wenig für den normalen Programmierer in einem Unternehmen der z.B. Treiber programmiert den keiner mehr nachguckt.

Generell hält es sich aber irgendwie die Waage, einfach weil niemand gerne Code auf seinem Rechner hat der irgendwo faul ist. Und was Open Source betrifft: Hier gibt es verschiedene Meinungen. Mache behaupten man kann leichter Schwachstellen finden und die Ausnutzen. Andere sagen man kann aber mit Hilfe dieser Information (Quelltext) schneller erkennen welche Schwachstelle wahrscheinlich ausgenutzt wurde usw...

Generell darf nicht jeder Code schreiben für einen Kernel oder ein großes Projekt. Da muss man sich erst erarbeiten, vertrauen gewinnen und sich seine Kenntnisse bewiesen. All das ist bestimmt viel Aufwendiger als nach einem Bug zu suchen, der schon drin ist. Den man ausnutzen könnte. Von daher würde das niemand machen.

Denn wer wohl einmal den Ruf hat sowas zu machen.. wird wohl nicht so leicht an einem anderen Projekt mitarbeiten können.

Oh und nochwas: Stell dir vor du hast die Stelle eingeschleust: Es sind dann nur Programme betroffen die die aktuelle Version benutzen. Testet jemand diese unstable Software und sie Funktioniert nicht wie erwartet sucht man nach Fehler (oder man bleibt bei der alten). Und das gebündelte Interesse diesen Fehler zu finden und zu patchen ist zumindest bei bedeutenden Projekten hinreichend groß das sich der Fehler "relativ schnell" finden lässt. Wenn das nicht den Gewünschten Effekt hat kommt das Codefragment (hoffentlich) nicht zum Einsatz.

Lg Chris

----------

## ChrisJumper

 *Quote:*   

> Gibt es da Mechanismen?

 

Die Evolution :)

----------

## blu3bird

 *ChrisJumper wrote:*   

>  *Quote:*   Gibt es da Mechanismen? 
> 
> Die Evolution 

 

Um konkrete Beispiele zu nennen:

Linux-Kernel:

Ein Bösewicht will Fehler in den Kernel einbauen, einfach einen Patch an die LKML schicken wird nicht funktionieren, da den Patch dort zu viele Leute überprüfen/lesen. Wenn der Bösewicht sich aber bereits zum Kernel-Dev mit git-Zugriff hochgearbeitet hat kann er den Patch reinknallen, aber auch dann schaut sich noch mindestens ein anderer Kernel-Dev den Patch an.

Gentoo:

(Erinnert irgendwie an [url="https://forums.gentoo.org/viewtopic-t-546225.html"]Bundestrojaner über Portag?[/url]  :Wink: )

Wenn jemand Gentoo-Dev werden will gibt es eine 1-Monatige Probezeit in der sein Ausbilder(Mentor, ein anderer Gentoo-Dev) für seine Handlungen verantwortlich ist. Das dient dazu dass die existierenden Devs nicht irgendwelche wildfremden ins Boot hohlen, sondern nur Leute denen sie zumindest bis zu einem bestimmten Limit vertrauen(unter anderem).

Und die Moral von der Geschicht: Bei allen Open-Source Projekten muss dich ein existierender Entwickler reinhohlen und das wird er nur machen wenn er dir vertraut..also möglich wäre es, mit viel Zeit, aber wirklich einfacher als einem großen Softwarehaus ne Bewerbung zu schicken, da dann eine Zeit lang zu arbeiten und den Source zu sabotieren ist es nicht.

----------

## schachti

Und selbst wenn sich jemand "hochgearbeitet" hat: Es gibt in der Regel immer mindestens ein anderes Augenpaar, das sich den Code anguckt. Das Risiko, dass eine Manipulation entdeckt wird, ist zumindest bei größeren Projekten relativ groß.

----------

## dertobi123

 *artbody wrote:*   

> Mir ist dies insofern wichtig, da es in letzter Zeit zu immer mehr "Systemausfällen" (für Desktopuser) kommt. Dies z.B. mal wegen einer Maus die nicht geht,  wie am letzten WE.
> 
> NVIDIA mal wieder SCHEISSSSSSE macht und nicht startet.... erst mal wieder neu emergen und eselect... 
> 
> ein emerge --sync 
> ...

 

1.) Was hat das mit der ausgehenden Fragestellung zu tun?

2.) Wer ein ~x86/~amd64/~whatever System benutzt, muss davon ausgehen, mit genau solchen Problemen konfrontiert zu werden

3.) Wer Hardware kauft, deren Nutzung zu großen Teil bekanntermassen von proprietären Treibern abhängig ist, nimmt bewusst in Kauf, sich hier in eine Abhängigkeit zu dem Hardwarehersteller zu begeben.

----------

## TheSmallOne

 *schachti wrote:*   

> Und selbst wenn sich jemand "hochgearbeitet" hat: Es gibt in der Regel immer mindestens ein anderes Augenpaar, das sich den Code anguckt. Das Risiko, dass eine Manipulation entdeckt wird, ist zumindest bei größeren Projekten relativ groß.

 

Hm, sind nicht größere Projekte eher unübersichtlich und somit die Anzahl derer, die sich tatsächlich damit beschäftigen so gesehen eher gering?

Aber um auf die ursprüngliche Situation einzugehen: Ich schätze das hängt alles davon ab, wieviel so ein Manipulator bereit ist zu zahlen. Wenn er es sich leisten kann ein ganzes Team an Entwicklern zu "bestechen", dann hat er natürlich mehr Chancen als jemand der keine finanziellen Mittel hat.

----------

## STiGMaTa_ch

Die Gefahr ist relativ klein.

Wie bereits schon gesagt wurde kann man zwar den Code relativ leicht ändern, diesen aber Upstream zu bringen wird ohne "Vertrauen" schwierig. Aber gehen wir doch einfach einmal davon aus, dass DR. EVIL seinen Code unbemerkt einschleusen konnte und das Paket nun auf allen Mirrors verfügbar ist. Was hat er nun dadurch erreicht? Im Moment noch gar nichts. Enduser saugen sich keine Sourcen herunter und kompilieren diese. Also muss DR. EVIL erst einmal warten, bis sich die Maintainer von z.B. SuSE, RedHat, Debian, Gentoo etc. die Pakete saugen.

Diese gehen nun aber nicht einfach hin, saugen sich das Paket, kompilieren (resp. erzeugen ein ebuild) es und schieben es in die Distribution. Nein, da wird erst einmal getestet was sich geändert hat, ob noch alle Abhängigkeiten stimmen etc. Und bereits an diesem Punkt läuft DR. EVIL gefahr, dass sich jemand den Code genauer anschaut. Denn was man nicht vergessen darf, der jeweilige Maintainer muss sich nicht durch jede Zeile des Codes kämpfen, sondern er kann ganz einfach einen diff über die geänderten Sourcen laufen lassen und sieht so was verändert wird. Selbst wenn der eigentliche Code also Millionen von Zeilen und tausende von Dateien beinhaltet, so sind im Endeffekt vielleicht nur einige hundert Codezeilen sowie einige Dutzend Dateien anzuschauen.

Und bei grossen Distributionen wie Redhat oder SuSE wird es bestimmt Leute geben, welche sich die Änderungen ganz genau anschauen. Denn die haben richtig was zu verlieren, wenn Ihnen sowas durch die Lappen fliegt.

Ausserdem muss man auch bedenken, dass viele Tools nicht nur für Linux sondern auch für z.B. BSD Systeme oder Solaris Systeme verwendet werden. Und viele Tools welche aus dem Linux Lager kommen und auf diese - ich nenne sie einfach mal so - exotischen Systemen laufen müssen, werden besonders genau angeschaut (allein schon um sicher zu stellen, dass der Code auf diesen Systemen auch wirklich funktionsfähig ist und sich nichts Linuxspezifisches darin befindet).

Aber gehen wir mal davon aus, dass es DR. EVIL tatsächlich schafft auch diese Hürde zu meistern. Jetzt gäbe es also unzählige Systeme, die eingeschleusten Code enthalten würden. Die Frage ist dann immer noch, wie kommt DR. EVIL an das, was der böse Code da auch immer erfasst oder durch die Hintertür welche das Programm aufreisst?

Wenn das System nicht im Internet steht, wird es schon verdammt schwierig. Dann müsste er direkten Zugriff auf einen Rechner haben. Und wenn er diesen tatsächlich hat, dann wird er all die oben genannten unsicheren Umstände sicherlich nicht in kauf nehmen. Dann wäre es einfacher für Ihn einen Keylogger zu installieren oder sonstige Schadsoftware zu installieren, ohne "fremden Code" zu manipulieren.

Aber in dem Moment, in dem er "über das Netz" kommen müsste, hätte er das Problem, dass es einen ganzen Haufen Leute auf diesem Erdball gibt, welche mit Sniffern etc. die versendeten Pakete analysieren. Und irgend einem von denen würde ganz bestimmt irgend wann etwas "komisches" auffallen.

Von daher glaube ich nicht, dass die Chance für solch einen Fall wirklich gross ist. Aber völlig ausschliessen kann man es natürlich nicht.

Lieber Gruss

STiGMaTa

----------

## artbody

Erst mal Danke für die ausführliche Erklärung.

Ist auf jeden Fall mal beruhigend.

Allerdings meinte ich nicht im Code irgendwelche größeren Dinge zu bewegen, das ist klar. Sowas fällt auf.

Nein ich dachte da eher an die kleinen Missgeschicke. Wie eben  am letzten WE daß die Maus nicht geht.

Zuerst "Symbol not found" und nach einem emerge -e world (hatte keine Lust alles auseinander zu suchen) gab es den Fehler nicht mehr, aber die Maus ging trotzdem nicht.

Erst am Montag mit einem update einiger xf86-input* ging es wieder.

Also eher Sabotage an Kleinigkeiten, wo jeder Programmierer sagt:"Ok kann ja mal passieren, sollte zwar nicht, aber .... naja tut ja wieder..."

Für einen Enduser , welcher nur unter Grafischer Oberfläche arbeitet ein untragbarer Zustand.

Passiert sowas ein paar Mal wird der Schrei nach M$ lauter als einem Systemadmin lieb ist.

----------

## tamiko

Sagen wir es mal so:

Glaubst du dass ein Programmierer, der an einem Projekt mitarbeitet, lange dabei ist, wenn er nur Mist abliefert?

Aber angenommen er wäre tatsächlich dabei, und würde Bugs am laufenden Band produzieren, würdest du das wahrscheinlich nicht mitbekommen.

Die Ebuilds werden, bevor sie als ~... aufgenommen werden bestimmt ersteinmal auf prinzipielle Funktionalität getestet, und bevor sie als stabil gekennzeichnet werden, wird schon etwas genauer überprüft, ob sie das tun, was sie sollen.

Bei anderen Distributionen ist dies sicherlich genauso, wenn nicht stellenweise noch wesentlich gründlicher.

Anders sieht es natürlich bei Closed-Source-Komponenten aus. (vgl. Kommentar von dertobi123)

Ich würde deshalb sagen, dass eine ordentlich eingeleitete FUD-Kampagne in Kombination mit illegalen Kartellabsprachen und dem gnadenlosen Ausnutzen von Monopolen (z.B. jeder PC gebündelt mit M$-Produkten.) wesentlich erfolgsversprechender ist.

So etwas hat bei Windows vs. OS2/Warp (also proprietärem Gegner) schon einmal funktioniert, wieso soll es dann gegen OpenSource nicht auch funktionieren?   :Rolling Eyes: 

Grüße,

Tamiko

----------

## schachti

 *TheSmallOne wrote:*   

>  *schachti wrote:*   Und selbst wenn sich jemand "hochgearbeitet" hat: Es gibt in der Regel immer mindestens ein anderes Augenpaar, das sich den Code anguckt. Das Risiko, dass eine Manipulation entdeckt wird, ist zumindest bei größeren Projekten relativ groß. 
> 
> Hm, sind nicht größere Projekte eher unübersichtlich und somit die Anzahl derer, die sich tatsächlich damit beschäftigen so gesehen eher gering?

 

Größere Projekte sind oft besser organisiert, siehe zum Beispiel den Kernel. Jedes größere Modul hat einen Maintainer, der sich mit dem speziellen Gebiet auskennt und Patches sehr genau anschaut. Bei kleineren Projekten ist das eher nicht so straff organisiert.

 *artbody wrote:*   

> 
> 
> Also eher Sabotage an Kleinigkeiten, wo jeder Programmierer sagt:"Ok kann ja mal passieren, sollte zwar nicht, aber .... naja tut ja wieder..."
> 
> Für einen Enduser , welcher nur unter Grafischer Oberfläche arbeitet ein untragbarer Zustand.
> ...

 

Der typische Enduser, für den sowas ein untragbarer Zustand ist, fährt sicher nicht gentoo und installiert bestimmt nicht dauernd die aktuelle Version sämtlicher installierter Software - der nimmt sich SUSE und ist damit 2 Jahre glücklich, und innerhalb dieser 2 Jahre liefert SUSE in der Regel nur Patches für die installierte Software, ohne einen Versionssprung zu machen. Wer ein "Bastelsystem" wie gentoo hat und regelmäßig neue Versionen installiert weiß auch, dass durchaus mal was kaputtgehen kann.

----------

## TheSmallOne

 *schachti wrote:*   

> Größere Projekte sind oft besser organisiert, siehe zum Beispiel den Kernel. Jedes größere Modul hat einen Maintainer, der sich mit dem speziellen Gebiet auskennt und Patches sehr genau anschaut. Bei kleineren Projekten ist das eher nicht so straff organisiert.

 

Naja, das heißt doch im Prinzip, dass größere Projekte - ich sag' mal - "gesplittet" sind. Also niemand kennt sich mehr mit dem gesamten Code aus, sondern jeder befasst sich nur noch mit einem Teilgebiet.

Und das macht es doch eigentlich, für das hier angedachte Szenario (jemand macht sich die Programmierer mit genug Geld gefügig), gefährlicher, weil man nur wenige Leute bestechen muß. Nämlich genau die, die für diesen Teil des Projekts zuständig sind. Und auch bei denen reicht es doch dann nur etwa die 2/3 der Leute zu bestechen, die "am wichtigsten" sind, also deren Meinung am meisten Gewicht hat, z.B. weil sie am längsten dabei sind, oder sich anderweitig durch gute Arbeit einen Namen gemacht haben. Wenn dann jemand ankommt und sagt: "Da in eurem Code stimmt was nicht" und der Großteil der Verantwortlichen antwortet "passt schon", dürfte man es nicht so leicht haben, sich dagegen durchzusetzen, da ja auch die übergeordneten Verantwortlichen sich nicht mit dem kompletten Code auskennen, sondern sich auf das Wort derjenigen verlassen müssen, die besagten Code "wie ihre Westentasche kennen".

Allerdings scheint mir das Szenario an sich doch eher in Richtung Paranoia zu gehen, denn als reale Bedrohung.

----------

## artbody

 *schachti wrote:*   

> ...der nimmt sich SUSE und ist damit 2 Jahre glücklich,...

 

Hm  :Question: 

Da wiederspreche ich dir jetzt mal aus eigener Erfahrung.

Als das noch SuSE GmbH war, war es mit der Zufriedenheit sicher wie du es gesagt hast.

Aber als die AG wurden gings bergab...

Als alter Linuxer hat man für so gewisse einfache Dinge eine Vorliebe

GentooFilemanager - schnell,einfach zu konfigurieren und schlicht

Enlightenment

Scite als Editor

3 Progs die bei mir eigentlich immer im Einsatz sind

Suse bastelte ja eh immer sein eigenen Müll, so ließ sich enlightenment weder von rpm noch vom source installieren.

Scite nur nach ein paar Änderungen

Gentoo filemanager musste auch von extern angepasst werden...

Bin dann auf Mandrake Cooker umgestiegen und kenne somit das mit der Bastelei

Als die aber Mandriva wurden wars dort auch vorbei mit gut.

Nur noch schnell schnell die nächste Version...

Ja und da kam ich zu gentoo Linux

Ist in meinen Augen auch eines der besten Linuxe

 :Very Happy: 

Was mich zu gentoo Linux überzeugt hatte war eben der Punkt: permanenter Update

Wenn ich nur daran denke was das bei Suse von 8.x auf 9.0 für eine Katastrophe war

Als alter Linuxer hatte ich wie viele 3 Installationen 

1. als laufendes System

2. Testumgebung ähnlich 1 wo updates eingespielt und erst mal alles ausprobiert wurde

3. Notsystem (2.Platte)

Ja und bei oben genanntem Update hat der Suseinstaller ohne zu fragen Installation 1 zum Teil gelöscht und z.B. /var/lib/mysql mit dem auf Installation 2 als Link ersetzt....

Da war ich extrem sauer. Ok 

Aber man gibt ja nicht auf. Backup war ja vorhanden, somit nicht so schlimm.

Also Instalation 1 und 2 plattgemacht und 1. neu aufgesetzt - ok bis auf diverse fehlende tools

2te angefangen wollen, aber die InstallationsCD verweigerte das und hat sich auch im expertenmodus nicht dazu bringen lassen ein 2. System auf die Platte zu setzen.

Auch auf die 2.Platte nicht.

OK- genug davon 

Mandrake...Mandriva  :Evil or Very Mad: 

AMD x2 probleme

Gentoo ....   :Laughing: 

und noch ein Vorteil von Gentoo ist die Community hier im Forum.

und ich habe seit Gentoo viel Linux gelernt.

Zurück zum User(W) 

Ist seither auch supper zufrieden - nur wenn übers WE die Maus nicht geht 

wer ist dann schuld  :Rolling Eyes: 

DER ADMIN 

 :Laughing: 

Wer darf dann nur noch für Sekunden an seinen Rechner

DER ADMIN 

 :Shocked: 

Das ist dann so bis der Mauszeiger wieder geht.

 :Laughing: 

----------

## artbody

Nun ein Wochenende lang kackt die Maus ab 

und jetzt die Tastatur.....  :Laughing: 

https://forums.gentoo.org/viewtopic-t-588884-postdays-0-postorder-asc-start-25.html

 *Quote:*   

> Now again my Win keys won't work, and neither will my Alt-Gr.

 

M$'s Billy freut sich

daß seine Behauptung unbrauchbar langsam zutrifft

.........

Ich mach fast schon ne Wette daß der ein paar arme OS-developer gekauft hat.

und erzähl hier jetzt keiner daß die fehlerfrei arbeiten..

bei "trivialcodingerrors" fliegt doch keiner aus dem Team.

----------

## tamiko

@artbody:

Ich habe das Gefühl, du willst hier mit allen mitteln die Paranoia schüren  :Very Happy: 

Ich habe bis jetzt keine Probleme mit meinen Eingabegeräten gehabt.

Aber deine Idee von gekauften Entwicklern, die die Open-Source-Gemeinschaft von Innen zerstören sollen, hat was.

Aber wie gesagt - es gibt so viele Möglichkeiten Open-Source-Programmen zu schaden, da ist das gezielte Einschleußen von Bugs sicherlich nicht die Effizienteste.

Grüße,

Tamiko

----------

## misterjack

xorg-server-1.4.* ist ja auch als testing makiert, da muss man mit sowas rechnen ...

----------

## think4urs11

 *artbody wrote:*   

> M$'s Billy freut sich ... Ich mach fast schon ne Wette daß der ein paar arme OS-developer gekauft hat.

 

FUD-Alarm

----------

## schachti

 *artbody wrote:*   

> 
> 
> Ich mach fast schon ne Wette daß der ein paar arme OS-developer gekauft hat.
> 
> 

 

Ich glaub's erst, wenn mein gentoo sich mit einem Blue Screen of Death verabschiedet.   :Laughing: 

----------

## artbody

BlueScreen   :Laughing:   Das wäre sicher zu offensichtlich.

@all ich will ja nicht den Teufel an die Wand malen, aber in den letzten wochen häuft sich das mit den Bugs in Bezug auf

Xorg, Maus und jetzt Keyboard (AltgGR und NumLoc..)

und bei einer Neuinstalation (2 fast laufende gentoo reichen ja nicht,  :Evil or Very Mad:   eben wegen dem fast)

jetzt tut das keyboard nicht und der sound momentan auch noch nicht.

Macht zusammen 3 fast funktionierende Gentoo's

Vieleicht dringt dieses Thema mal bis zu den Dev's durch  :Shocked: 

----------

## misterjack

Es gibt auch noch die berühmt-berüchtigten CKI-Fehler, die man nicht unter den Tisch kehren sollte.

Chair-Keyboard-Interface

Von den ganzen Fehlern merk ich merkwürdigerweise auf mindestens 2 Systemen nullkommanichts.

 *artbody wrote:*   

> Gentoo's [...] Dev's

 

Seit wann apostrophiert man Plural-s? Setzen, sechs.

----------

## dertobi123

 *artbody wrote:*   

> Vieleicht dringt dieses Thema mal bis zu den Dev's durch 

 

Möglicherweise etwas provokant - aber vielleicht dringt zu Anwendern auch mal durch, dass stable stable ist und testing nicht stable ist?

----------

## Finswimmer

 *artbody wrote:*   

> BlueScreen    Das wäre sicher zu offensichtlich.
> 
> @all ich will ja nicht den Teufel an die Wand malen, aber in den letzten wochen häuft sich das mit den Bugs in Bezug auf
> 
> Xorg, Maus und jetzt Keyboard (AltgGR und NumLoc..)
> ...

 

Ich habe irgendwie das Gefühl, dass du mit Gentoo noch nicht so vertraut bist, wie es sein sollte.

Oder du hast irgendwelche anderen Fehler im System.

Habe eben erst, weil ich die ganze Zeit nur GPRS Internet hatte, auf xorg-1.4 upgegradet.

Was soll ich sagen. 

No problem.

Ich würde also eher die Devs loben  :Smile: 

Tobi

----------

## pablo_supertux

@artbody: bist du sicher, dass es sich nicht eher um ein PEBCAK Problem handelt?

 *Quote:*   

> 
> 
> Vieleicht dringt dieses Thema mal bis zu den Dev's durch
> 
> 

 

damit das passiert musst du

1. bug unter bugs.gentoo.org melden

2. mehr Information geben als "geht nicht"

3. Hinweise geben, was du gemacht hast, welche Versionen du installiert hast, was genau "geht nicht" bedeutet, usw.

sonst wirst du nicht ernst genommen und eher als Troll abgestempelt.

----------

## artbody

Heute scheint bei mir wieder so ein Tag yu sein, wo ich wirklich denke da- hier sabotage betrieben wird.

Nacheinem emerge -uDNeav world

 :Arrow:  Netzwerk abgeschossen

 :Arrow:  deutsche tastatur weg

.......

wieder xx Stunden   :Arrow:  f[r|n Arsch

Also dem Netywerk mu-, uch nun immer erst mal per root ein default gatewaz beibringen

und das tastaturproblem seht ihr ja yz -/ und anstatt ü ... kommt us tastatur ...  ;'[

ICH WILL MIT LINUX ARBEITEN UND KEIN CONFIG JUNKZ WERDEN

es ist yum reinschlagen

HASS ungeb'ndigter HASS auf die verworrene unf'higkeit 

sicher auch auf meine eigene, weil ich nicht jedem von dilitanten begangenen Fehlern mit einer 

BEFEHLSYEILE gegen[bertreten kann.

Kotzt mich an.

Irgendwas l'uft da doch falsch

 :Embarassed:   :Embarassed:   :Embarassed: 

----------

## disi

Also zum Thema, 

es gab da ja den Skandal mit Web 2.0. Wo Leute bezahlt wurden (war es Microsoft?) auf Wikipedia falsche Eintraege zu machen. Auf Youtube gab es den Skandal mit der Werbung in den Videos.

Also die Gefahr ist schon allgegenwaertig   :Exclamation: 

zum OT: ich kann das nicht bestaetigen, ich habe am Sonntag mein gesamtes System neu aufgesetzt (Wechsel von x86 zu x86_64). ACCEPT_KEYWORDS="amd64" und alles laeuft rund. Nur bei den Modulen der Hardwarehersteller fahre ich ** weil ich sonst Probleme bekomme und die neuesten meistens besser laufen.

----------

## schachti

artbody: revdep-rebuild und etc-update ordnungsgemäß durchgeführt? Evtl. Ausgaben bei emerge beachtet?

----------

## b3cks

Baselayout update gemacht? https://bugs.gentoo.org/show_bug.cgi?id=205894

----------

## artbody

hab ich

letzter update also emerge -uDN world ist erst 14 Tage her

gestern auf heut hab ich ein -e mitdayu gemacht..

Es ist ja nicht so, dass ich die Fehler hier als hilfe poste

Netzwerk geht halt nur wie oben beschrieben.

die entsprechenden configs wurden nicht ver'ndert

cups ebenso -- sprich der drucker druckt zwar aber es ist nichts auf dem papier.

h;rt sich wie ein echter BUG an

revdep/rebuild

```
 * Checking dynamic linking consistency

[ 16% ]  *   broken /usr/bin/lpr.orig (requires libgnutls.so.13)

[ 50% ]  *   broken /usr/lib64/gkrellm2/plugins/gkrellmms.so (requires libaudacious.so.5)

[ 100% ]                 

 

```

Hab dayu was realistisches als Frage gepostet.

https://forums.gentoo.org/viewtopic-p-4734878.html#4734878

----------

## artbody

aliase f[r diesen text

z y

y z.... 

weil meine Tastatur dumpfbackig troty unver'nderter config pl;tylich nur noch US kann

b3cks mit dem Netywerk hast du recht der BUG ist es

```
netstat -rn

Kernel IP Routentabelle

Ziel            Router          Genmask         Flags   MSS Fenster irtt Iface

0.0.0.0         192.168.2.1     255.255.255.255 UGH       0 0          0 eth0

192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo

0.0.0.0         192.168.2.1     0.0.0.0         UG        0 0          0 eth0

```

hab das ja auch als root kurzerhand mit

route add default gw  192.168.2.1

gel;sst- aber das ist genau der Zustand eines Rechners der ihn nur noch f[r root benutzbar macht

weil nach einem Neustart erst mal root so ne Kacke reparieren muss

allein die Zeit die einen sowas kostet....

ich dachte bei gentoo wird unfertiges als masked gehandhabt

und erst wenn man sich sicher ist, dass es auch geht und stabil l'uft...

Ich h'tte kein Problem damit ein Testszstem paralell yu fahren, aber unmasked ist gleich sabil scheint bei gentoo irgendwie nicht gany yu harmonieren

----------

## Finswimmer

 *artbody wrote:*   

> aliase f[r diesen text
> 
> z y
> 
> y z.... 
> ...

 

Setz das "route add..." einfach in die /etc/conf.d/local.start

Und bitte achte auf deine Schreibweise, auch wenn schwierig ist mit US Layout zu schreiben, kann man damit doch einen ansehnlichen Text produzieren.

Tobi

----------

## artbody

default route

 *Quote:*   

> Setz das "route add..." einfach in die /etc/conf.d/local.start 

 

ok geht

1. punkt für Inkonsistens im System

Das keyboard auf de

 *Quote:*   

> Create /etc/hal/fdi/policy/x11-input.fdi 

 

ok geht

2.punkt für Inkonsistens im System

Drucker

emerge -- unmerge gkrellmms 

+.....Datei /usr/bin/lpr musste ich von hand löschen

emerge -ueDNav cups

revdep-rebuild

ok läuft

---drucker tut auch wieder

letzter sync

und vieleicht über Nacht 

nochmal emerge -ueDNav world

-ahahahahahhahhahhahahha

hängt sich an der falschen dateigröße von nvidiatreiber auf

uahuahahahah

-----------------

genug für heut 

ein halber Tag am Arsch

vieleicht sollten die Entwickler von Gentoo mal über eine gestaffelte variante von masked nachdenken

1. masked = kann muss aber net eventuell und ....  :Rolling Eyes:   :Idea:   :Question: 

2. test = normal tut alles aber immer wieder Ärger mit Kleinigkeiten (entspricht so ungefähr einem derzeitigen immer wieder upgedateten system)  :Embarassed: 

3. stable = workstation  :Cool: 

4. save&stable = server  :Very Happy: 

----------

## artbody

Das "IMMER DER WURM DRIN THEMA" wäre die lustigere Überschrift gewesen

```
/usr/sbin/python-updater

/usr/sbin/python-updater: line 23: cut: command not found

 * Starting Python Updater from 2.5 to  :

 * Searching for packages with files in /usr/lib/python2.5 /usr/lib32/python2.5 /usr/lib64/python2.5 ..

 * Adding to list: =app-office/planner-0.14.2

 * Adding to list: =sys-libs/libcap-1.10-r11

 * Adding to list: =sys-libs/libieee1284-0.2.11

 * Adding to list: =sys-libs/cracklib-2.8.12

 * Adding to list: =net-print/foomatic-gui-0.7.5

 * Adding to list: =dev-java/java-config-2.1.3

 * Adding to list: =dev-java/antlr-2.7.7

 * Adding to list: =dev-java/java-config-1.3.7

 * Adding to list: =media-libs/lcms-1.17

 * Adding to list: =media-libs/pdflib-7.0.2

 * Adding to list: =dev-python/pygtksourceview-2.0.0-r1

 * Adding to list: =dev-python/numpy-1.0.4-r1

 * Adding to list: =dev-python/gnome-python-2.20.1

 * Adding to list: =dev-python/pyopengl-2.0.1.09-r1

 * Adding to list: =dev-python/gnome-python-desktop-2.20.0

 * Adding to list: =dev-python/pycrypto-2.0.1-r5

 * Adding to list: =dev-python/pyxdg-0.15

 * Adding to list: =dev-python/python-fchksum-1.7.1

 * Adding to list: =dev-python/gnome-python-extras-2.19.1-r1

 * Adding to list: =dev-python/pycairo-1.4.12

 * Adding to list: =dev-python/python-ldap-2.3.1

 * Adding to list: =dev-python/pygobject-2.14.1

 * Adding to list: =dev-python/pyorbit-2.14.3

 * Adding to list: =dev-python/setuptools-0.6_rc7-r1

 * Adding to list: =dev-python/ipy-0.55

 * Adding to list: =dev-python/numeric-24.2-r6

 * Adding to list: =dev-python/pygtk-2.12.1

 * Adding to list: =dev-python/pyrex-0.9.6.4

 * Adding to list: =dev-python/dbus-python-0.82.4

 * Adding to list: =dev-python/pygtkglext-1.1.0

 * Adding to list: =dev-python/pyxml-0.8.4-r1

 * Adding to list: =dev-util/subversion-1.4.4-r4

 * Adding to list: =dev-util/scons-0.97

 * Adding to list: =x11-misc/alacarte-0.11.3-r1

 * Adding to list: =gnome-base/gnome-menus-2.20.3

 * Adding to list: =gnome-base/gnome-applets-2.20.1

 * Adding to list: =sys-apps/file-4.23

 * Adding to list: =app-admin/sabayon-2.20.1

 * Adding to list: =app-admin/pessulus-2.16.3

 * Adding to list: =app-admin/webapp-config-1.50.16-r2

 * Adding to list: =app-admin/gamin-0.1.9

 * Adding to list (manually): =x11-libs/vte-0.16.12

 * Adding to list: =gnome-extra/deskbar-applet-2.20.3

 * Adding to list: =gnome-extra/gnome-games-2.20.3

 * Adding to list: =dev-libs/libxml2-2.6.30-r1

 * Adding to list: =dev-libs/libxslt-1.1.22

 * Adding to list: =net-mail/getmail-4.7.7

 * Adding to list: =net-mail/fetchmail-6.3.8-r1

These are the packages that would be merged, in order:

Calculating dependencies |

!!! All ebuilds that could satisfy "=dev-util/subversion-1.4.4-r4" have been masked.

!!! One of the following masked packages is required to complete your request:

- dev-util/subversion-1.4.4-r4 (masked by: EAPI , CHOST: )

The current version of portage supports EAPI '1'. You must upgrade to a

newer version of portage before EAPI masked packages can be installed.

For more information, see MASKED PACKAGES section in the emerge man page or 

refer to the Gentoo Handbook.

```

----------

## franzf

Klappt es mit python-updater -i (--ignore-versions)?  Damit umgehst du das Problem dass portage nenau die Version nimmt welche gerade installiert ist (ja, ist das selbe wie revdep-rebuild -X, nur für Python  :Wink: ).

----------

## Finswimmer

 *artbody wrote:*   

> Das "IMMER DER WURM DRIN THEMA" wäre die lustigere Überschrift gewesen
> 
> ```
> /usr/sbin/python-updater
> 
> ...

 

Wird das hier etwa ein Thread, wo jeder sein Problem unter dem Deckmantel einer Verschwörung posten will?

Dein Problem hat nichts mit der Diskussion um die Sicherheit in OpenSource Projekten zu tun.

 *Quote:*   

> /usr/sbin/python-updater: line 23: cut: command not found

 

Scheint dein Problem (zum Teil) zu sein, aber dafür hast du doch den anderen Thread mit den coreutils.

Tobi

----------

