DPD, die zweite.

Vor ein paar Tagen, habe ich ja berichtet, daß DPD seine Pakete für Kunden nicht immer an die Haustür liefert. Grund ist natürlich, daß die Zusteller nicht pauschal bezahlt werden, sondern nach Paketen, die sie zugestellt haben. Eine Quelle bei der Konkurrenz hat das bestätigt 😉 Als Zustellung gilt auch, wenn es im DropShop abgeworfen wird.  Dem Zusteller ist es also egal, ob er es persönlich abgibt oder es im DropShop landet.

Ursachen

Wichtig für den Zusteller ist, daß er möglichst viele Pakete  am Tag schafft, weil die Marge so gering ist. D.h. nicht zum Kunden zu fahren und alles im Shop abzuwerfen, ist im Interesse des Zustellers um auf seinen Verdienst zu kommen. Kundenservice kann ihm egal sein, er trifft den Kunden ja nicht, auch wird es ihm egal sein, daß der Transportvertrag die Lieferung an die Tür vorsieht. Da wird es sicherlich Ausnahmen geben, so von wegen Berufsehre usw.. aber wer kann sich die schon leisten ?

Jetzt zum Paket

Das ist natürlich nie gekommen, es wurde nicht im DropShop abgegeben, es wurde nicht an die Haustür geliefert, es wurde nicht nochmal zugestellt und es wurde mit dem Kunden, also mir, auch keine Vereinbarung getroffen. Trotzdem hatte das Paket 3 Tage nach der Arbeitsverweigerung des Zustellers und somit 3 Tage Lagerung im Zentrallager, davon 2 Arbeitstage, plötzlich den Vermerk, daß der Kunde die Annahme verweigert hat. Ich wünschte, ich hätte die Gelegenheit dazu gehabt.

Natürlich ist genau das Gegenteil zutreffend, denn ich habe mehrfach in der Zeit bei DPD angefragt, ob mir jemand sagen kann, wie es weiter geht, wann es erneut geliefert wird und ausdrücklich auf Zustellung an die Haustür bestanden. Um es nochmal deutlich zu machen, es ging um 15g Wachs für 6 € ! und nicht um ein 40kg Paket 😀

„Zurück zum Lück“

Das Paket ging dann an den Absender, dem es technisch nicht mehr gehört hat, zurück. Zum Glück habe ich mit dem über Ebay die ganze Zeit Infos ausgetauscht, da absehbar war, das DPD keinen Bock hat, wurde es zwischenzeitlich erneut per DHL verschickt.

In der Zeit, in der das Paket nicht von DPD geliefert wurde, schlug DHL 2x bei mir auf 🙂 und nach 2 weiteren Tagen war dann auch der Briefumschlag aus Pappe mit dem 15g Döschen Wachs da. Ok, der Herr von DHL war wegen dem Brief dann nicht extra an der Tür, dafür gibt es ja schließlich diese ominösen Briefkästen, aber er war da, was ihn extrem positiv gegenüber DPD erscheinen läßt 😀

Merke: DHL Boten werden pauschal bezahlt, DPD Zusteller werden ausgebeutet mit Akkordarbeit.

Also seid nett zu Eurem Zusteller, egal von welchem Dienst er kommt, die haben es beide nicht leicht. Mein DHLer bekommt demnächst einen kleinen Anerkennungsbonus.

Signieren von npm Paketen

Zur Einleitung eine kleine Geschichte zu einem Projekt, daß ich mit einem unserer Kunden umgesetzt habe. Da das Projekt mangels Benutzer jüngst eingestellt wurde, ist wohl die Floskel „Es war einmal…“ angebracht 🙂

Die Geschichte von Lord Uglify

Also.. Es war einmal .. ein tolles webbasiertes Firmenspiel für das jede Menge Javascriptcode erzeugt wurde, weil es ja im Browser zu spielen war. Nun sollte das ellenlange Javascript eingedampft werden mit „Uglify“ einem node.js Tool zum Schrumpfen und Verschleiern von Javascriptcode.

Nun sollte jemand Uglify irgendwo installieren und es dafür benutzen. Das war der erste Fehler. Nachdem Node.Js aus dem Repository installiert wurde, tat es natürlich nichts sinnvolles, denn Uglify hat wie so viele andere Node.js Programme, einen Abhängkeitsbaum, der milde betrachtet, bis zum Mond reicht. Mit NPM, dem Node.Js Paketmanager, kann man die Abhängkeiten befriedigen, glaubten wir zumindest. Das war Fehler Nummer 2. Denn die Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten der Abhängigkeiten von den Abhängigkeiten die keine Ende nehmen wollten, brauchten geschlagene 30 Minuten sich zu installieren. Na gut, jetzt wird es ja wohl endlich starten. Das war der dritte Fehler.. allerdings dann auch der letzte, weil ich keinen Bock mehr hatte mich von so einem Witzprogramm verarschen zu lassen.

