wolletd

Didn't really take long for replacements like https://ruffle.rs/ to emerge, though.

Also DocJade: https://www.youtube.com/watch?v=6Kvi4JPUsak

Especially for Linux, not everything is a desktop system. I have Debian installations running on embedded machines in the ten thousands.

Besides our custom kernel modules and business applications, Debian has everything these systems need and more.

I find it way cooler to use Debian on embedded systems rather than some buildroot, because it's a widely available and reproducible environment and debugging and development tools are an "apt install" away.

After realizing that I'd have to recompile dropbear myself to disable SHA-1, I also thought about that approach.

I'll figure it out. I'm currently planning the update to 23.05, anyway.

Neat. Adding three lines to my sshd_config makes lines go green.

Unfortunately, Dropbear doesn't appear to support any Encrypt-then-MAC algorithms, so I can't get my swarm of OpenWRT routers all green.

First you complain that people are asking for more free stuff, then you complain that they are asking in the wrong place?

Whats your point? Aren't people allowed to discuss stuff other people share with them on the internet?

I keep SSH on Port 22. After years, I'm still amazed about the operational model of these attacking hosts.

They are completely dumb. I haven't kept record, but I have the feeling that some IPs in my fail2ban list are practically in there for month or even years now.

I assume they are just sweeping the whole IPv4 range? No state, no cache. Either they successfully attack a host or they go to the next IP. Repeat 2^32 times, start again.

I'm not sure where I wanted to go with this comment. Is it _that cheap_ to constantly sweep the IPv4 range or is it _that profitable_ to do it once you have a successful attack?

Just friday I've had a discussion with a colleague about filenames.

We do a lot of computer vision and in his project, each processed object is assigned a UUID and he wanted to save images to files for each one.

So we took some time to go over various timestamp formats to be embedded into the filename to make the files sort chronologically. UUIDv7 is just spot-on solving our problem. In this use case, there are no real security considerations.

Apparently, humanity is damned to repeat it's mistakes over and over again.

"100 years should be enough" is what led us to a mountain of Y2K issues, because when would a two digit year ever be ambigious?

But I guess it's a psychological issue. Unless you're a megalomaniac, it's just natural to assume that your decisions won't matter much outside of your life and lifetime. And in that case, 100 years totally is enough because I probably won't live that long. And even more, in a lot of cases, it's also the correct assumption and the project won't live longer than a few years.

So, thinking about it, unless you are developing a novel standard or something that you want the world to adopt, 100 years probably IS fine. Unfortunately, KSUID wants to be a novel standard, so there's an issue.

I once had UUID collisions in Linux Boot IDs when we started developing our own embedded systems at my company.

Found them because systemd-journald isn't very happy when Boot IDs repeat and (apparently, then) stops showing earlier boots once it hits a repeating boot ID. And I wanted to see an earlier boot. Then I started logging the Boot ID in a textfile myself and it took less than 10 reboots to have duplicate Boot IDs.

Long story short, some weeks earlier, I "optimized" the Kernel config for that system and some config flags that didn't sound like something I'd need. As it turns out, an ARCH_ZYNQ target apparently also needs ARCH_VEXPRESS set. Otherwise it works absolutely fine, but with a broken RNG that you will notice weeks later.

That was a valuable "don't take down a fence until you know the reason why it was put up" lesson. Don't unset kernel config flags until you know why they are set.

Aside from breaking RNGs, I've never experienced any UUID collisions either.

Oh, I didn't want to critique Anti-cheat for existing and not properly working (yet) in Proton.

It's software that tries to validate the environment the game is running in and is suddenly confronted with "wait, thats not a Windows system at all". And as you already argued, just ditching Anti-cheat is not an option.

So they either ignore Linux/Proton altogether or have to start actually implementing anti-cheat for a Linux/Proton environment. Even if they go with the second option (as e.g. EAC is, iirc), it simply takes time to implement.

According to ProtonDB, you just launch it: https://www.protondb.com/app/268910

I haven't had a Windows for Gaming in 10 years. The first seven years of that, I haven't played many games. However, CS:GO, Factorio, Civilization and Stardew Valley, among others, all had native Linux support and I wasn't bored.

Then the Steam Deck and Proton came. I ticked a box in Steam settings to not restrict "Steam Play" to verified games, installed a Windows game and started it. It just worked. When Cyberpunk 2077 came out, Proton was updated in time and I launched Cyberpunk 2077, a demanding modern game, in my Linux Steam Client as if it was nothing special.

It's three years later and I'm still thrilled. You bascially don't have to care anymore. I still take a look into ProtonDB before buying a game, but I can't remember the last time it wasn't working (excluding Anti Cheat-Stuff for Multiplayer, but even that is being worked on).

Asio has no coroutine implementation and C++20 Coros are stackless. So, to build fibers with asio, you need boost::coroutine for stackful coros.

On the python requirements: I've always been satisfied with Bash implementations of ACME. I use dehydrated from the very beginning (when it was still called letsencrypt.sh) and lately started using acme.sh.

> and then usually SSH back into the system.

