Neues YouTube-Video: Visualisierung im Devices-Adapter

[Thomas Braun]

@wendy2702 Ich habe damit sehr gemischte Ergebnisse gehabt.
audit fix geht oft noch relativ schmerzlos über die Bühne, aber auch nicht immer.
Vom forcen ganz die Finger lassen, das sorgt eigentlich immer für ganz böses Kopfweh.

Ich würde es einfach ignorieren und darauf hoffen, dass die Devs die Dependencies nach Möglichkeit in ihren Modulen entsprechend mitziehen.

Welcome to dependency hell!

[wendy2702]

OK.

Danke für euren Input.

Die werden nur gefühlt immer mehr deshalb wollte ich mal nachfragen.

Habe bisher immer mit dem audit fix leben können aber jetzt bekommt er nur noch 15 davon gelöst.

[Thomas Braun]

@wendy2702

Mit regulären Adapter-Updates werden das auch wieder weniger.

[wendy2702]

Dann warte ich mal bis/ob sich da noch etwas tut sonst mache ich bei Gelegenheit mal issues bei den entsprechenden Adaptern auf.

[Thomas Braun]

@wendy2702 Ja, das mit den Issues ist eine gute Idee.

[apollon77]

Also mit einem aktuellen "iob fix ausgeführtem System" sollte nie ein npm audit als Ausgabe kommen :) Wir haben an sich im Installer/Fixer drin das npm keine "audit" Meldungen mehr bringen soll :-)

[Thomas Braun]

@apollon77

Ich bin so frech und gebe das selber ein. :-P

[AlCalzone]

@wendy2702 sagte in Wie mit NPM Audit ergebnis umgehen?:

die teilweise vorgeschlagenen Befehle doch sicher ausführen und dabei Gefahr zu laufen das IOB danach nicht mehr läuft

fixed that for you :)

[apollon77]

@thomas-braun Na dann happy risk :-))

[Thomas Braun]

@apollon77

Ja, no risk, no fun!
Ich schau zwar schon mal öfters per audit rein, aber fixen tu ich das eigentlich nie. Lass ich wie oben gesagt auch die Finger von.

[apollon77]

@thomas-braun aahhh ... dann hatte ich es falsch verstanden :-)

[OliverIO]

@wendy2702
dieser befehl ist nur für package owner gedacht um Art der sicherheitsprobleme und ggfs deren Behebungsmöglichkeiten zu identifizieren.
Da hier aber auch oft Sicherheitslücken in, nennen wir es mal tiefer gelegenen paketen stehen, ist das nicht so einfach.
oft umfasst die Behebung auch breaking changes. dh der nutzende muss auch etwas in seinem paket machen.
Wenn das dann in einem paket ist, das du nur über eine andere Abhängigkeit nutzt, dann kannst du da nur wenig tun, ausser dich nach einem anderen Paket/Fork umschauen welches aktualisiert wurde oder die gleiche Funktionalität hat und besser gepflegt ist.

Das ist ein Vorteil aber auch ein nachteil von NPM bzw den javascript Paketmanagern generell.
Du kannst zwar schnell Pakete in dein Projekt einbinden, musst aber genau schauen, welche dependencies jedes einzelne Paket nutzt und wie sicher und gepflegt die sind und das kann sich jederzeit ändern.

[wendy2702]

MAcht es denn Sinn für diese im Audit benannten Adapter ein Issue zu öffnen um den Dev darauf hinzuweisen das es da was gibt oder ist das eher verschenkte Zeit ?

[OliverIO]

@wendy2702 wenn das problem direkt an einer abhängigkeit des adapters hängt, dann ja.
wenn es an einer Abhängigkeit an einer Abhängigkeit hängt dann nein. Erkennbar im audit-protokoll im Feld Dependency of

Github zeigt dem Entwickler diese Dinge auch an, wenn man dependabot nutzt.

so zb bei mytime

Das sind bspw alles Probleme, die nur in den devDependencies hängen (parcel, gulp).
Das betrifft die normale Installation eines Benutzers nicht, da diese Abhängigeiten gar nicht installiert werden.
Irgendwann werde ich das machen. Muss dazu aber parcel upgraden und das bedeutet uU Änderungen an config, code, tests, etc.

[OliverIO]

Ich konnte leider nicht das ganze Protokoll einfügen, was gar nicht so groß ist.
Es kam eine Fehlermeldung "Payload too large"

Spoiler

$ npm audit

                      === npm audit security report ===

┌───────────────────────────────────────────────────────────────────────────────
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└───────────────────────────────────────────────────────────────────────────────
┌───────────────────────────────────────────────────────────────────────────────
│ Moderate      │  Inefficient Regular Expression Complexity in                │
│               │ chalk/ansi-regex                                             │
├───────────────────────────────────────────────────────────────────────────────
│ Package       │ ansi-regex                                                   │
├───────────────────────────────────────────────────────────────────────────────
│ Patched in    │ >=5.0.1                                                      │
├───────────────────────────────────────────────────────────────────────────────
│ Dependency of │ parcel-bundler [dev]                                         │
├───────────────────────────────────────────────────────────────────────────────
│ Path          │ parcel-bundler > @parcel/logger > ora > strip-ansi >         │
│               │ ansi-regex                                                   │
├───────────────────────────────────────────────────────────────────────────────
│ More info     │ https://github.com/advisories/GHSA-93q8-gq69-wqmw            │
└───────────────────────────────────────────────────────────────────────────────

found 25 vulnerabilities (2 low, 19 moderate, 4 high) in 1284 scanned packages
 25 vulnerabilities require manual review. See the full report for details.

[wendy2702]

@oliverio Ja, das war bei mir auch zu lang.