4 ms·

I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? Presumably you'd have to bump the

I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? Presumably you'd have to bump the language version, deploy it out and beg users to upgrade. Except, users don't upgrade stuff. While if you version the standard library, every new project will get the newer version of the standard library. Sure, there's space tradeoffs, though you could offer a manual linking option. But at the very least, the amount of new projects with the vulnerability will be next to nil. And what if the standard library just gets dated? Take Node for instance. The fs module has a whole bunch of outdated callback based functions. Sure, you can wrap them in promisify, but it sucks that we have these outdated functions stuck around forever. There's definitely tradeoffs with package/dependency multiplication, but I don't think standard libraries are as clear cut as people make them out to be.

perlgeek 7y ago
> I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? That depends on what you are writing. For an application that is deployed stand-alone, you'll likely fat-package it with python and all the libraries. In case of a security issue, you create a new version of your application that bundles the fixed python. For an application that is deployed on the system python (more typical on Linux), it's the system admin's task to update the system python.
- _hardwaregeek 7y ago
  I'm talking from a language maintainer perspective. From a user perspective, sure, you can upgrade. But that doesn't mean everybody will upgrade. In general, people don't like upgrading. That's why browsers all automatically update these days.
will4274 7y ago
You're trading things to update. Either the bug is in the standard library and you need to update the standard library or the bug is not in the standard library and you need to update not-the-standard-library. Either way, the maintainer of the library can't get everybody to upgrade.
Jach 7y ago
> What happens if you discover a security vulnerability in your stdlib? As the user of the stdlib, it really depends on what the security issue is. For most users, if they can verify they're not using module X, then there's no problem and no rush for them to upgrade. In a language like Python that's very dynamic, you also might be able to download a hotfix .py file provided by the language maintainers (or any other party) as an alternative to upgrading, or as something for the interim while you wait for the upgrade to get released, backported and released for older major versions, and available for the deploy environment -- this might even take the form of an iptables rule, depending on the issue. In short my point is that there are alternatives besides bumping one release's release version and hoping people upgrade. > Except, users don't upgrade stuff. Actually users do. Not all users, but your sweeping statement isn't true of all users either. Experience and reading reports tell me that many if not most users actually upgrade, especially when there's a significant security issue and especially when upgrading is easy. 2.7.14 to 2.7.15 was a problem for no one. For the users who don't upgrade, they're not likely to upgrade a third party / split off thing any more than the core language. There's also another party of users worth mentioning, those that don't upgrade specific things because past upgrades have been a terrible experience. This is a reputation issue. > And what if the standard library just gets dated? Take Node for instance. The fs module has a whole bunch of outdated callback based functions. Sure, you can wrap them in promisify, but it sucks that we have these outdated functions stuck around forever. Sucks for whom? I've been out of the Node ecosystem for several years, is there a pfs module that uses promises (either built-in or as an external lib)? If so users can use that if they want. Does it suck for the maintainer? I don't see how if those functions are small and don't really need any maintenance. What would suck is if all the existing programs that wrote some fs-using code a long time ago and haven't had to touch it now suddenly need to go update it to satisfy people's fashions. You might be interested in this talk that makes the case to stop breaking your API especially if you're requiring more and providing less. https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
- _hardwaregeek 7y ago
  > Actually users do. Not all users, but your sweeping statement isn't true of all users either. Experience and reading reports tell me that many if not most users actually upgrade, especially when there's a significant security issue and especially when upgrading is easy. 2.7.14 to 2.7.15 was a problem for no one. Sure, some people definitely upgrade. But there's a big difference between requiring someone to actively hear and heed your warning and having them automatically upgrade whenever they create a newer project. Or even just prompting them to upgrade like NPM does for package vulnerabilities. > For the users who don't upgrade, they're not likely to upgrade a third party / split off thing any more than the core language. That's not the point. If your standard library is a package, any new project will automatically download the latest version of the standard library. If I have a vulnerability in an npm package, I simply push a new version and people will automatically download that new version when they create a new project. If there is a vulnerability in the Python standard library, users will continue to have that vulnerability until they actively patch it. > Sucks for whom? I've been out of the Node ecosystem for several years, is there a pfs module that uses promises (either built-in or as an external lib)? If so users can use that if they want. Does it suck for the maintainer? I don't see how if those functions are small and don't really need any maintenance. Not a canonical one. They're starting to add a new promise based API, but now we have two different APIs doing the same thing. What if we come up with a newer way to do async? Do we add yet another API? > What would suck is if all the existing programs that wrote some fs-using code a long time ago and haven't had to touch it now suddenly need to go update it to satisfy people's fashions. That's a bit of a straw man. With packages, you can still support multiple versions. It's just that fs would no longer be tied to Node. You could make a newer fs package, fs 2.0 or whatever, that uses promises. The older one would still be supported, of course, but it wouldn't be stuck in Node.
dvhh 7y ago
From a different perspective, servers usually have a maintenance cycle to update system package where the standard library could be updated, user package on the other hand have to be updated by the user themselves ( and they could stick with the obsolete version if they want too, and could have a per project package version ) there is no convenient way for the user to update all the versions.
- _hardwaregeek 7y ago
  > there is no convenient way for the user to update all the versions. Perhaps I'm misreading this, but isn't that the purpose of package managers? I can run an `npm install foo` and update it at will.
  - dvhh 7y ago
    there is no such thing like "npm update" to update all package as far as am aware for the python world ( at least as far as pip is concerned ), plus user deployed package could not be covered by update performed by the system administrator.