I'm wondering, is Bash/Shell a DSL?

You can do anything with it because it allows launching other programs, but I'd say it was designed specifically for the domain of launching other programs and building data pipelines with their in- and outputs.

Because the goal of WebAuthn is to not depend on any companies infrastructure.

And there's work being done in that direction. Apple supports passkeys from third-party password managers, 1Password has a Passkey beta and KeePassXC has a pull request working on passkey support. [0]

That independence is a design goal of passkeys, because they want to replace passwords and passwords are independent by their nature.

[0]: https://github.com/keepassxreboot/keepassxc/pull/8825

To clarify, biometrics are only used for local authentication against the platform authenticator. An attacker still needs the authenticators private data, too. The authentication against the service is using public key crypto.

Also, you should be able to use a platform authenticator with a PIN.

I've written my bachelors thesis (mostly) with Markdown and Pandoc. You can just insert TeX commands in your Markdown and pandoc will recognize and pass them. It's really neat.

I don't think I would have wanted XML documents as sources. I felt like Markdown was a successful step away from any XML-inspired tag formats. Most books don't have a complex hierarchy. They just have paragraphs and titles.

JetBrains also has a excellent Vim Mode plugin that provides most features I love Vim for.

From my experience, it's possible to just do

  ssh host 'ls "folder name"'

and practically ignore the `command [arguments]` split in SSHs synopsis. It's all passed to a shell and parsed again, anyway.

Well, because my local instance of <WebApp> says, <Feature> isn't available unless I use HTTPS.

Also, HTTPS with a public CA just works on most systems, whereas IPsec requires Client configuration. It's still easier to roll out than switching from IPv4.

For personal or experimental things, I may use a local CA, but getting certificates for the internal subdomains of my company is trivial when you already got a public domain on a Server that's capable of using DNS-01 challenges.

Enabling HTTPS is just way easier than actually ensuring you can trust your local network. Many real-life middle-class companies start out with just having a network and not thinking about security at all. Some companies may even have untrusted internal networks by choice by allowing BYOD.

On the other hand, I'm not sure whether I would confirm active research work on apparently rather capable combat AIs right now, if I were some USAF official.

I guess the URL path in the Nginx log would be URL-encoded and have a %20 instead of a space. And otherwise, it would actually also a problem of that text based log format that uses spaces as field delimiters itself.

Anyway: When I can "build up from the command line", then apparently whatever I'm building up can be easily and intuitively done in the command line. So, stuffing it into a bash script is fast and easy and should be easy to understand as well.

I just have real-world applications for small scripts that aren't much bigger than those "cute little bash examples". When you work with embedded systems, you do a lot of repeatable stuff via SSH. I once ported an Installer to Python and now I hate it because it has so much unhelpful noise between the actual relevant commands being executed.

Yes, Bash has it's issues and requires some discipline, but so do most other languages.

We made a short-term decision to develop a new project in Rust only three months ago.

As we build vending machines and such things, our products usually contain multiple processors that communicate over various connections and there's a lot of interaction with real-world, physical things. Also, as there are a lot of microcontrollers involved, C and C++ are the dominant languages in our development.

So, a lot of our development time actually goes into solving the general unpredictiveness of the real world and humans interacting with actual machines.

Rust enables us to focus on solving those problems without getting held up by stupid memory issues. In our case, iterating over new software versions often is slow because it may involve restarting a big machine and doing actual user interaction with it – the time Rust takes before compiling is easily saved for us.

From my point of view, I'm not actively making it harder, I just don't make it as simple.

My development process usually starts in the terminal, as I am a terminal user and do iterative development there as well as tinkering with system interfaces.

A CLI is the natural first product of my development. Building a web interface is additional work. Also, it's been a decade since I have written any reasonable web frontend.

Granted, it's not a real TUI with curses and stuff, but I like to do some eye-candy with escape sequences. Because I am the most frequent user of my tools and I always like seeing something I deliberately made look good. :)

I have systems that have no web server and don't need one and adding one would add complexity and potential security risks to the system. Administration is only done via SSH.

There are just situations where the question goes the other way around: Is there any need for _more_ than a command line interface? No. Anyone competent enough to do anything meaningful on that server is also capable of doing it via command line.

I have a WireGuard VPN with about 250 devices, most of them POS machines in the wild. I adopted WireGuard for our first machines about half a year before the 1.0 release, so there weren't much tools yet.

I piggybacked onto the original configuration file format and built myself https://github.com/WolleTD/wg-setup, which helps me validating the correctness and uniqueness of new entries, hacks names into the entries and even updates an internal DNS zone.

I really don't have to care much for key rotation, though. As most of the devices are out of our control anyway, they aren't allowed to connect to anything inside the VPN. It's just for us to connect to them.

I'm also not sure why C++ is listed as exception. In practice, modern C++ is all about avoiding manual memory management. Since C++11 at least, possibly longer.

Yeah, you still can do manual memory management, but thats by accident because it's a compiled language. You don't get manual memory management by accident when designing an interperted language because you would have to interpret it explicitly.

This article just reads like it's from 2006.