imrejonk

> My server does verify the certificate of the target MX

But how do you know if the target MX is correct, and not controlled by an attacker? You can't really know for sure unless the receiver has secured their domain name with DNSSEC or published an MTA-STS policy.

My former colleague Marco Davids from SIDN Labs (the R&D department at the .nl TLD operator) did an experiment in 2021 where he actively disabled IPv4 support on all components in his test network, even disabling the complete IPv4 stack in the FreeBSD kernel (not possible on Linux, at least not at the time). So far, his test is the only thing I know of that came close to an authentic simulation of an IPv6-only world.

https://www.sidnlabs.nl/en/news-and-blogs/can-we-do-without-...

I was thinking about the same thing. Such a classic!

I fully expected the smoke alarm CW key to work by picking up smoke signals: https://sites.google.com/site/oh6dccw/smoke-alarm-cw-key

Reminds me of the Pixelflut LED display. The hacker camp SHA2017 had one above a bar, 36C3 had one as well. Their traffic peaked at 4 Gbit/s and 30 Gbit/s respectively.

https://hackaday.com/2020/08/01/playing-the-pixelflut/

And: they have a crash cart (keyboard, mouse and display) and battery backup built-in. An old laptop is perfect for starting a homelab. The only major downside I can think of, and as another commenter already mentioned, is the limited storage (RAID) options.

While I agree with you that an error message like this should not be taken as a personal attack, it still causes a horrible user experience. It’s not like the developers of these systems had no choice in the wording of these errors: they picked the insensitive computer-says-no option, while they could have went with an apologetic “Sorry, our system does not support special characters” instead.

A system not supporting non-latin characters in personal names is pitiful, but a system telling the user that they have an invalid name is outright insulting.

Why stop there? Probes traverse the whole TCP/IP stack, best to stop them early at layer 1: https://www.bit.nl/news/115/88/Cut-here-to-activate-firewall...

Ah, so it wasn’t some SEO trick (see your sibling comment) after all :)

Thanks for the fun and informative blog post!

Sharp!

I find it slightly ironic that a blog that’s educating (and entertaining) us on time and timezones does not itself mention when its blogposts were published, at least on mobile.

This one appears to have been published in the summer of 2024.

This adds `set -o pipefail` to POSIX sh, which causes a whole pipeline to fail (non-zero exit code) if one or more of the commands in the pipeline fail.

I wonder if this "all GNU/Linux systems" is correct, or if we'll see some nuance added in a couple of hours/days. I'd be a monstrous patch day if this RCE really impacts all GNU/Linux systems.

Care to share the source of this hint?

This was featured on this week’s Airplane Geeks podcast (starting at 0:02:00): http://www.airplanegeeks.com/2024/08/21/812-artificial-intel...

> The worst is when a request starts out simple — I help them fix one hallucination — but then that customer wants to build more complex logic, and somehow I’ve set the expectation that I will provide unlimited free support forever. I’ve gotten a number of angry messages from customers who essentially want me to build their whole app for free.

Annoying, but a good way to weed out bad customers. Life’s too short to deal with people who feel this entitled.

A larger battery and more solar panels doesn’t seem to be an option for the authors:

> The modern stack doesn't really work for us, it doesn't apply to the limitations that we have on the boat. We have 180 watts of solar. We just spent the whole summer with two 6-volt batteries, which is very small. When you're going down that route, at every turn people are telling to just put more solar panels, or to buy more batteries. That is such a modern way of solving your problem. In reality, technology like this(especially high-tech) rarely solves problems. It creates a lot of other problems, which on a sailboat is very immediate. Putting more solar would mean more windage, more chance of things flying off and cutting our limbs. More batteries would mean the boat would be heavier, it would stop us from being able to run away from storms.

https://100r.co/site/weathering_software_winter.html

Reminded me of the Internet Beer Tap by Techinc, a hacker space in Amsterdam:

> Once upon a time, a lovely piece of Purple networking hardware got pushed into the obscene job of having to function in tapping the internet for law-enforcement purposes. After liberating the quarter-million-dollar-networking-switch, we have taken it upon ourselves to offer it a worthy retirement plan that allows it to re-socialize itself. The Internet Beer Tap became a fact.

https://wiki.techinc.nl/Internet_Beer_Tap

They provide a good reason for completely removing the DSA code:

> We are also likely to start exploring a post-quantum signature algorithm soon and are mindful of the overall size and complexity of the key/signature code.

Vulnerabilities like heartbleed and Log4Shell is what you get when you have limited developer capacity but insist on endlessly keeping legacy code around.

Could that later standard be NSEC3? It’s like the easily walkable NSEC, but with hashed names and special flags for opting out of delegation security features. The 3 appears to stand for the number of people that fully understand how it works…

"What is this in-ter-net?" asked Piglet. "I have no clue." said Pooh. "But I heard they have honeypots, so we better take a look."

The first thing that comes to mind is ENTSO-E's Power Flow Tool. It had a number of simulations of Europe's power grid with typical demand scenario's, prompting you to take care of grid balancing when a power line suddenly failed during peak load.

Unfortunately I just discovered that they removed it from their website somewhere this year. I've asked them to restore it. For now you can play with this copy in the Internet Archive: https://web.archive.org/web/20220124003709/https://www.entso...

The author of the Go diff library has just released it under the MIT license: https://github.com/seletskiy/godiff/commit/865648740d705a24a...

I really like the message composer in Claws Mail. It has proper line wrapping, meaning that you don’t get strange line breaks in quoted text when replying inline. I’ve never got that to work on Evolution and Thunderbird (which I haven’t used in a while, so maybe this has been fixed already).

> At the time when Debian 11 was about to be released, PHP 8.0 was 10 months old yet Debian's 11 was released with PHP 7.4. That makes PHP 7.4 the standard in Debian stable for at least 3 years after its release. But PHP 7.4 only gets upstream support until 28 Nov 2021 and security support is permanently ended at 28 Nov 2022, which is seven month from now. This means that unless Debian has some really good C developers, no one can provide any security fixes for PHP 7.4. Not only that, no one outside of Debian will be monitoring problems with PHP 7.4 because everyone else will long since have upgraded to PHP 8.

It’s a case of bad timing. Packages for PHP 8 were uploaded shortly before the bullseye freeze, which didn’t sit well with the release managers. See bug #976811 [1]. The maintainer also mentions in that bug thread that Microsoft will provide security fixes for PHP 7.4 after the EOL date.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811

It does not appear to be enabled in the kernel by default:

> While the module can be found in most major distributions, it must be loaded in order to be exploited.

> Today’s email protocols use the STARTTLS protocol for encryption; it is laughably easy to do a protocol downgrade attack that turns off the encryption.

This can be solved with DANE, which is based on DNSSEC. When properly configured, the sending mailserver will force the use of STARTTLS with a trusted certificate. The STARTTLS+DANE combination has been a mandatory standard for governmental organizations in the Netherlands since 2016.

Cool project! Too bad there's not much detail in these maps. The Dutch land registry and national mapping agency maintains a website with highly detailed, historical maps of the Netherlands that go back to 1815: https://topotijdreis.nl/