1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Softwareentwicklung:…

Ein generelles Vertrauensproblem

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. Ein generelles Vertrauensproblem

    Autor: JouMxyzptlk 27.04.19 - 12:26

    Docker Hub, Github, Updatemechanismen einiger Linux Distributionen...
    Alle Programme welche bei der Installation darauf angewiesen sind dass eine Onlineverbindung die aktiven Komponenten holt sind anfällig.
    Firefox, Google Chrome, SVP-Projekt und und und. Bei Firefox und SVP gibt es komplette offline Installer, aber für viel zu viele nicht mehr. Und dann noch Krebsgeschwüre wie "Chip-Installer"...

    In Scheißtrend den ich seit vielen Jahren nicht ausstehen kann und sich immer verschlimmert. Klar, ich kenne die Argumente mit "ist doch alles signiert" und so - und prompt kommt so eine Newsmeldung welche das Signieren aushebelt und mich nicht mal überrascht.

    Ultra HD ist LOW RES! 8K bis 16K sind mein Metier.

  2. Re: Ein generelles Vertrauensproblem

    Autor: Tpircs Avaj 27.04.19 - 12:52

    JouMxyzptlk schrieb:
    --------------------------------------------------------------------------------
    > Firefox, Google Chrome, SVP-Projekt und und und. Bei Firefox und SVP gibt
    > es komplette offline Installer, aber für viel zu viele nicht mehr.

    Und den Offline-Installer hast du natürlich ... mit der Post auf Papier bekommen und eingescannt. Oder was?

    Alles klar.

  3. [gelöscht]

    Autor: [gelöscht] 27.04.19 - 13:09

    [gelöscht]



    2 mal bearbeitet, zuletzt am 27.04.19 13:11 durch burzum.

  4. Re: Ein generelles Vertrauensproblem

    Autor: JouMxyzptlk 27.04.19 - 14:11

    Tpircs Avaj schrieb:
    --------------------------------------------------------------------------------
    > JouMxyzptlk schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Firefox, Google Chrome, SVP-Projekt und und und. Bei Firefox und SVP
    > gibt
    > > es komplette offline Installer, aber für viel zu viele nicht mehr.
    >
    > Und den Offline-Installer hast du natürlich ... mit der Post auf Papier
    > bekommen und eingescannt. Oder was?

    Der Offline Installer kann genauso infiziert sein, aber es ist nur eine mögliche Quelle der Infektion, und nicht mehrere, teilweise hunderte, Quellen. CRC und SHA lassen sich leicht prüfen, 7-zip bringt da eine ganz bequemes Kontextmenü mit.
    Den Offline Installer kann ich auch ein paar Tage liegen lassen und dann nachprüfen was Virustotal dazu sagt.
    Beim Offline Installer kann ich mich absichtlich für eine ältere Version entscheiden weil die neuere Version mehr Bugs als Features hat.
    Und so weiter und so weiter blah blah. Denk das ganze mal durch. Wenn du weiterhin stur bleiben willst dass es identisch schlecht ist kann man dir nicht helfen.

  5. Re: Ein generelles Vertrauensproblem

    Autor: Mangnoppa 27.04.19 - 14:22

    burzum schrieb:
    --------------------------------------------------------------------------------
    > Das Problem sehe ich vor allem bei allem was tausende Dependencies hat,
    > also primär Softwareentwicklung und Linux.
    >
    > Habe ich EINE Binary die signiert ist, kann ich das relativ easy
    > nachvollziehen und auch woher sie kommt. Installiere ich irgendwas via yarn
    > für Node oder mein JS Projekt, dann zieht mir das Ding gefühlte 10.000
    > Dependencies aus 1000 Quellen. Es ist schlicht nicht mehr effektiv prüfbar
    > woher all der Shit kommt.
    >
    > Bei Linux das gleiche in Grün: Tausende Abhängigkeiten und es wird noch
    > verschärft dadurch, das jede verdammte Distri das Rad neu erfindet und ihre
    > eigenen Päckchen packt. Besonders geil wird es wenn ich Packete aus
    > Drittrepos ziehen MUSS weil die aktuelle Version nicht im Repo der Distri
    > ist. Ergo MUSS ich Fremquellen einfügen. Am Ende zieht er dann wieder
    > gefühlte 1000 Packages aus 100 Quellen. Wie will ich die alle sinnvoll und
    > zeitnah prüfen?
    >
    > Die ganzen Libs usw sind ja alle schön und Bequem aber wir haben uns dafür
    > entschieden lieber mal ein Rädchen selbst neu zu erfinden als bei nur
    > 10-100 Zeilen auf irgendeine Lib zu setzen. Gerade bei JS gibt es so
    > manches Package wo die Metadaten drumherum größer sind als die paar Zeilen
    > Code. So haben wir die Kontrolle über den Code und er liegt in unserem Repo
    > in unserem VPN. Persönlich sehe ich inzwischen auch die Zukunft inzwischen
    > in (Web) Anwendungen ohne Framework (auf Serverseite) drunter. Wir sind weg
    > von Frameworks hin zu einer Hand voll Libs und CQRS anstatt MVC
    > (Frameworks).

    Wenn du die neuste Version einer Software benötigst und deshalb ein Fremdrepo eintragen musst, behaupte ich, verwendest du die falsche Distribution. Ich verstehe aber was du meinst und stimme dem auch teilweise zu. Trotzdem solltest du dann vielleicht deine distro wechseln.

  6. Re: Ein generelles Vertrauensproblem

    Autor: Hawk321 27.04.19 - 16:40

    burzum schrieb:
    --------------------------------------------------------------------------------
    > Das Problem sehe ich vor allem bei allem was tausende Dependencies hat,
    > also primär Softwareentwicklung und Linux.
    >

    > Bei Linux das gleiche in Grün: Tausende Abhängigkeiten und es wird noch
    > verschärft dadurch, das jede verdammte Distri das Rad neu erfindet und ihre
    > eigenen Päckchen packt. Besonders geil wird es wenn ich Packete aus
    > Drittrepos ziehen MUSS weil die aktuelle Version nicht im Repo der Distri
    > ist. Ergo MUSS ich Fremquellen einfügen. Am Ende zieht er dann wieder
    > gefühlte 1000 Packages aus 100 Quellen. Wie will ich die alle sinnvoll und
    > zeitnah prüfen?

    Bei seriösen Linux Distros ist das kein Problem und teils so extrem peinlich geprüft das es schon weh tut (RedHat !), andere Repos die von seriösen Quellen kommen sind auch kein Problem --> NGINX, CEPH ...

    Gerade bei Linux gibt es genug Mechanismen um Pakete zu prüfen und zu checken was gerade und warum geändert wird/wurde.
    Nur wie so oft, man muss sich mit der Materie auseinander setzen, was nun mal dauert.

    Hat man allerdings den Dreh raus, ist man bei Linux am besten aufgehoben. Soo viele Distros gibt es nicht für den Server Bereich, das meint man nur.

    Die Diskussion hatte ich bereits mit X Azubis und Praktikanten, erst als ich das alles mal intensive erklärt hab und die Leute selbst ausprobieren durften, viel auch der Groschen.

  7. Re: Ein generelles Vertrauensproblem

    Autor: tomatentee 27.04.19 - 21:11

    Ob jetzt du die 1000 Dependencies reinlutscht oder Dir dein Vendor ein fat binary mit allen Abhängigkeiten reinkompilliert rüber schmeißt macht wenig Unterschied. Der Anbieter kann das ja auch nicht alles scannen.

    Im Gegenteil: Wenn es in einer der Abhängigkeiten ein Problem hat bist du auf den Anbieter angewiesen, verwaltest du selbst, kannst du selbst updaten.

    Daneben gibt es einen wichtigen Unterschied zwischen den Linux-Paketen und NPM&Co: Bei den Paketen guckt zumindest der Maintainer der Distri nochmal drüber und nicht jeder Honk kann einfach irgendwas pushen. Sowas wie der Event-Stream fuckup wäre da vorher aufgefallen.

  8. Re: Ein generelles Vertrauensproblem

    Autor: Tuxgamer12 28.04.19 - 09:20

    JouMxyzptlk schrieb:
    --------------------------------------------------------------------------------
    > Docker Hub, Github, Updatemechanismen einiger Linux Distributionen...
    > Alle Programme welche bei der Installation darauf angewiesen sind dass eine
    > Onlineverbindung die aktiven Komponenten holt sind anfällig.

    Github ist offensichtlich kein "Programm", das du installierst. Sondern eine Hostingplattform für Open Source Softwareentwicklung mit git. Wenn eines der dort entwicklenten Projekte der Meinung ist einen Onlineinstaller zu basteln, ist das wohl kaum Problem von Github. Im Gegenteil: Aus der Definition von "Open Source" folgt, dass du zumindestens die Sourcen sogar offline herunterladen können musst (und diese eben auch offline installieren/kompilieren kannst). Und um ehrlich zu sein: Ich habe auf Github schon deutlich mehr Binaries zum Download gesehen als Online installer (nämlich ziemlich genau null).

    Docker Hub ist genauso kein "Programm", das du installierst, sondern ebenfalls eine Hostingplattform. Eben für Container. Wohlgemerkt: Container, die in den wenigsten Fällen eine Onlineverbindung brauchen um Componenten nachzuladen oder einfach schlecht geschrieben sind ;). Also Container (genauer gesagt Layer), die du dir (in beliebiger Version) herunterlädst und dann machen kannst, was auch immer du willst (offline!). Der einzige Unterschied zu deiner ".exe" ist jediglich, dass der Download üblicherweise nicht über Webbrowser, sondern über Software "docker" erfolgt. Muss aber nicht sein - Download klappt auch über kleines Script.

    Zuletzt kannst du dir üblicherweise in jeder Linux Distribution die Pakete zur Offline-Installation lokal herunterladen (üblicherweise .deb oder .rpm). Was glaubst du, was tools wie apt, yum oder zypper machen? "Offline-Installationsdaten" in temporäres Verzeichniss herunterladen und anschließend installieren. Ein Flag gesetzt und schon werden die "Offline-Installationsdaten" nur heruntergeladen. Es spricht auch nichts dagegen, wenn du dir die .debs / .rpms manuell vom Spiegelserver zusammensuchst und installierst? Und damit die Vorteile hast, die auch immer du bei diesem "Offline-Installations"-Vorgehen siehst?

    => Irgendwie haut so keines deiner Beispiele wirklich hin.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Senior Cloud Engineer (m/w/d)
    unimed Abrechnungsservice für Kliniken und Chefärzte GmbH, Wadern (Home-Office möglich)
  2. Head (m/w/d) Software Development - Stellvertretender Gesamtentwicklungsleiter
    über eTec Consult GmbH, Großraum Nürnberg
  3. Datenkoordinator*in (m/w/d)
    Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  4. IT-Servicetechniker (m/w/d) - Bank Technologie
    GRG Deutschland GmbH, Hamburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€
  2. (u. a. Ryzen 5 5600X 358,03€)


Haben wir etwas übersehen?

E-Mail an news@golem.de