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.

Power Network Tycoon: https://store.steampowered.com/app/2429930/Power_Network_Tyc...

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.

> The order of amendments is just the order in which the constitution has been amended. It's meaningless to talk about "first amendments" in other countries.

Also, at least here in Brazil, the way the constitution is amended is by patching it. For instance, our constitutional amendment number 115 (https://www.planalto.gov.br/ccivil_03/constituicao/emendas/e...) patches article 5 of the constitution to add protection of personal data as a right. But we wouldn't talk about "amendment 115", we would instead talk about "article 5 item LXXIX of the constitution"; that is, what matters is the patched text, not the law that patched it.

I don't know about other countries, but it wouldn't surprise me if they take a similar approach.

> I've watched it shift from "Only update if we can prove we are impacted" to "Update everything immediately just in case".

> [...] a much more cautious approach has become common.

I'd argue that this is a less cautious approach, not more. It takes time to carefully evaluate, review, and test each change.

> I better make sure that all future versions of it also always return an even number of characters, just in case some moron decided to bank their application's functionality on that?

Oh yes, this does happen. There's even a name for that: ossification (https://en.wikipedia.org/wiki/Protocol_ossification). You can't change your API/protocol, because "some moron" started depending on implementation details.

It's easy to say "your application deserves to break" from an ivory tower, but it's often not easy or viable to fix it (for instance, it might have different owners, it might no longer be maintained, it might be more expensive to change, etc). And the change which broke that application was not in it; the blame naturally goes to what was changed last.

If you read the whole book, you know it didn't quite work...

> In what world is a square not a rectangle?

In the world of object-oriented programming: https://en.wikipedia.org/wiki/Liskov_substitution_principle#...

> How else would I change the temperature remotely if it didn‘t?

...why do you need to change the fridge temperature remotely?

I can imagine one good use: plotting graphs of inner temperature, configured set point, motor on/off status, door open/closed status, and power consumption. But that use case does not require having control of the fridge compressor...

It's hard to explain without going into a few low-level details of PCI Express, but let me try.

Most PCI devices expose some memory and/or I/O ports to the CPU. That memory (or I/O ports) is mapped to somewhere in the address space visible to the CPU. Besides the memory and I/O ports, all PCI devices also expose a separate set of configuration registers; among these registers, there are the Base Address Registers (BARs), which configure where the memory or I/O ports is mapped.

Here's an example output from "lspci -vv" for a GPU:

        Region 0: Memory at 7c00000000 (64-bit, prefetchable) [size=8G]
        Region 2: Memory at 7e00000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at f000 [size=256]
        Region 5: Memory at fca00000 (32-bit, non-prefetchable) [size=1M]
        Expansion ROM at fcb00000 [disabled] [size=128K]

Note that regions 0 and 2 are above the 4GB addressable by old 32-bit CPUs. To be compatible with these old CPUs, this card and many others like it allow the firmware (and/or the operating system) to choose not only where the memory is mapped, but also its size. We can see this in the same "lspci -vv" output for this GPU:

        Capabilities: [200 v1] Physical Resizable BAR
                BAR 0: current size: 8GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB
                BAR 2: current size: 256MB, supported: 2MB 4MB 8MB 16MB 32MB 64MB 128MB 256MB

Older systems which do not understand this extended capability will still treat these regions as fixed size, probably with the first size in this list (256MB for region 0, 2MB for region 2). Newer systems can tell the device to "resize" the BAR to a bigger size, which obviously needs the first region to be placed above the 4GB barrier since it's too big.

Why is this useful? This particular GPU has 8GB of VRAM; it's quite obvious that region 0 is a direct view into that VRAM. When using the maximum BAR size, the CPU can directly read and write anywhere into the VRAM; when using a smaller BAR, the CPU can only see a small window into the VRAM, and has to use less direct methods to access it.

(As an aside: go right now and do a "sudo lspci -vv" on your computer, if you see a Resizable BAR capability which isn't using the maximum size, you can probably gain a bit more speed for free by going into the BIOS and enabling "Resizable BAR" and/or "Above 4G decoding". If you can't find these options, well, AFAIU that's what this project is all about..)

> Yes, /dev/(u)random is supposed to do that, [...] getrandom() is often times suggested, but alas isn’t a standardized function, i.e. it’s not part of the POSIX specification.

Is /dev/random or /dev/urandom part of the POSIX specification?

Length extension attacks are not an issue for git, because every object has two fields in its header, which is prepended to the object before hashing: the object type and the length in bytes.

> Good, are there (m)any other plans to ditch the slow files and use proper database?

The filesystem is a proper database, just not a relational one.

Linus focused heavily on performance when he wrote git; he used the filesystem because, as the main Linux kernel maintainer, he knew that the Linux VFS and filesystems were fast enough for these use cases.

(It's the use cases that have changed; it was not expected back then to have more than a few hundred refs in a single repository.)

> Are all of these unsuitable [0]? [...] I looked it up and people had problems selling to Brazil [1] but there are various listings that offer to ship.

Do these phones have ANATEL certification? Because if they don't, they will be rejected by customs. It's not simply a case of the item being held until you pay a 60% import tax.

> GrapheneOS's goal is privacy for the world and that's achieved through secure devices.

Perfect is the enemy of good. What's better for privacy, an old but inexpensive smartphone running Android 11, or the same smartphone running an up-to-date third-party rebuild of Android 16 or newer with as many privacy-improving bells and whistles as the hardware can support?

> Soon there will be two different phone brands which you can install it on.

...will they be available in my country (Brazil)? I don't think I've ever seen a Google Pixel phone in person.

> Heh, in the security world, this shows how your traditional metal key is "something you know" (like a password) because it can be copied and many people can know it at once!

If you have a photo of a traditional metal key, you can duplicate it. AFAIK, there's also a numeric representation of the height of each position on the key; if you know that number, you can duplicate the key. A traditional metal key is more like a password than most people think.

> Same as traditional physical keys, you don't have a single key, you have multiple ones [...]

I have multiple identical ones.

> [...] and can go to the local locksmith and get another one in minutes.

Can I go to the digital equivalent of a locksmith (like a backup software) and duplicate my passkey? Can I do that with only my passkey in hand (without having to do anything to the corresponding lock, or having to contact its issuer), like I recently did with a physical key?