perlgeek 7y ago

> I've wondered about standard libraries for a while now. What happens if you discover a security vulnerability in your stdlib? That depends on what you are writing. For an application that is deployed stand-alone, you'll likely fat-package it with python and all the libraries. In case of a security issue, you create a new version of your application that bundles the fixed python. For an application that is deployed on the system python (more typical on Linux), it's the system admin's task to update the system python.

_hardwaregeek 7y ago
I'm talking from a language maintainer perspective. From a user perspective, sure, you can upgrade. But that doesn't mean everybody will upgrade. In general, people don't like upgrading. That's why browsers all automatically update these days.

will4274 7y ago

You're trading things to update. Either the bug is in the standard library and you need to update the standard library or the bug is not in the standard library and you need to update not-the-standard-library. Either way, the maintainer of the library can't get everybody to upgrade.

Jach 7y ago

> What happens if you discover a security vulnerability in your stdlib? As the user of the stdlib, it really depends on what the security issue is. For most users, if they can verify they're not using module X, then there's no problem and no rush for them to upgrade. In a language like Python that's very dynamic, you also might be able to download a hotfix .py file provided by the language maintainers (or any other party) as an alternative to upgrading, or as something for the interim while you wait for the upgrade to get released, backported and released for older major versions, and available for the deploy environment -- this might even take the form of an iptables rule, depending on the issue. In short my point is that there are alternatives besides bumping one release's release version and hoping people upgrade. > Except, users don't upgrade stuff. Actually users do. Not all users, but your sweeping statement isn't true of all users either. Experience and reading reports tell me that many if not most users actually upgrade, especially when there's a significant security issue and especially when upgrading is easy. 2.7.14 to 2.7.15 was a problem for no one. For the users who don't upgrade, they're not likely to upgrade a third party / split off thing any more than the core language. There's also another party of users worth mentioning, those that don't upgrade specific things because past upgrades have been a terrible experience. This is a reputation issue. > And what if the standard library just gets dated? Take Node for instance. The fs module has a whole bunch of outdated callback based functions. Sure, you can wrap them in promisify, but it sucks that we have these outdated functions stuck around forever. Sucks for whom? I've been out of the Node ecosystem for several years, is there a pfs module that uses promises (either built-in or as an external lib)? If so users can use that if they want. Does it suck for the maintainer? I don't see how if those functions are small and don't really need any maintenance. What would suck is if all the existing programs that wrote some fs-using code a long time ago and haven't had to touch it now suddenly need to go update it to satisfy people's fashions. You might be interested in this talk that makes the case to stop breaking your API especially if you're requiring more and providing less. https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk

_hardwaregeek 7y ago
> Actually users do. Not all users, but your sweeping statement isn't true of all users either. Experience and reading reports tell me that many if not most users actually upgrade, especially when there's a significant security issue and especially when upgrading is easy. 2.7.14 to 2.7.15 was a problem for no one. Sure, some people definitely upgrade. But there's a big difference between requiring someone to actively hear and heed your warning and having them automatically upgrade whenever they create a newer project. Or even just prompting them to upgrade like NPM does for package vulnerabilities. > For the users who don't upgrade, they're not likely to upgrade a third party / split off thing any more than the core language. That's not the point. If your standard library is a package, any new project will automatically download the latest version of the standard library. If I have a vulnerability in an npm package, I simply push a new version and people will automatically download that new version when they create a new project. If there is a vulnerability in the Python standard library, users will continue to have that vulnerability until they actively patch it. > Sucks for whom? I've been out of the Node ecosystem for several years, is there a pfs module that uses promises (either built-in or as an external lib)? If so users can use that if they want. Does it suck for the maintainer? I don't see how if those functions are small and don't really need any maintenance. Not a canonical one. They're starting to add a new promise based API, but now we have two different APIs doing the same thing. What if we come up with a newer way to do async? Do we add yet another API? > What would suck is if all the existing programs that wrote some fs-using code a long time ago and haven't had to touch it now suddenly need to go update it to satisfy people's fashions. That's a bit of a straw man. With packages, you can still support multiple versions. It's just that fs would no longer be tied to Node. You could make a newer fs package, fs 2.0 or whatever, that uses promises. The older one would still be supported, of course, but it wouldn't be stuck in Node.

dvhh 7y ago

From a different perspective, servers usually have a maintenance cycle to update system package where the standard library could be updated, user package on the other hand have to be updated by the user themselves ( and they could stick with the obsolete version if they want too, and could have a per project package version ) there is no convenient way for the user to update all the versions.

_hardwaregeek 7y ago
> there is no convenient way for the user to update all the versions. Perhaps I'm misreading this, but isn't that the purpose of package managers? I can run an `npm install foo` and update it at will.
- dvhh 7y ago
  there is no such thing like "npm update" to update all package as far as am aware for the python world ( at least as far as pip is concerned ), plus user deployed package could not be covered by update performed by the system administrator.