Alternative Phone Line? You want the bootstrapping problem?

For me, Nix(OS) solved most of the problems:

* Getting a dev env with `nix-shell -E '(import <nixpkgs> {}).somePackage'` where I can edit the source and compile it with the various `runPhase` commands[1]. Yes, a bit cumbersome, but it works and it is the same for all packages.

* Integrating the resulting patch into the package manager using overrides[2]. Sure, applying the patch may break at some point, but I am more comfortable reviewing that by hand than rely on an agent that does it for me.

[1]: https://wiki.nixos.org/wiki/Nixpkgs/Create_and_debug_package... [2]: https://wiki.nixos.org/wiki/Overlays#Adding_patches

Before openjdk did move to github, they made sure they had a solution for those problems:

* Contributors without github accounts * Moving away from github (when needed) * No vendor lock-in for github stuff.

I personally think, this is a good idea - a lot of work, but may be worth it in the long run.

The problem is not that the array is mutable, but that the size of the array may differ for different strings. (In fact, it usually* does differ if the string length is different).

This makes it impossible to flatten - as the VM needs to know the total size when creating the memory layout for a class...

* (with a small exception: if the strings use different coders, one can be twice as long and the backing arrays would still have the same size)

Indeed. At this point you’d need to bring the size of the string into the type system (C++ Templates we meet again!) but then you look at a solution worse than the problem…

Such hacks will slowly stop working (without explicitly allowing it from the command line.)

In this example, it would throw an IllegalAccessException, because java.base doesn't open java.lang.

Doesn’t field.setAccessible(true) already throw on a modern version?

Exactly.

You can make it not throw by adding `--add-opens java.base/java.lang=ALL-UNNAMED` or similar to the command line, but breaking things like this is becoming harder.

I changed the sudo settings to not require a password.

Now an application on my computer can obtain root without user interaction.

Where is my CVE?

Same. There are so many things you could mess up without root from my account anyway. My account isn't a locked down one. You could alias sudo to a keylogger, for instance, and then do whatever as root the next time I sudo something.

So the password check really has no point. Typing sudo is still a lightweight sanity check, otherwise I may as well just log in as root.

By some logic:

* If they want to tell someone personally what to do or not to do, is some form of employment.

* If it is not paid, it can be considered slavery.

* It is usually possible to quit jobs.

Systemd (part of many major linux distributions) has for example machine-id[1], readable by anyone on the machine under /etc/machine-id.

[1]: https://www.freedesktop.org/software/systemd/man/latest/mach...

Unlike the Microsoft equivalent (?), nothing prevents you from scrambling it or outright chmodding to 700 to protect it from prying eyes.

I go further and bubblewrap software that I don't fully trust like Steam on my gaming machine. I simply don't expose /etc at all in most cases. The Linux security model is actually quite weak against potentially invasive software running in a main user account. For example /home is also completely exposed to programs such as games and anti-cheat software.

Yep, and firefox ships it to it's servers.

Sarcastic view: Doesn't matter - the EU wont listen, then pull a surprised pikachu and make laws to force googles play integrity to attest that other devices are genuine, because obviously, the problem is google, not stupid design decisions made while creating the app.

I think EU is warming up to the possibility that relying on US tech is has strategic consequences.

You can do GET & POST requests without preflight.

The logic behind this is: It was possible to do this before the introduction of those APIs anyway - but you could not read the response.

You could send a GET request by, for example, embedding an image. And you could send a POST request by submitting a form - even if the form did only consist of hidden elements.

Those are called "simple requests": https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

It is expected from web application that they can correctly handle those requests, even when they were sent from a different origin (for example, blocking them by using a CSRF token).

It was however not expected that existing web applications could handle non-simple requests - as the ability to do so was restricted either to command line tools or required other user interaction/configuration. This is where the preflight request comes in - send an OPTIONS to check if the other side is okay with that kind of request.

But what CORS do is: It can make the response available to the requesting script - the request did already happen if it didn't require a preflight.