cesarb

> What else would you use to power the configuration gui frontend?

Perl?

> What remains to be seen is which polling stations remained open and which did not.

You can check it yourself, the output and log files for each ballot box are already available. I can see that mine opened and closed at the expected time.

Or even Whatsapp, which people already have installed on their phone. No need to go to the store to install anything.

A scammer managed to convince a relative to share their screen during a Whatsapp video call. Luckly, said relative didn't use banking apps on the phone, the bank rejected as suspicious the transaction on the computer which would have sent money to the scammer, and the relative asked me for help before going to the ATM to unblock the account (I then contacted the bank and had them fully block the account as a precaution, and told my relative to go to the bank branch the next day to change the passwords and unblock the account).

Or the adb escape hatch. IIRC, their adb equivalent is limited to having a small number of apps installed at the same time, needs each app to be periodically reinstalled at short intervals (IIRC, one week), and you need to have your expensive Apple laptop with you for that reinstall.

Even with Android becoming much more closed, it's still more open than Apple.

> But the Go version is as well old news,

> actually it was one of the first stories about eMudhra appearing on the HN homepage yesterday.

I feel like I'm going crazy, something which happened (checks clock again to be sure) yesterday (actually two days ago I think, so much has happened that it all blurs together) is being considered old news!

It's not just IoT devices. It's also a very very long tail of programs which for some reason have their own copy of the CA certificates list, either because they don't trust the system's one, want to work identically on all platforms, have a severe case of not-invented-here, or all three at the same time (looking at you, Java...)

> I wonder how 3&4 avoided it :)

Probably the same way log4j 1.x avoided log4shell: the vulnerable code was introduced on a later release.

> Why would you want to access hosts via ssh over TOR?

When you're behind a restrictive firewall which blocks anything other than HTTP/HTTPS (like at an Internet café), or when there's some upstream routing issue making reaching the server directly impossible from your location (these can be a pain to diagnose).

Or perhaps it's simply your default: you proxy everything through Tor, and need a reason to not go through it.

Once again, this shows the strength of mutual authentication (ssh user key authentication, or HTTPS client certificates): even if the client accepts the forged server key from a MITM server, the real server won't accept the client key exchange (since it, at least in the SSH protocol, is bound to the connection). For the three things the attacker did here:

1. It can't steal your password, since the private key never leaves your client;

2. It can observe each command you type, but it can't open a connection to the real server to know how it would respond to your commands;

3. It can't open any connection to the real server (it will fail authentication), so it can't do anything to the real server.

If you really like passwords, there are ways to configure sshd to require both a client key and a password, in that order.

> If you lose it report to the same people (service desk).

THIS is the reason it worked great for your use case. You have a stopgap for the worst case.

You also have a limited, well-known, and mandated set of compatible software and hardware. And you don't have to worry about attestation preventing you from using any future hardware or software, because you have control over any attestation whitelists.

The scenario people worry about is not "passkeys being mandated by your company to access company webapps on company-provided devices, with easy access to in-person passkey resets". The scenario people worry about is passkeys making them lose access to third-party sites on their own devices.

> Cookies do solve a valid problem on the web, that being "How do we maintain 'state' from one page request to the next in a stateless protocol like HTTP(s)?"

Don't you people remember how it was done back when web browsers didn't have cookies, or could be configured to reject or ask for each cookie? The server software automatically added a PHPSESSID parameter to every link, containing the session identifier.

> if (x > 0) {…}. But what if you entered the body when x <= 0?

> if (false) {…}. But what if you execute the body?

> These are “impossible”. What happens when the impossible occurs is “undefined”.

By the way, that's exactly what happens with Spectre and its class of ghostly vulnerabilities! The processor speculatively executes these "impossible" paths, and discards the result once it detects they couldn't happen; but there are ways to "leak" information from that irreal world through side-effects like cache lines being discarded.

> If your entire program is inside unsafe, then Rust is actually worse than C as far as UB is concerned. On the other hand, no one writes Rust like that, and Rust restricts all UB to unsafe blocks.

Nitpicking: it's not the unsafe blocks themselves, but a few language features which are only allowed inside unsafe blocks. Language features which are allowed outside unsafe blocks work identically within unsafe blocks, and gain no extra UB just by being inside an unsafe block.

> If I wrote some code, I expect it to be present in the binary. I don't just write code to be removed by the compiler.

It's very common to write code in templates or inline functions expecting the compiler to remove it if it's not relevant on the calling site. That's part of what makes "zero cost abstractions" have zero cost at runtime.

For instance, I have a SIMD routine with extra code to process the tail (leftover elements smaller than the native vector size). When the compiler can prove that the size of the input will always be a multiple of the vector size (which is very common for my use cases), it will completely remove that tail handling code.