Live data from Hacker News

CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

lists.thekelleys.org.uk

51–60 of 256 posts

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#51
post #40

Earlier quoted context omitted.

There are two different kinds of updates. One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now . These are the updates stable gets. The other is changes and additions. They're both more likely to break things and less important to move into…

You definitely need different channels for high priority fixes and normal releases, stable and testing releases and all that. But two years is impractical and Debian gets a ton of friction over it. Web browsers and maybe one or two other packages are able to carve out exceptions, because those packages are big enough for the rules to bend and no one can argue with a straight face that Debian is going to somehow muste…

> ...upstream package maintainers who are expected to deal with bug reports from ancient versions...

They are not expected to deal with this. This is the responsibility of the Debian package maintainer.

If you (as an upstream) licensed your software in a manner that allows Debian to do what it does, and they do this to serve their users who actually want that, you are wrong to then complain about it.

If you don't want this, don't license your software like that, and Debian and their users will use some other software instead.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#52
post #45

Earlier quoted context omitted.

That's a bit shameless, indeed. dnsmasq has served me well for like an eternity in multiple setups for different use cases. As all software it has bugs. And once located those get fixed. Its author is also easy to communicate with. Why should I switch over to something way less proven? I'm quite sure your software also has bugs, many still not located. Maybe because it's less popular/ less well known nobody cares to…

"All software has bugs" is the most meaningless statement ever. It is just used for bonding with fellow bug writers who sit at a virtual campfire and muse about inevitabilities. Demonstrably some software has fewer bugs, and its authors are often hated, especially if they are a lone author like Bernstein. Because it must not happen! Projects with useless churn and many bug reports are more popular because only activi…

"All software has bugs" so "be wary of the one trying to say they haven't had any in 3 years" not so "I guess all are equal". For extremely low security bug rates either the scope is extremely narrow, the claim is dubious, or the project is a massive effort which the community talks about directly in posts rather than plugs (e.g. curl).

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#53

Maybe this is the kick in the ass Debian needs to upgrade the embarrassingly ancient dnsmasq in "stable" because while I can't think of any new features, the latest versions contain many non-CVE bug fixes. But I doubt it, they will lazily backport these patches to create some frankenstein one-off version and be done with it. Before anyone says "tHaT's wHaT sTaBlE iS fOr": they have literally shipped straight-up broke…

> ...they have literally shipped straight-up broken packages before, because fixing it would somehow make it not "stable"

Irrelevant strawman, since you're not accusing the dnsmasq package in Debian stable of being straight-up broken.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#55
post #40

Earlier quoted context omitted.

There are two different kinds of updates. One is security updates and bug fixes. These need to fix the problem with the smallest change to minimize the amount of possible breakage, because the code is already vulnerable/broken in production and needs to be updated right now . These are the updates stable gets. The other is changes and additions. They're both more likely to break things and less important to move into…

You definitely need different channels for high priority fixes and normal releases, stable and testing releases and all that. But two years is impractical and Debian gets a ton of friction over it. Web browsers and maybe one or two other packages are able to carve out exceptions, because those packages are big enough for the rules to bend and no one can argue with a straight face that Debian is going to somehow muste…

Good grief, you are not forced to uae Debian! Please leave the only stable distro alone, and just use one more to your style.

I assure you, enormous sums of people prefer Debian the way it is. I do not, ever, want "new stuff" in stable. I have better things to do than fight daily change in a distro, it's beyond a waste of time and just silly.

If you want new things, leave stable alone, and just run Debian testing! It updates all the time, and is still more stable than most other distros.

Debian is the way it is on purpose, it is not a mistake, not left over reasoning, and nothing you said seems relevant in this regard.

For example, there is no better way than backporting, when it comes to maintaining compatibility. And that's what many people want.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#56

The AI bug report tsunami is not in all projects. As the top comment notes, MaraDNS didn't have any. I assume djbdns and tinydns didn't either, otherwise they'd shout it from the rooftops. I never understood why some projects get extremely popular and others don't. I also suspect by now that the reports by tools that are "too dangerous to release" scan all projects but selectively only contact those with issues, so t…

