Ankündigung

Einklappen
Keine Ankündigung bisher.

Fragen zu Composer

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Fragen zu Composer

    Als PHP-Entwickler und Eigenbrödler, habe ich bisher auf NPM, NodeJS oder Composer verzichtet. Es gibt einige sehr gute Gründe, warum. Nun bin ich deshalb schon einige Male an meine Grenzen gekommen, weil manche Scripts gar nicht mehr ohne sowas laufen. Aktuell ist es das CMS Drupal, in das ich mich einarbeiten möchte, weil es sein kann, dass ich zukünftig damit arbeite. Noch ist keine endgültige Entscheidung gefallen, aber vorher habe ich ein paar Fragen dazu, die mir die hiesige Community hoffentlich beantworten kann.

    Geht von einem Linux-System aus. Ich möchte es nicht global nutzen, sondern vorerst nur für eine einzige Webseite.

    Meine Fragen:

    1. Wie sicher ist die Verwendung von Composer?
    2. Hat schon jemand negative Erfahrungen damit gemacht?
    3. Welche Bedenken habt ihr?

    THXIA

  • #2
    Composer ist einfach nur ein Package Manager. Der ist so sicher oder unsicher wie die Packages, die du damit lädst. Also von daher macht es keinen wirklichen Unterschied, ob du Software-Pakete mit Composer oder rmanuell über eine Webseite runter lädst.

    Das ist ungefähr vergleichbar mit apt auf Linux. Man kann Software per Hand installieren, oder man verwendet einen Package Manager dafür. Geht beides, nur mit Package Manager ist es weitaus bequemer.

    Kommentar


    • #3
      Der Vergleich zu apt ist gut, das macht es verständlich. Ich weiß aber schon, was Composer macht. Bei apt kann ich Sources festlegen, denen ich vertraue. Soweit ich weiß, geht das mit Composer nicht. Ich denke, ich gebe da möglicherweise zuviel Verantwortung ab.

      Ich hatte mal mit NodeJS herumprobiert und war ehrlich gesagt überrascht, wie viele Ordner und Dateien unter vendor zu finden waren. Deutlich mehr als ich erwartet hatte und nahezu unmöglich alle zu kontrollieren. Da wird eben auch installiert, was möglicherweise benötigt wird. Auch darum habe ich Abstand genommen. Ich weiß nie, was da installiert wird und müsste bei jedem Update prüfen, ob das noch kosher ist.

      Bequemer mag das sein, so muss man sich nicht selbst zusammen suchen, was man braucht. Und man kann davon ausgehen, dass das dann auch zusammen läuft. Aber was, wenn die irgendwann eine Gegenleistung wollen? Die wissen schon durch die Verwendung, dass ich eine bestimmte Software nutze. Wenn die diese Info zu Geld machen, werden sie sicherlich bald mehr wollen. Als Nächstes kommt dann die Registrierung mit Mail-Adresse und Klarnamen. Womöglich werden Entwickler und Pakete ausgeschlossen, die keine Gebühren entrichten wollen?

      Für mich ist das eine Medaille mit zwei Seiten. Warum sich Entwickler darauf einlassen, ist klar. Damit steigen die Nutzerzahlen, wenn das erst etabliert ist. Die neuen Programmierer wachsen gleich in diese Abhängigkeit hinein. Aber ich meine, dass man nichts geschenkt bekommt, auch darum bin ich vorsichtig.

      Gibt es auch Erfahrungen oder Bedenken, die du teilen kannst? Nutzt du Composer oder etwas Vergleichbares?

      Kommentar


      • #4
        Composer hilft dir auch dabei, die Constraints der Sachen zu beachten, die du für die Projekt zusammenwirfst. Beim manuellen Zusammenstellen könnte das etwas fummelig werden ist ja so teilweise schon zum Haare-raufen

        Der Composer ist nicht das Non-plus-Ultra, hat sich aber als Standard etabliert. Kaum ein professionelles Projekt dürfte es noch ohne machen...

        Warum sich Entwickler darauf einlassen, ist klar. Damit steigen die Nutzerzahlen, wenn das erst etabliert ist.
        In erster Line erleichtert es die Arbeit von Entwicklern... Software zu verwalten, die aus Komponenten besteht, ist keine Kleinigkeit. Das mag im Wald-und-Wiesenprojekt noch funktionieren, aber nicht mehr im kommerziellen Umfeld, wenn dutzende Entwickler an komplexen Anforderungen arbeiten.. wer da keine Hilfsmittel zur Strukturierung nutzt, wird verrückt.

        Du hast in der Ausbildung (hoffe ich) gelernt, das man Software wiederverwenden kann und sollte. Das man nichts geschenkt bekommt ist zudem nicht wahr. Der Gedanke von OpenSource, freeware oder shareware kommt nicht von ungefähr, weil ganz normale, nette Menschen (die Community) andere an ihrem Werk teilhaben lassen wollen. Klar gibt es auch die anderen, die bösen, aber erstaunlicherweise scheint es bei weitem mehr von den Guten zu geben, die diesen Gedanken weiterleben lassen und nützlichen Code produzieren, den sie anderen frei zur Verfügung stellen. Software ist ein sonderbares Gut, denn wenn man es teilt, vervielfältigt es sich (denk mal drüber nach )

        Bischen wie wir hier im Forum... wir helfen anderen, die wir gar nicht kennen, in unserer Freizeit, ohne Bezahlung... einfach aus Freundlichkeit und dem Bedürfnis, jemandem etwas nützliches beibringen zu können. Niemand wurde dazu gezwungen, die Leute, die sowas machen, sind einfach nett (das unterstelle ich einfach mal jedem hier )
        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar


        • #5
          Ich habe immer alles kompakt gehalten, weniger Bibliotheken als Funktionen benutzt und wenn es läuft, laufen lassen. Bin letztendlich gut damit gefahren, Code selbst zu schreiben und Pakete von Hand einzubauen.

          Ich habe mich auch viel eingebracht, Projekte in Lateinamerika durch Webseiten unterstützt, den besten, kostenlosen Wappengenerator ins Netz gestellt, und über Jahre ein Forum für 3D-Enthusiasten administriert - alles ehrenamtlich, kostenfrei und bis auf wenige, gesponsorte Events werbefrei.

          Es gibt aber auch die, die Einnahmen generieren. Die können kontinuierlich in Marketing und Entwicklung investieren. Weil das ihr Leben finanziert, machen sie auch dann weiter, wenn es zeitlich eng wird oder neue Herausforderungen locken. Darum haben die einen Vorteil.

          Wie sicher die von Composer installierten Pakete sind, müssen in meinem Fall wohl die Entwickler von Drupal bzw. Drupal-Addons festlegen. Ich erinnere mich gut, dass insbesondere "die Großen" immer wieder Exploits glänzen. Bei vBulletin war unsere Community z.B. vom Zero-Day 2019 betroffen. Ich glaube, deshalb fällt mir der Umstieg nicht leicht. So viele Ordner und jede Menge Code, wo sich ein Sicherheitsleck verstecken kann. Ich werde einfach im Netz nach Sicherheitslücken suchen. Da werde ich wohl eine Antwort finden.

          Kommentar


          • #6
            Du hast bei egal welcher Drittanbieter Software immer das Risiko, dass etwas nicht sicher ist
            Sogar der Linux Kernel oder PHP selbst waren davon nicht verschont.

            Gerade wenn du auf ein großes CMS mit Plugins etc. setzt, erhöht sich das Risiko.
            Bei den "großen" hast du aber eher die Chance, dass jemand schnell darüber berichtet und es ggf. sogar herstellerseitig ganz fix einen Patch gibt.

            Du solltest also wie bei der Auswahl jeder anderen Software auch darauf achten, dass der Anbieter eines Paketes vertrauenswürdig ist.

            Dass ein Paket auf Packagist selbst kompromittiert wird, ist eher unwahrscheinlich, bzw. man würde es auch ziemlich zügig erfahren und es würde offline genommen.

            Wenn der Anbieter eines Package einen guten Job gemacht hat, dann wird auch tatsächlich nur das installiert, was wirklich benötigt wird. Ein seriöser Anbieter wird dir niemals etwas "auf gut Glück" mit ausliefern. Im Gegenteil findet man in Dokumentationen häufig Hinweise, dass für dieses oder jenes feature ein zusätzliches Paket hinzugefügt werden muss.

            Diese Abhängigkeiten hast du aber bei egal welcher Installationsmethode. Das ist auch nichts ungewöhnliches. Auch ein APT installiert dir alle Abhängigkeiten gleich mit.

            Es geht also einzig um die Frage, inwieweit du dem Anbieter vertrauen kannst oder nicht. Drupal selbst hatte in der Vergangenheit einige hässliche kritische Lücken. Trotzdem wird die aktuelle Version (und leider auch viele veraltete Version) zahlreich eingesetzt, weil man eben daran glaubt, dass die Lücken zeitnah erkannt und behoben werden.


            ​​​​​​
            ​​​​​
            Good programming is 5% knowledge, 5% skill, 20% caffeine, 30% attention to detail and 40% RTFM
            Kapazitäten frei: Einfach per PN ein Angebot einholen.

            Kommentar


            • #7
              viele packete - auch von seriösen anbietern, manchen wurde möglicherweise falsch geholfen, bei andreren haben sich falsche helfer eingeschlichen, bei dritte wiederum ist ein passwort oder ein stück hardwarwe verlohren geangen..
              es gibt böse menschen, und es gibt wenig möglichkeiten sie effektiv auszuschliuessen.

              der vorteil, wie oben erwähnt, es fällt schneller auch und kann deswegen schneller gefixt oder zumindest temporär überbrückt werden.


              es gibt mehre möglichkeiten, den von dir genutzeten werdencode an verschiedenen stellen der deploying gegenm sicherheitslücken zu testen.
              eine davon,lieferst composer mit:

              https://getcomposer.org/doc/03-cli.md#audit

              andere findest du im netzt

              Kommentar

              Lädt...
              X