Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CERT is releasing six CVEs for serious security vulnerabilities in dnsmasq

lists.thekelleys.org.uk

Post reply on HN
Print view View original

161–170 of 256 posts

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

#161

Post by PunchyHamster »

koverstreet wrote: post #22
zrm wrote: post #12

Earlier quoted context omitted.

They're not going to put a newer version in stable. The way stable gets newer versions of things is that you get the newer version into testing and then every two years testing becomes stable and stable becomes oldstable, at which point the newer version from testing becomes the version in stable. The thing to complain about is if the version in testing is ancient.

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. Not to mention, you think the C of today is bad? Have you looked at old C

The automatically tested Debian release is called Debian Testing. And it is stable enough.

Debian Stable is basically "we target particular release with our dependencies instead of requiring customer to update entire system together with our software". That model works just fine as long as you don't go too far back.

> On top of that, the backport model heavily discourages the kinds of refactorings and architectural cleanups that would address bugs systemically and encourage a whack-a-mole approach - because in the backport model, people want fixes they can backport. And then things just get worse and worse.

Narrator: It turned out things were not getting worse, they were just fine.

> We'd all be a lot better off if certain projects took some of the enthusiasm with which they throw outrageous engineering time at backports, and spent at least some of that on automated testing and converting to Rust.

That project is RedHat, not Debian, they backport entire features back to old versions (together with bugs!)

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

#162

Post by PunchyHamster »

koverstreet wrote: post #33
zrm wrote: 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…

Get thru the issues once every 2 years is entirely fine. Farther than that and you get problems. We do that for ~500 systems of very varied use. I wouldn't want to do it yearly (or dread on rolling release) but I also wouldn't want to do it any less often coz of issues you mentioned.

> And if you're two years out of the loop and it turns out upstream broke something fundamental, and you're just now finding out about it while they've moved on and maybe continued with a redesign, that's also going to be a fun conversation.

Having that sprung on you because you decided to run everything on latest is worse.

"Oh we have CVE, we now need to uproot everything because new version that fixes it also changed shit"

With release every year or two you can *plan* for it. You are not forced into it as with "rolling" releases because with rolling you NEED to take in new features together with bugfixes, but with Debian-like release cycle you can do it system by system when new version comes up and the "old" one still gets security fixes so you're not instantly screwed.

> So if the backport model is expensive and error prone, and it exists to support something that maybe wasn't such a good idea in the first place... well, you may want something, but that doesn't make it smart.

It exists in that format because people are running businesses bigger than "a man with a webpage deployed off master every few days"

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

#163

Post by PunchyHamster »

washingupliquid wrote: post #92
zrm wrote: 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…

> One is security updates and bug fixes. That's where you're wrong. They're not one and the same. Debian stable often defers non-security bug fixes for up to two years by playing this game. I'm not interested in new features unless they make things actually work. Debian stable time and again favors broken over new. Broken kernels, broken packages. At least they're stable in their brokenness. Hence my complaint.

Haven't noticed much broken.

But I have noticed far more broken in distro that DOES backport features, RHEL/Centos. So many that we migrated away from it, when they backported a driver bug into centos 5 and then did the same backport of a bug for centos 6.

Also rebuilding package is trivial if you don't agree with what should and should not go into stable version

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

#164

Post by PunchyHamster »

washingupliquid wrote: post #96
koverstreet wrote: post #61

Earlier quoted context omitted.

If package maintainers were always fine upstanding package maintainers as you imagine them to be I wouldn't be complaining, but I have in fact had Debian ship my software and screw it up and gotten a flood of bug reports, so... :) I think you need to chill out. Relicensing the way you suggest would be _quite_ the hostile act, and I'm not going to that either. But I am an engineer, so of course I'm going to talk about…

[flagged]

BSD devs have head too far up their arse to fix anything wrong with their distro

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

#165

Post by PunchyHamster »

vel0city wrote: post #62
toast0 wrote: post #58

Earlier quoted context omitted.

> 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?

Personally I'd rather have a manageable stream of little bad things consistently over time rather than suddenly having a mountain of bad things one day.

Debian Testing works entirely fine for that use case. Each package gets ~2 weeks of shakeout in Unstable before it gets there so there is chance most of the teething issues with new version is handled already, and is more than most rolling distros do

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

#166

Post by PunchyHamster »

SoftTalker wrote: post #49

Never liked using dnsmasq. Always felt like too much in one tool. A local caching resolver, dhcp server, and tftp/pxe boot setup were always things I preferred to configure separately.

That's kinda the point. It is "i run a small router" app in a box.

DHCP and DNS are connected, PXE requires DHCP entries, so to do a simple setup you'd need to glue together at least 3 daemons otherwise, all with different config syntax

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

#167

Post by PunchyHamster »

koyote wrote: post #103
SoftTalker wrote: post #49

Never liked using dnsmasq. Always felt like too much in one tool. A local caching resolver, dhcp server, and tftp/pxe boot setup were always things I preferred to configure separately.

I agree, it also goes against the Linux "way of doing things". For example, Opnsense uses the dhcp portions of dnsmasq only (and unbound for the dns parts) which just feels 'wrong'.

dhcpd is probably more quirky than dnsmasq, all software from ISC is kinda ass (also technically dhcpd is end of life)

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

#168

Post by PunchyHamster »

yjftsjthsd-h wrote: post #11
ck2 wrote: post #10

if machine-learning can find all these holes why can't machine-learning write a product from scratch that is flawless?

Who said it can't? https://news.ycombinator.com/item?id=47759709 appears to be a nearly flawless (per spec) zip implementation.

[flagged]

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

#169

Post by kokada »

Orygin wrote: post #160
turpentine wrote: post #155

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=47943499 - 44 CVEs trying to replace coreutils with a greenfield rust rewrite. There's no free lunch.

How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p....

Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).

Post reply on HN