PaX

Another thing to keep in mind is that imperialism also has the effect of driving down wages in the imperial core since the capitalist can pay their workers less if the price of basic, essential commodities can be decreased by super-exploitation in the imperial periphery. This is a major reason why real wages in the US have been stagnant for a while, for example. So this would have a counterbalancing effect on how much a first-world worker would need to pay proportionally to their income for a case of soda if the process of imperialism were ended.

In addition to the other answers, you might consider using getline() if you're on a POSIX-compliant system. It can automatically allocate a buffer for you.

Thanks for deleting your post. I hope our two communities can live and share in peace. There are certainly some hexbears over here who have been too antagonistic as well as some people here who seem to want to stir things up.

:blahaj-heart: (we have no such emoji on our instance but maybe you do lol)

Or maybe terminal emulation needs to be brought up to speed with modern computing. New terminal specs and all that.

Yeah, I agree. I should have been more clear lol. See my other comment.

Sorry, I should have been more clear. I agree with you. I'm not talking about text-based interfaces and commands. I just mean the way Unix/POSIX handles "terminals" (devices that accept streams of characters according to a protocol established in the 70s) is an antiquated way of handling simple plain text streams. It made sense back then when there was a need to send commands to dumb terminals in-band with the plaintext but this doesn't really make sense these days when your "terminal" is actually just a program pretending to be a dumb terminal running inside a window. When was the last time you used job control instead of opening another window?

Satire or not, it's still correct lol. Terminals and terminal emulation need to be destroyed. Modern systems with graphics and windowing systems are not VT100s and that's a good thing.

Well Linux is using rdrand in place of the fTPM one so .. from firmware to hardware.

That depends on your distribution's setting of the CONFIG_RANDOM_TRUST_CPU compile-time configuration option and the random.trust_cpu sysctl setting. I'm not sure what the major distributions are doing with that at the moment.

Then again even if you generate random numbers using pure software, is your CPU or firmware FOSS and without bugs (cough .. Debian OpenSSL maintainers, cough ..)? If not, and you assume you can't trust the firmware and hardware - all your random numbers are belong to us.

Like you said, it is impossible to be completely safe. But using proprietary cryptographic hardware/firmware, the inner workings of which are known only to Intel, introduces a lot of risk. Especially when we know the NSA spends hundreds of millions of dollars on bribing companies to introduce backdoors into their products. At least when it's an open source cryptographic library they have to go to great lengths to create subtle bugs or broken algorithms that no one notices.

Our CPUs are certainly backdoored too, beyond RDRAND. But it's way more complicated to compromise any arbitrary cryptographic algorithm running on the CPU with a backdoor than making a flawed hardware RNG. Any individual operation making up a cryptographic algorithm can be verified to have executed properly according to the specification of the instruction set. It would be very obvious, for example, if XORing two 0s produced a 1, that something is very wrong. So a backdoor like this would have to only activate in very specific circumstances and it would be very obvious, limiting its use to specific targets. But a black box that produces random numbers is very, very difficult to verify.

Ultimately, the real solution is the dissolution of the American security state and the computer monopolies.

If I'm fucked, they're fucked.

Not if they're the only ones who know about the backdoors.

Edit: I started writing that before your edit about the "Ken Thompson hack". An element of any good backdoor would include obfuscation of its existence, of course. The issue is it is impossible to predict every possible permutation of operations that would result in discovery of the backdoor and account for them. Maybe if you had a sentient AI dynamically rewriting its own code... anyway, backdoors in tooling like compilers is very concerning. But I'm not too concerned about a Ken Thompson type attack there just because of how widely they're used, how many different environments they run in, and how scrutinized the outputted code is.

👁 Imagine using any commercial firmware/hardware RNGs.

No, by running a relay or exit node you are opting in to routing traffic that could contain CSAM. This is a problem with all anonymous unmoderated distributed systems like Tor. With Freenet, for example, you're even opting in to storing it (pieces of it in encrypted form that can't be accessed without the content hash key).

Privacy is good but so is censorship (moderation). The censorship just needs to be implemented by an accountable group of people that share the same interests of the users. Tor is trying to solve a problem that can only be solved through social struggle with institutions of power.

I like Alpine Linux. You could also try OpenBSD if you want a Unix that just works without as much struggle. NetBSD and FreeBSD are also around and have Linux binary compatibility.