Ich habe dann einfach „jsmin“ genommen: klein,schnell,effektiv,läuft überall, keine Abhängigkeiten und einfachst zu bedienen. Kurzum, ein Programm wies sein sollte.

Was hat das jetzt mit dem Signieren von Paketen zu tun ?

Tja, wie man oben lesen kann, sind Node.js Programm extrem modularisiert, sprich, mal eben selbst was schreiben ist praktisch nicht, weil man erst mal jede Menge an Paketen installieren muß. Im Gegensatz zu Java, wo eine Fülle von Klassen mitgeliefert werden, kommen die Pakete per NPM ins Projekt rein.

Diese Pakete sind nicht signiert, die von Java zwar auch nicht, aber die kommen ja auch aus einer definierten Quelle gleich mit. Signieren ist im NPM auch nicht vorgesehen. Daher hat jemand in Australien ( Details bei Heise ) gemeint, er müßte das ändern und hat ein Signaturtool für Node.js Pakete gebaut.

Die Begründung war, das neulich diverse Pakete aus dem NPM Repo auf merkwürdige Art verschwunden sind, zwischenzeitlich durch gleichnamige Pakete ersetzt wurden, um dann funktional mit den früheren Paket  zu kollidieren, sprich, was anderes zu machen, als das Original.

Da jeder Pakete in das NPM Repo laden kann, würde das Signieren also den Prozess mit den Paket-Abhängigkeiten sicherer machen, weil wenn sich so ein Vorgang wie eben beschrieben passiert, würde ja die Signatur nicht mehr passen und dem Entwickler würde dann auffallen, daß da gerade was schief läuft. Nun, das mag sein.

Das eigentliche Problem

Das eigentliche Problem löst das natürlich nicht: 100 Abhängigkeiten im Projekt, und den von den Entwicklern hat noch nie einer gehört. Ob die da Schadcode einbauen oder nicht, kann man nicht an der Tatsache einer gültigen Signatur erkennen.
Alles was dieses Signaturen bieten, ist ein Verwechslungsschutz, das aber auch nur, wenn der lange verschollene Author doch nochmal gefunden wird 🙂

Ich halte das für nichts, was man an die große Glocke hängen sollte, denn das hier kann man damit nicht vermeiden:

https://hackernoon.com/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5

Es lohnt sich bis zum Ende zu lesen, weil Ihr sonst einen falschen Eindruck von der Sache bekommt. Wenn Ihr damit fertig sein, hier ein Zitat von „blog.fefe.org“ unser aller Weltverschwörungsguru 😉 passend zum Thema :

[l] Ein Einsender kommentiert die Webfrontend-Warnung:

  • lass‘ uns als kleine Veranschaulichung, wie breit und tief die Güllegrube npm sein kann, eine Webanwendung anfangen. Natürlich mit Angular und dem aktuellen Standard-Build-System @angular/cli:

    $ npm i @angular/cli
    $ node_modules/.bin/ng new webkid --directory=.

    Das Ergebnis ist ein Skeleton mit einer Hello-World-Seite und:
    31 direkten Abhängigkeiten
    974 Abhängigkeiten insgesamt
    305 MB in node_modules

    Davon sind 158 Pakete Duplikate von bereits installierten Paketen mit einer anderen Versionsnummer. Bei so vielen Abhängigkeiten ändern sich die Zahlen natürlich schnell, also am besten sofort anfangen mit dem Audit!“

    “ [Ende des Zitats]  Aufgrund der Struktur von Fefes Webseite, müßt Ihr selbst den „Wed Jan 10 2018“ suchen 😉

 

Dem Kommentar kann man sich nur anschließen. Keine Signatur der Welt macht das irgendwie sicherer!

Davon ab, keine Ahnung wie jemand auf die Idee kommt, dafür zu Entwickeln. Da braucht man ja Stunden um anzufangen. Leute nehmt was vernünftiges, nehmt Java. Eclipse auf. Neues Javaprojekt aufmachen und einfach losschreiben 😉

Java kommt übrigens leer mit knapp 105 MBye aus 😉 und das wäre dann auch für alle Projekte und nicht PRO Projekt 😀

Quelle: heise.de – Open Source Tool zum Signieren von npm Paketen veroeffentlicht