I feel like there are basically two types of dependencies: for the sake of bikeshedding, call them A and B.
Type A dependencies are things like PGP, your kernel, your web browser, your SSL implementation, your Acme/Let’s Encrypt client, your MTA, ‘sanitize-html’, etc: things that talk to the outside world and/or pose a security risk.
Type B dependencies are things like ‘react-loading-spinner’, your MUA, your terminal emulator, etc. These are things that don’t talk to the outside world, don’t touch secrets, and don’t have significant security implications.
I want my package manager to be able to either realise for itself or be told that type A dependencies should be upgraded as soon as possible. I want it to pester and harass me about updates to these sorts of dependencies. I also think you should be meticulously careful about introducing these sorts of dependencies. The latter kind of dependencies are different: throw them in willy-nilly, do what you like with them, leave them for years or don’t, up to you. Never auto-update them.
If you maintain a type A dependency you have a responsibility to ensure that you do maintain backwards compatibility. People should be able to rely on you. They (and in this case NPM) should be able to auto-update type A dependencies without thinking about it really.
Because really, npm updating sanitize-html is not a bad thing. Do you want to sit around on an old insecure version of a library that sanitizes HTML? Presumably you want your HTML sanitised for a reason.
There is no such thing as a library that categorically “does not touch secrets”. A terminal emulator has to render a mix of secret data and untrusted data, react-loading-spinner could be replacing itself with a widget full of sensitive data and have access to that for a brief moment, and I’m honestly surprised that you think an email client is type B (the mail server that it talks to is trusted, but the email payload is where most of the complexity is, and it’s not trusted data).
I feel like there are basically two types of dependencies: for the sake of bikeshedding, call them A and B.
Type A dependencies are things like PGP, your kernel, your web browser, your SSL implementation, your Acme/Let’s Encrypt client, your MTA, ‘sanitize-html’, etc: things that talk to the outside world and/or pose a security risk.
Type B dependencies are things like ‘react-loading-spinner’, your MUA, your terminal emulator, etc. These are things that don’t talk to the outside world, don’t touch secrets, and don’t have significant security implications.
I want my package manager to be able to either realise for itself or be told that type A dependencies should be upgraded as soon as possible. I want it to pester and harass me about updates to these sorts of dependencies. I also think you should be meticulously careful about introducing these sorts of dependencies. The latter kind of dependencies are different: throw them in willy-nilly, do what you like with them, leave them for years or don’t, up to you. Never auto-update them.
If you maintain a type A dependency you have a responsibility to ensure that you do maintain backwards compatibility. People should be able to rely on you. They (and in this case NPM) should be able to auto-update type A dependencies without thinking about it really.
Because really, npm updating sanitize-html is not a bad thing. Do you want to sit around on an old insecure version of a library that sanitizes HTML? Presumably you want your HTML sanitised for a reason.
There is no such thing as a library that categorically “does not touch secrets”. A terminal emulator has to render a mix of secret data and untrusted data, react-loading-spinner could be replacing itself with a widget full of sensitive data and have access to that for a brief moment, and I’m honestly surprised that you think an email client is type B (the mail server that it talks to is trusted, but the email payload is where most of the complexity is, and it’s not trusted data).