> Die Paketierung ist im JS Umfeld bereits heute sehr beliebt
Saubere Paketierung ist das, was z.B. Linux-Distributionen machen, nicht das, was das "JS Umfeld" darunter versteht.
Wer sagt mir bei "require foo", dass ich dem, was in irgendeiner Form geladen wird, vertrauen kann!? Ich spreche hier von standardisierten und verifizierbaren weil signierten Paketen, die über einen Distributor verteilt werden und systemweit ausgetauscht werden können.
Von blablabla233 am Mo, 27. November 2017 um 13:26 #
Ich verstehe ja was Du meinst...ABER weshalb vertraust einer Distribution mehr wie dem Upstream? Ist ja nicht/nicht-unbedingt so wie wenn eine Distributionen einen Codeaudit macht bevor es gepackt wird.
> weshalb vertraust einer Distribution mehr wie dem Upstream?
Andersrum wird übrigens auch ein Schuh draus: Projekt X verwendet eine z.B. veraltete, unsichere oder lokal gepatchte JQuery-Bibliothek. Ich möchte aber ein signiertes ungepatchtes Original von Upstream. D.h. wenn Projekt X eine Verbesserung oder eine Fehlerkorrektur macht, dann soll Projekt X bitte mit dem JQuery-Team zusammenarbeiten und nicht den Andwender die Scheiße ausbaden lassen.
Übrigens gibt es tatsächlich Umgebungen, in denen Code Audits, Pentests usq. "vorkommen"...
> Die Entwickler haben schlicht vergessen, dieses Verzeichnis via .gitignore aus dem Commits heraus zu halten.
Nachtrag: Derartige Pakete auf lokaler Projektebene zum Entwicklungszeitpunkt sind verständlicherweise bequem; Aber diese Herangehensweise ist im Grunde schon Teil des Problems.
Mir ist nicht klar, welche Alternative zu dazu siehst. Die Dateien müssen für das Projekt verfügbar sein, sonst wären sie nicht nutzbar. Dateien außerhalb eines Projektes zu speichern ist unsauber und fehleranfällig, speziell wenn verschiedene Projekte unterschiedliche Versionen eines Pakets benötigen.
Das Vorgehen ist an sich absolut ok, es ist eben nur ein Fehler in der .gitignore Datei. Die Dateien müssen nicht commited werden, da hat jemand einfach gepennt.
> Dateien außerhalb eines Projektes zu speichern ist unsauber und fehleranfällig, speziell wenn verschiedene Projekte unterschiedliche Versionen eines Pakets benötigen.
Dafür gibt es die Möglichkeit virtueller Umgebungen - ist zugegebenenermaßen Aufwand. Fehleranfällig - ja klar, wenn man auf saubere Buildskripte und hinreichende Testabdeckung verzichtet. Das ist genau der gesparte Aufwand, der Anderen später doppelt und dreifach auf die Füße fällt.
> Das Vorgehen ist an sich absolut ok, es ist eben nur ein Fehler in der .gitignore Datei. Die Dateien müssen nicht commited werden, da hat jemand einfach gepennt.
"Gepennt" ist gut. Die Realität ist doch, dass das vielen sch...egal ist. Viel zu oft findet man Drittcode (nicht nur JS), der sinnlos statisch eingebacken wird. Die Pflege von Abhängigkeiten sollte in eigenen Paketen/Repositorien geschehen und die über möglichst portable Buildskripte sauber referenziert werden.
Es ist nicht so, dass ich deinen Ansatz nicht nachvollziehen kann; Ist ja Aufwand, den man nicht bezahlt bekommt.
> Die Paketierung ist im JS Umfeld bereits heute sehr beliebt
Saubere Paketierung ist das, was z.B. Linux-Distributionen machen, nicht das, was das "JS Umfeld" darunter versteht.
Wer sagt mir bei "require foo", dass ich dem, was in irgendeiner Form geladen wird, vertrauen kann!? Ich spreche hier von standardisierten und verifizierbaren weil signierten Paketen, die über einen Distributor verteilt werden und systemweit ausgetauscht werden können.
Ich verstehe ja was Du meinst...ABER weshalb vertraust einer Distribution mehr wie dem Upstream? Ist ja nicht/nicht-unbedingt so wie wenn eine Distributionen einen Codeaudit macht bevor es gepackt wird.
> weshalb vertraust einer Distribution mehr wie dem Upstream?
- Prinzip "Second pair of eyes" - was sicherlich nicht im absoluter Sicherheit garantiert ist
- Saubere Integration ins Gesamtsystem.
Nachtrag:
> weshalb vertraust einer Distribution mehr wie dem Upstream?
Andersrum wird übrigens auch ein Schuh draus: Projekt X verwendet eine z.B. veraltete, unsichere oder lokal gepatchte JQuery-Bibliothek. Ich möchte aber ein signiertes ungepatchtes Original von Upstream. D.h. wenn Projekt X eine Verbesserung oder eine Fehlerkorrektur macht, dann soll Projekt X bitte mit dem JQuery-Team zusammenarbeiten und nicht den Andwender die Scheiße ausbaden lassen.
Übrigens gibt es tatsächlich Umgebungen, in denen Code Audits, Pentests usq. "vorkommen"...
> Die Entwickler haben schlicht vergessen, dieses Verzeichnis via .gitignore aus dem Commits heraus zu halten.
Nachtrag: Derartige Pakete auf lokaler Projektebene zum Entwicklungszeitpunkt sind verständlicherweise bequem; Aber diese Herangehensweise ist im Grunde schon Teil des Problems.
Mir ist nicht klar, welche Alternative zu dazu siehst. Die Dateien müssen für das Projekt verfügbar sein, sonst wären sie nicht nutzbar.
Dateien außerhalb eines Projektes zu speichern ist unsauber und fehleranfällig, speziell wenn verschiedene Projekte unterschiedliche Versionen eines Pakets benötigen.
Das Vorgehen ist an sich absolut ok, es ist eben nur ein Fehler in der .gitignore Datei. Die Dateien müssen nicht commited werden, da hat jemand einfach gepennt.
> Dateien außerhalb eines Projektes zu speichern ist unsauber und fehleranfällig, speziell wenn verschiedene Projekte unterschiedliche Versionen eines Pakets benötigen.
Dafür gibt es die Möglichkeit virtueller Umgebungen - ist zugegebenenermaßen Aufwand. Fehleranfällig - ja klar, wenn man auf saubere Buildskripte und hinreichende Testabdeckung verzichtet. Das ist genau der gesparte Aufwand, der Anderen später doppelt und dreifach auf die Füße fällt.
> Das Vorgehen ist an sich absolut ok, es ist eben nur ein Fehler in der .gitignore Datei. Die Dateien müssen nicht commited werden, da hat jemand einfach gepennt.
"Gepennt" ist gut. Die Realität ist doch, dass das vielen sch...egal ist. Viel zu oft findet man Drittcode (nicht nur JS), der sinnlos statisch eingebacken wird. Die Pflege von Abhängigkeiten sollte in eigenen Paketen/Repositorien geschehen und die über möglichst portable Buildskripte sauber referenziert werden.
Es ist nicht so, dass ich deinen Ansatz nicht nachvollziehen kann; Ist ja Aufwand, den man nicht bezahlt bekommt.