mikrocontroller.net

Forum: PC Hard- und Software Fehlermeldung unter Kubuntu nicht verstanden


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: R. F. (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Installieren eines Paketes erhalte ich folgenden Text:
------------------------------------------------------------
 sudo add-apt-repository -y ppa:bladerf/bladerf
OK:1 http://ppa.launchpad.net/bladerf/bladerf/ubuntu cosmic InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu cosmic InRelease
OK:3 http://security.ubuntu.com/ubuntu cosmic-security InRelease
Ign:4 http://ppa.launchpad.net/gqrx/gqrx-sdr/ubuntu cosmic InRelease
OK:5 http://de.archive.ubuntu.com/ubuntu cosmic-updates InRelease
OK:6 http://de.archive.ubuntu.com/ubuntu cosmic-backports InRelease
OK:7 http://ppa.launchpad.net/myriadrf/drivers/ubuntu cosmic InRelease
Ign:8 http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu cosmic InRelease
Fehl:9 http://ppa.launchpad.net/gqrx/gqrx-sdr/ubuntu cosmic Release
  404  Not Found [IP: 91.189.95.83 80]
Fehl:10 http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu cosmic Release
  404  Not Found [IP: 91.189.95.83 80]
Paketlisten werden gelesen... Fertig
E: Das Depot »http://ppa.launchpad.net/gqrx/gqrx-sdr/ubuntu cosmic 
Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere 
Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren 
Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
E: Das Depot »http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu cosmic 
Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere 
Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
-------------------------------------------------

Ich würde gerne wissen, was das bedeutet und was ich tun muss, um dieses 
Problem zu beheben.

Freundlichen Gruss

Robert

Autor: Nano (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Ich finde es recht mutig, dass du dich bei privaten Repos bedienst und 
gar keine Angst hast, dass man dir Schadcode unterschiebt. Aber 
vielleicht war dir diese Gefahr gar nicht bewusst.

Mein Tipp:
Bleib bei Kutuntu wie es vom Hersteller kommt und installiere dir den 
Rest aus dem Quellcode den du dir aus sicheren Quellen besorgst.

Noch besser wäre es aber gleich auf Debian zu wechseln.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Ich finde es recht mutig, dass du dich bei privaten Repos bedienst und
> gar keine Angst hast, dass man dir Schadcode unterschiebt. Aber
> vielleicht war dir diese Gefahr gar nicht bewusst.

Das, hier noch in lang. ;)
https://wiki.ubuntuusers.de/Paketquellen/

Autor: R. F. (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich wollte ich nur gqrx-sdr installieren. Mehr nicht.

Ich habe nicht gewusst, dass das Arbeiten mit diesem Programm gefährlich 
ist.

Wie installiere ich das ohne Gefährdung meines Systems?

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Während ich ebenfalls von Fremdquellen abraten würde, würde ich erstmal 
darauf hinweisen, wo das Problem liegt.

Offenbar bietet das Repo keine Packete für ubuntu cosmic. Das am 
nächsten liegende scheint ubuntu xenial zu sein, aber das Risiko dass es 
bei unterschiedlichen codenames/releasen zu Problemen kommt ist stark 
erhöht. Wenn du bei einem der Links mit den 404 meldungen draufklickst 
und nach dist/ gehst, siehst du für welche das Repo Packete bietet:
http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu/dists/

Wozu willst du die fremden quellen eigentlich überhaupt, gqrx-sdr und 
gnuradio gibts auch in den offiziellen repos sogar bei deinem momentanen 
ubuntu release/codename, einfach "apt-get update && apt-get install 
gqrx-sdr" btw. "apt-get install gnuradio": 
https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=gqrx-sdr
https://packages.ubuntu.com/search?suite=all&section=all&arch=any&keywords=gnuradio&searchon=names

Autor: R. F. (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe ich gerade gemacht, mit folgendem Ergebnis:
--------------------------------------
rfr@rfr-Mainframe:~$ sudo apt-get update
OK:1 http://security.ubuntu.com/ubuntu cosmic-security InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu cosmic InRelease
OK:3 http://ppa.launchpad.net/bladerf/bladerf/ubuntu cosmic InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu cosmic-updates InRelease
Ign:5 http://ppa.launchpad.net/gqrx/gqrx-sdr/ubuntu cosmic InRelease
OK:6 http://de.archive.ubuntu.com/ubuntu cosmic-backports InRelease
OK:7 http://ppa.launchpad.net/myriadrf/drivers/ubuntu cosmic InRelease
Ign:8 http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu cosmic InRelease
Fehl:9 http://ppa.launchpad.net/gqrx/gqrx-sdr/ubuntu cosmic Release
  404  Not Found [IP: 91.189.95.83 80]
Fehl:10 http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu cosmic Release
  404  Not Found [IP: 91.189.95.83 80]
Paketlisten werden gelesen... Fertig
E: Das Depot »http://ppa.launchpad.net/gqrx/gqrx-sdr/ubuntu cosmic 
Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere 
Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren 
Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).
E: Das Depot »http://ppa.launchpad.net/myriadrf/gnuradio/ubuntu cosmic 
Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere 
Art durchgeführt werden, daher ist es standardmäßig deaktiviert.

Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst die problematischen PPAs, die du hinzugefügt hast, vorher noch 
deaktivieren oder entfernen: 
https://askubuntu.com/questions/143203/how-to-disable-a-particular-ppa#143206

Autor: Petty 12 (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Und so eine gequirlte Scheiße ergibt irgendwann mal ein funktionierendes 
System auf das man sich auch verlassen kann?
Man bin ich froh das ich mir so was nicht antue. Es lebe Windows, 78,9 
Prozent der PC Benutzer können sich nicht irren.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Petty 12 schrieb:
> Man bin ich froh das ich mir so was nicht antue. Es lebe Windows, 78,9
> Prozent der PC Benutzer können sich nicht irren.

Wer nicht selbständig Denkt, kann sich auch nicht irren!
(Geschrieben von einem stinkfaulen Windos User. Stink-Faul nicht 
Denk-Faul:)

Autor: Jack V. (jackv)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Und so eine gequirlte Scheiße ergibt irgendwann mal ein funktionierendes System
> auf das man sich auch verlassen kann?

Nein, für Systeme, auf die man sich verlassen kann, nimmt man andere 
Distributionen.


[scnr]

: Bearbeitet durch User
Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Ich finde es recht mutig, dass du dich bei privaten Repos bedienst und
> gar keine Angst hast, dass man dir Schadcode unterschiebt. Aber
> vielleicht war dir diese Gefahr gar nicht bewusst.
>
> Mein Tipp:
> Bleib bei Kutuntu wie es vom Hersteller kommt und installiere dir den
> Rest aus dem Quellcode den du dir aus sicheren Quellen besorgst.
>
> Noch besser wäre es aber gleich auf Debian zu wechseln.

Die Quellen sind schon ok wen auch alt glaube 16.04 war die letzte 
unterstützte Version, grundsätzlich hast aber recht was dem TO einfach 
fehlt sind die Keys und einige Paket quellen sind nicht verfügbar.

Der TO kann es aber knicken auf Cosmic irgend was mit SDR zu versuchen, 
das liegt dadran das das System bestimmte Libs in ner eigenen Version 
benutzt und das mit dem ganzen SDR Gedöns nicht zusammen funktioniert 
nicht mal das was xyz-Ubuntu bereitstellt läuft damit.

Selbst Compilieren soll laufen ist aber sehr aufwendig weil man ne ganze 
menge noch anpassen muss ich hatte es mal versucht ging aber hinterher 
auch nicht wirklich brauchbar.

: Bearbeitet durch User
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Petty 12 schrieb:
> Und so eine gequirlte Scheiße ergibt irgendwann mal ein funktionierendes
> System auf das man sich auch verlassen kann?
> Man bin ich froh das ich mir so was nicht antue. Es lebe Windows, 78,9
> Prozent der PC Benutzer können sich nicht irren.

Wenn du dir bei Windows den aktuellen Firefox anstatt von mozilla.org 
von irgendeiner dubiosen Dropbox Box holst und installierst, dann musst 
du dich auch nicht wundern, wenn du dir die Möglichkeit von Schadcode 
auf System holst.
Mit Linux vs. Windows hat das also gar nichts zu tun, eher mit Nutzern 
die blind irgendwelchen Quellen vertrauen.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
K. J. schrieb:
> Die Quellen sind schon ok

Sagt wer?
Keiner überprüft die Binaries von PPA Quellen.
Man könnte problemlos den Originalquellcode modifizieren, dann eine 
Schadroutine einbauen und als PPA dort uploaden und dann einfach nur 
warten bis jemand kommt und sich diese modifizierten Pakete installiert.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> K. J. schrieb:
>> Die Quellen sind schon ok
>
> Sagt wer?
> Keiner überprüft die Binaries von PPA Quellen.
> Man könnte problemlos den Originalquellcode modifizieren, dann eine
> Schadroutine einbauen und als PPA dort uploaden und dann einfach nur
> warten bis jemand kommt und sich diese modifizierten Pakete installiert.

Jup stimmt aber dann dürftest du nix mehr installieren ich bezweifle das 
du dir jeden Quellcode durchlist grade von grösseren Projekten wo jeder 
was rein Commiten kann und dann die ganzen Regelmäßig gehackten oder auf 
andere Art manipulierten GIT ACCs...

p.s der Quellcode liegt dem PPA ja bei lesen tut es aber eh so gut wie 
niemand.

Autor: test (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Petty 12 schrieb:
> Und so eine gequirlte Scheiße ergibt irgendwann mal ein funktionierendes
> System auf das man sich auch verlassen kann?
> Man bin ich froh das ich mir so was nicht antue. Es lebe Windows, 78,9
> Prozent der PC Benutzer können sich nicht irren.

Unter Windows hast du das selbe Problem wenn du einfach wild jede 
Software installierst die dir irgendwo im Web unterkommt.


Jedes System wo man Adminrechte hat kann man kaputt machen.


Wer sich nicht zutraut das zu handeln kann sich nen iPhone kaufen. Dort 
bekommt man keine Adminrechte und kann nix Distributionsfremdes 
installieren.

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
K. J. schrieb:
> Selbst Compilieren soll laufen ist aber sehr aufwendig weil man ne ganze
> menge noch anpassen muss ich hatte es mal versucht ging aber hinterher
> auch nicht wirklich brauchbar.

Habs letztens unter arch selbst kompiliert. Da mußte man eigentlich nix 
anpassen, sondern nur alle benötigten Libs vorher installieren.
Genauso wie bei sdrangle.
Das Schema ist doch fast immer das gleiche:
- git clone https://blahblahblah (oder wget xyz.tar.gz und tar -xzvf 
xyz.tag.gz)
- mkdir build
- cd build
- configure ../
- make
- sudo make install

Wenn die passenden Build-Tools (gcc, autoconf, make, etc.pp.) 
installiert sind, sollte das unabhängig von der Distribution 
funktionieren.

Autor: DPA (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
K. J. schrieb:
> Jup stimmt aber dann dürftest du nix mehr installieren ich bezweifle das
> du dir jeden Quellcode durchlist grade von grösseren Projekten wo jeder
> was rein Commiten kann und dann die ganzen Regelmäßig gehackten oder auf
> andere Art manipulierten GIT ACCs...

Bei git projekten können nur die maintainer in deren Projekten 
committen. Änderungen von anderen müssen diese vorschlagen, das schaut 
sich dann ein maintainer an, bei grösseren projekten braucht es sogar 
mehrere, bevor das dann gemerged wird.

Falls ein git repo gehackt wird, fällt das in der regel schnell auf:
 * Ändert sich die git historie, schlägt der nächste push/pull fehl. 
Dann force pushen die maintainer ihre lokale kopie wieder, nachdem 
herausgefunden wurde wie der Angreifer rein kahm.
 * Bei zusäzlichen commits ist die chance auch sehr hoch, das jemandem 
auffällt, dass ein Commit micht von ihnen ist. Im besten fall bekommt 
sogar einer einen merge konflikt.

Bei debian packeten gibt es ausserdem den reproducible builds effort. Es 
geht darum, dass wenn jemand anderes das gleiche source packet buildet, 
die binaries übereinstimmen. Ist leider aber noch weniger weit, als es 
sein sollte: https://wiki.debian.org/ReproducibleBuilds

Autor: R. F. (rfr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht jetzt.
Vielen Dank allen.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
K. J. schrieb:
> Nano schrieb:
>> K. J. schrieb:
>>> Die Quellen sind schon ok
>>
>> Sagt wer?
>> Keiner überprüft die Binaries von PPA Quellen.
>> Man könnte problemlos den Originalquellcode modifizieren, dann eine
>> Schadroutine einbauen und als PPA dort uploaden und dann einfach nur
>> warten bis jemand kommt und sich diese modifizierten Pakete installiert.
>
> Jup stimmt aber dann dürftest du nix mehr installieren ich bezweifle das
> du dir jeden Quellcode durchlist grade von grösseren Projekten wo jeder
> was rein Commiten kann und dann die ganzen Regelmäßig gehackten oder auf
> andere Art manipulierten GIT ACCs...

Zwischen PPAs und den GIT Repos der Entwickler oder den 
Quellcodedatenbanken der Distributionen gibt es aber schon noch einen 
Unterschied.

Der Entwickler hat eine Reputation zu verlieren und wenn er Schadcode in 
das GIT Repo einbaut, wäre das nachträglich recht einfach nachweisbar.
Zumal die ein oder anderen Leute sich den Quellcode ansehen könnten und 
manche Projekte auch von mehreren Entwickelt werden, bei letzterem ist 
es also noch schwerer, da Schadcode einzubauen.
Auf jeden Fall wird man sich den Quellcode ganz genau ansehen, wenn 
Probleme mit dieser Software bekannt werden sollten und dann ist der Ruf 
des Entwicklers dahin.

Eine Distribution hat ebenfalls eine Reputation zu verlieren und der 
Quellcode, der von Upstream kommt, kommt bspw. im Fall von Debian nur 
als kurzen Diff in deren Quellcodedatenbank.
Dadurch können Änderungen leicht nachvollzogen werden und da es einen 
Maintainer gibt, der ebenfalls seinen Ruf wahren will, wird der sich den 
Code auch ansehen und nicht alles durchwinken, was kommt.
Und bei größeren Projekten wird er auch nicht alleine sein, manche 
gucken sich den Quellcode an um etwas zu lernen und die können Schadcode 
dann auch finden.
Am Ende, wenn das alles in die Distrieigenen Repos gekommen ist, wird 
dann aus diesem Code ein Binary und dann ein Paket erstellt.
Im Falle von Debian gibt es das reproducible  Build Projekt, womit 
Binaries in Pakete, die nicht mit ebenso aus dem gleichen Quellcode 
compilierten Paketen, übereinstimmen, auffallen würden.
Siehe:
https://tests.reproducible-builds.org/debian/buster/index_suite_amd64_stats.html

In beiden Fällen, sowohl bei den Upstream Entwicklern als auch bei den 
Distributionen ist es also schwer, da Schadcode einzubauen, bei beiden 
dürften mehrere Leute hinsehen und beide haben einen Ruf zu verlieren.
Aus dem Grund ist es recht unwahrscheinlich, dass man da Pakete mit 
enthaltenen Schadroutinen bekommt.

> p.s der Quellcode liegt dem PPA ja bei lesen tut es aber eh so gut wie
> niemand.

Ja, das ist schon richtig, aber das Problem fängt schon bei der Art und 
Weise an, wie da so ein Stück Quellcode eingepflegt werden kann.
Wenn's blöd läuft, ist das bei jeder Versionsänderung ein großer Haufen 
Quellcode und keine einzelnen Diffs, die man nach und nach gut und 
leicht nachvollziehen könnte.
Und es wird wahrscheinlich niemand hinsehen, einen Diff zum Originalcode 
gibt es auch nicht und reproducible Builds ohnehin nicht.
Vor allem ist es das Repo eines einzelnen, der kann praktisch machen was 
er will, kaum einer sieht hin und der Account kann ein beliebiges 
Pseudonym sein.
Wollte jemand Schadcode über PPAs einbauen, dann nimmt er ein Pseudonym 
und wenn er auffliegt, nimmt er ein neues und eine andere Software.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.