> The AI bug report tsunami is not in all projects.

It's in popular projects.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#57
post #30

Earlier quoted context omitted.

No, that's exactly the thing to complain about. That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. Not to mention, you think the C of today is bad? Have you looked at old C? And the disadvantage is that backporting is manual, resource intensive, and prone to error - and the p…

> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. That's not what it's about. What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it…

> You don't want that as an automatic update because it will break in production for anyone who is actually using it

The problem with this take is that it’s stuck in the early 2000’s, where all servers are pets to be cared for and lovingly updated in place.

It’s also circular: you have the same problem with the current model if you don’t have a test environment. And if you do have a test environment, releases can be tested and validated at a much higher cadence.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#58
post #30

Earlier quoted context omitted.

> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. That's not what it's about. What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it…

You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that... So when you do update and get that GSSAPI change, it comes with two years worth of other updates - and tracking that down mixed in with everything else is going to be all kinds of fun. And if you're two years out of the loop and it turns out upstream bro…

> You're going to have to update production at some point, and delaying it to once every 2 years is just deferred maintenance. And you know what they say about that...

Doing terrible work every 2 years is better than doing it every day?

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#59
post #30

Earlier quoted context omitted.

> That whole model dates to before automated testing was even really a thing, and no one knew how to do QA; your QA was all the people willing to run your code and report bugs, and that took time. That's not what it's about. What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. You don't want that as an automatic update because it…

> What it's about is, newer versions change things. A newer version of OpenSSH disables GSSAPI by default when an older version had it enabled. Debian patches defaults in OpenSSH code so it behaves differently than upstream. They shouldn't legally be allowed to call it OpenSSH, let alone lecture people about it. Let them call their fork DebSSH, like they have to do with "IceWeasel" and all the other nonsense they mir…

It's called open source. People are allowed to compile it as they wish. That's part of the positive, and doing so doesn't mean anything is broken.

Re: CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

#60
post #45

Earlier quoted context omitted.

"All software has bugs" is the most meaningless statement ever. It is just used for bonding with fellow bug writers who sit at a virtual campfire and muse about inevitabilities. Demonstrably some software has fewer bugs, and its authors are often hated, especially if they are a lone author like Bernstein. Because it must not happen! Projects with useless churn and many bug reports are more popular because only activi…

"All software has bugs" so "be wary of the one trying to say they haven't had any in 3 years" not so "I guess all are equal". For extremely low security bug rates either the scope is extremely narrow, the claim is dubious, or the project is a massive effort which the community talks about directly in posts rather than plugs (e.g. curl).

DJB, with Qmail and DjbDNS (as well as Publicfile, which didn’t catch on in an era of CGI scripts), showed that one could have (mostly) security bug free software without the scope being “extremely narrow”, and without the claim being “dubious”.

It’s not normal for software to be so poorly written, one doubts the claim that a security bug hasn’t been found in over three years. If one thinks the claim of no security bugs of consequence in three years is dubious, feel free to do a security audit of MaraDNS (or DjbDNS, which I also will take responsibility for even though my software is, if you will, a “competitor” to DjbDNS), and report any bugs you find.

Speaking of DJB, DjbDNS has had a few security bugs over the years (but not that many), but I’m maintaining a fork of DjbDNS with all of the security bugs I know about fixed:

https://github.com/samboy/ndjbdns

I am saying all this as someone who has had significant enough issues with DJB’s software, I ended up writing my own DNS server so I didn’t have to use his server (I might not had done so if DjbDNS was public domain in 2001, but oh well).

(As a matter of etiquette, it’s a little rude to claim someone is saying something “dubious”, especially when the claim is backed up with solid evidence [multiple audits didn’t find anything of significance in the last year, as I documented above], unless you have solid evidence the claim is dubious, e.g. a significant security hole more recent than three years old)

Post reply on HN