ssh (dropbear) Version (2014.66-r0) & CVE-2017-9078

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • ssh (dropbear) Version (2014.66-r0) & CVE-2017-9078

      Hi folks,

      wie sieht es mit Aktualisierungen bei VU/VTI aus. Wenn ich das richtig sehe, sollte man die installierte dropbear (ssh) wegen cvedetails.com/cve/CVE-2017-9078/ nicht im INet nutzen...

      Diese Softwarekomponenten könnte man doch an VU vorbei aktualisieren (wenn VU es nicht macht). Wie stellt sich VTI da auf?

      (und bitte keine Kommentare zu ssh-ports nicht ins Internet hängen. Das ist ein Linux-Rechner und auch ein Receiver :happy3: )

      LG

      lopiuh
    • Hätte ich fertig übersetzt in der Version 2019.78 bei mir seit einiger Zeit am laufen, die ARM-Version kann ich als IPK-Datei zur Verfügung stellen. Für Mips hab ich nix.
      Diskutiere nie mit einem Idioten. Er zieht dich auf sein Niveau runter und schlägt dich mit seiner Erfahrung.
    • Hey rdamas,

      vielen Dank für Dein Angebot. Ich nutze die Chance mal crosscompiling zu üben. rsync läuft schon.

      Gibts für VTI eine Motivation zumindest die bekannten sicherheitskritischen Pakete nicht upzudaten? und wtf macht VU bei diesem Thema?

      Gruß

      lopiuh
    • @rdamas: Ich bekomme beim Installieren "Deiner" Pakete GCC-9.2.0 für Boxen mit ARM-Prozessor (*4k) fehlende Abhängigkeiten: (bin auf dem Herstellerimage)


      * satisfy_dependencies_for: Cannot satisfy the following dependencies for git:
      * libc6-ldconfig *

      * satisfy_dependencies_for: Cannot satisfy the following dependencies for gcc:
      * libc6-ldconfig * libc6-thread-db * libcidn1 * libc6-extra-nss *

      * satisfy_dependencies_for: Cannot satisfy the following dependencies for libc6-dev:
      * libc6-thread-db * libcidn1 * libc6-extra-nss *


      Hast Du da ein Tipp für mich?

      Beim Cross compilieren von dropbear unter x86/Debian für host=arm-linux-gnueabi erhalte ich zwar arm-binaries, beim Ausführen (+x ist gesetzt) auf der Box aber leider "-sh: ./dropbear: No such file or directory" (rsync hatte hingegen funktioniert und ist ausführbar). Weißt Du woran das liegen könnte?


      Gruß lopiuh

      sorry, sehe gerade, dass die fehlenden Pakete im vti repository vorhanden sind, ...
    • lopiuh schrieb:

      Wie stellt sich VTI da auf?

      Die VTi Feeds sind randvoll mit gnadenlos veralteten Paketen. Von systemkritischen Updates ist leider seit Jahren überhaupt nichts zu sehen. Stattdessen wird bei TVi auf neuste Plugins und "Featureitis" gesetzt.
      Hinzu kommt: der ganze Enigma2-Kram basiert auf python2.7; diese Version ist seit Anfang diesen Jahres EOL(!).
      Mich würde in dem Zusammenhang mal eine Roadmap von VTi interessieren: Wie lange soll das denn auf dem alten Schrott weiter laufen?

      Unter dem Strich kann ich nur einen Aufruf starten: Leute, lasst uns als Community aktiv werden! Einfach ein eigenen Feed betreiben und damit unabhängig von den seltsamen und teilweise gefährlichen Zuständen etwas entgegensetzten. Wir reden hier immerhin von 4-6 Jahre alten Software-Paketen, die in allen CVS-Datenbaken mitunter mit Höchstpunktzahl aufgeführt sind.

      Weil die VTi-Feeds so furchtbar veraltet sind, betreibe ich seit Jahren für *mich alleine* genau das: mein eigenes, kleines (MIPSel)-Repository (aka feed): github.com/cfdisk/vti-banana-mipsel
      Paketierung und Pflege ist allerdings Arbeits- und Zeitintensiv. Ich würde mich daher sehr freuen, wenn wir zusammen als Community auf solch einem Weg einen Ausweg erarbeiten könnten.

      @VTi-Team: nichts für ungut. Es ist aber in dem Bereich absolut unterirdisch, was ihr da abliefert. Bitte seht das als konstruktive Kritik.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Banana Joe ()

    • @banana Joe: Du sprichst mir aus der Seele. Aus diesem Grund wollte ich eigentlich OpenATV/OpenPLI nehmen, aber dieses f*ck proprietäre, fast channel change will ich zumindest eine Zeit mal ausprobieren, nachdem ich diesem "Feature" seit Wegfall von a-n-a-l-o-g-SAT hinterhertrauere. Ich bin "eigentlich" FOSS Fanatiker und sollte den proprietärem Kram von VU gar nicht einsetzen. Das, was Du ansprichst, hat die github.com/oe-alliance doch eigentlich schon umgesetzt, oder?

      LG

      lopiuh
    • Ich bin da überhaupt nicht mehr auf dem Stand, was diese ganzen Open-Images angeht. Ich vermute aber stark, das es ganz furchtbar schief gehen wird, wenn man sich einfach an einem der Open-Image-Feeds bedient.Aber falls du irgendwelche Feed-URLs kennst, dann gerne her damit. Bin da bisher nicht fündig geworden, würde aber gerne mal reinschauen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NaseDC () aus folgendem Grund: Direktzitat entfernt

    • Hi,

      ne ich meinte nicht, deren repositories/feeds im vti zu verwenden, sondern direkt die "distro", da diese (so zumindest mein Eindruck) die Kriterien "Pakete sind aktuell" und "Quellen/Buildumgebung veröffentlicht" erfüllen.

      SSH ist in V.8.0p1-r0 / 7.9p1+git-r0 / 7.4p1-r0.1
      gstreamer ist in V. 1.17.0.1+git18671+e17bde5-r0 / ? / 1.14.4+git18169+3c586de-r0.1

      (openatv-6.4 / 6.3 / openpli-7.2) vorhanden.

      fehlt (mir) halt fast channel change. Ich habe mir jetzt dank dem GCC von rdamas ein paar Pakete aus den nativen Quellen auf der Box übersetzt, da ich keine Buildumgebung für VTI finde und das mit dem crosscompilieren nicht hinbekommen habe.

      Gibt es für VTI eine Buildumgebung und wenn nicht, why?

      Gruß

      lopiuh

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von NaseDC () aus folgendem Grund: Könnt ihr mal diese unnützen Direktzitate unterlassen!