A security issue in nginx resolver was identified, which might allow an attacker who is able to forge UDP packets from the DNS server to cause 1-byte memory overwrite, resulting in worker process crash or potential other impact.

That’s the essence of the CVE-2021-23017 that was published on May 25. I patched NGINX Extended few days later for bionic, focal and groovy Ubuntu releases. hirsute will join the builds eventually.

Additionally there was a minor bugfix release for ModSecurity, v1.0.2. It’s now also available in the PPA.

Back in December 2019 I wrote a post about Dynamic Upstreams in NGINX w/ Consul and here’s the summary:

I find combination of Consul for service-discovery and NGINX with basing its upstream configuration on it extremely powerful. As I also mentioned multiple times already – I think Upsync is one of the most elegant solutions for combining these two lovely pieces of technology together. I hope that this article will push you into direction of having less things hardcoded and plenty more dynamic and discoverable.

I still find NGINX with Upsync combination to be one of the cleanest and most elegant solutions to the problem of having upstreams provided dynamically. That said, HAProxy just up the ante by building in support for Consul, quote:

When you register more instances of the same service, HAProxy will fill in these disabled server slots, which lets you scale up or down in many cases without a reload.

And that’s the beauty. The entire control over the backends being in and out is under Consul control and HAProxy just routes through it dynamically. Yet again raises as a viable alternative to a fully-blown HTTP server. Respect.

Recently I wanted to go through the bunch of facts from different parts of the infrastructure I maintain. I’ve been already collecting Ansible facts in Redis to speed things up and then I noticed that they are actually still stored in JSON. I always had a soft spot for SQLite and I toyed with the idea of having Ansible facts in a queryable form. The missing piece? Something to transfer these JSON facts from Redis to SQLite. Let’s script it!

I’ve been following 13.0 starting around the same time last year. It was my coming back to FreeBSD after few years break. I instantly felt at home with it and I also wanted to use all the things “my way”. I customized /etc/make.conf and /etc/src.conf, I switched to git repositories whenever they were available etc. All the fun stuff. FreeBSD behaved on my NUC rock solid all the time – I did bring some rain onto myself (you can’t avoid it when you mess around with bleeding edge), but never to a degree that wouldn’t be recoverable (thank goodness for bectl) this way or another. At some point this year I started preparing for this release and was going more and more towards defaults and eventually I switched back to freebsd-update and portsnap. Being able to do these things without a hitch is a testament of how good of operating system FreeBSD is. Now go try it out!

Jim Salter writes on Ars Technica:

Unfortunately for Netgate, neither its sponsored code nor the week-long sprint by Donenfeld, Dunwoodie, and Evans seem likely to make it into FreeBSD 13.0. Presented with one deeply flawed port and another massively rushed overhaul, the FreeBSD team will most likely disable the WireGuard module entirely for 13.0-RELEASE and revisit for 13.1-RELEASE.

As expected, WireGuard support has been dropped in RC3 of 13.0-RELEASE. What’s even worse of not having WireGuard in is the fact that developers who tried their best to fix everything that was wrong with its implementation received… Bashing from Scott Long. It’s not the first time when Netgate’s CEO is acting like a 5 year old. I’m not linking to his “article” on the Netgate’s blog cause it’s simply not worth anybody’s time.

It is worthwhile though to have a look into this mailing list post by Jason A. Donenfeld (WireGuard’s author). Just to give you some idea:

It makes sense to communicate with your customers about things with your upcoming products if you feel it’s necessary. But threatening that you’re going to highlight “that extreme caution should be taken in any future dealings with you” sounds to me like a threat of some intense slander. And again, attacking security researchers and kernel programmers who took time to rewrite code to make it better before a release deadline… That’s …wow. I wish you would not go on the attack like that.

Wow indeed.