4 ms·
With things that don't change often like JSON, XML and crypto, the same argument doesn't hold much value though.
by endorphine 4y ago
With things that don't change often like JSON, XML and crypto, the same argument doesn't hold much value though.
- maxbond 4y agoThose are all use cases that are likely to have security issues; it would be nice if we could release security fixes for them without needing to bump up the release schedule of the entire language. (But this is an area where good engineers reasonably differ.)
- fiedzia 4y agocrypto does change. Maybe not specifications of specific algorithms, but which of them are supported may change. Do we want to break existing code when one of them will become deprecated or do we want to allow insecure method to be used to make web requests?
- cesarb 4y ago> > With things that don't change often like [...] and crypto > crypto does change A nearby comment mentioned Python, which did have that problem. The ssl module on its standard library didn't verify certificates by default, and since that's no longer considered good cryptographic practice (to put it mildly), that behavior had to change, even though it could break existing code. See for instance https://access.redhat.com/articles/2039753 https://access.redhat.com/articles/2039753 and the several PEPs it links to, in particular https://peps.python.org/pep-0466/ https://peps.python.org/pep-0466/ which is about the backporting of the Python 3.x version of that module to a patch release of Python 2.7.