3 ms·

I find it really interesting that they snuck the patch in to a commit months ago. Are there any other examples of something like this happening where maintainer

by aeleos 9y ago

I find it really interesting that they snuck the patch in to a commit months ago. Are there any other examples of something like this happening where maintainers had to obscure changes to the software?

ccrush 9y ago
All closed source software
firethief 9y ago
I think that's standard practice for cryptocurrencies. I mean, what else would you do, announce it and make users race with exploiters to react?
- runeks 9y ago
  He's not asking whether or not it's the wisest thing to do, but if there's precedent for this sort of thing (sneaking in fixes to fatal bugs in open source crypto-currencies). You seem to imply it has happened before; do you have any examples? It's inherently problematic because you need to somehow get your users to upgrade their software without knowledge of exactly why they need to do this. I know Bitcoin has had denial-of-service fixes sneaked in, but I'm not aware of anything of this nature. One thing's for sure: the commit logs of crypto-currencies will be scrutinized a lot more by black hats from now on.
  - firethief 9y ago
    I can't find any references to what I'd heard about bitcoin bug handling, but it was probably in reference to the DoS fixes. I haven't heard of any exploitable-for-profit bugs being handled the same way, but we wouldn't have, would we? So the question is whether a shut-down-everything DoS or a stolen money bug would be handled similarly, as a policy. I think if a stolen money bug were considered significantly worse than a shut-down-everything bug there would still be an alert system in place, since it could effectively reduce the former to the latter.
indolering 9y ago
This is a constant issue: what is the safest course of action? You start by patching your shit first, then push it upstream, and then slowly broaden the disclosure circle. Large software vendors (RedHat, IBM, etc) and infrastructure operators (Amazon, Cloudflare, etc) get advanced notice. Only then is it distributed to the public. This is the de-facto route for closed-source software, but Linus doesn't mark all security patches as such [0]. There are a lot of unpatched systems out there and Linus doesn't have the time to parse the exact ramifications of every security bug. That being said, it's pretty clear that we need to invest in more robust software development methods. [0]: http://yarchive.net/comp/linux/security_bugs.html http://yarchive.net/comp/linux/security_bugs.html

by aeleos 9y ago

ccrush 9y ago

All closed source software

firethief 9y ago

I think that's standard practice for cryptocurrencies. I mean, what else would you do, announce it and make users race with exploiters to react?

runeks 9y ago
He's not asking whether or not it's the wisest thing to do, but if there's precedent for this sort of thing (sneaking in fixes to fatal bugs in open source crypto-currencies). You seem to imply it has happened before; do you have any examples? It's inherently problematic because you need to somehow get your users to upgrade their software without knowledge of exactly why they need to do this. I know Bitcoin has had denial-of-service fixes sneaked in, but I'm not aware of anything of this nature. One thing's for sure: the commit logs of crypto-currencies will be scrutinized a lot more by black hats from now on.
- firethief 9y ago
  I can't find any references to what I'd heard about bitcoin bug handling, but it was probably in reference to the DoS fixes. I haven't heard of any exploitable-for-profit bugs being handled the same way, but we wouldn't have, would we? So the question is whether a shut-down-everything DoS or a stolen money bug would be handled similarly, as a policy. I think if a stolen money bug were considered significantly worse than a shut-down-everything bug there would still be an alert system in place, since it could effectively reduce the former to the latter.

indolering 9y ago

This is a constant issue: what is the safest course of action? You start by patching your shit first, then push it upstream, and then slowly broaden the disclosure circle. Large software vendors (RedHat, IBM, etc) and infrastructure operators (Amazon, Cloudflare, etc) get advanced notice. Only then is it distributed to the public. This is the de-facto route for closed-source software, but Linus doesn't mark all security patches as such [0]. There are a lot of unpatched systems out there and Linus doesn't have the time to parse the exact ramifications of every security bug. That being said, it's pretty clear that we need to invest in more robust software development methods. [0]: http://yarchive.net/comp/linux/security_bugs.html http://yarchive.net/comp/linux/security_bugs.html