imrejonk
imrejonk on Hacker News
> 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!
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.
Posted by
imrejonk on Wednesday December 11, 2024 @03:06AM
from the camras.nl dept.
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.
Ah, so it wasn’t some SEO trick (see your sibling comment) after all :)
Thanks for the fun and informative blog post!
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?
Posted by
imrejonk on Friday August 23, 2024 @02:08PM
from the faa.gov dept.
> 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…
Posted by
imrejonk on Sunday April 02, 2023 @11:26AM
from the imrejonk.nl dept.
"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...
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