I migrated a monorepo including C++, Kotlin, Java, TypeScript and Python to Bazel. It's no small feat, and the DX varies widely across languages and platforms, but it's absolutely worth it. `bazel test //...` from a fresh clone builds & tests everything including gRPC/protobuf code generation, custom code generation, downloading packages, toolchains and linters, dependencies between langs, test suites with coverage across multiple languages.
Integration testing is a breeze through data dependencies. The reproducibility guarantees means we can reference container image SHAs in our Terraform and if the image didn't change the deploy is a no-op.
Bazel is an outstanding build system that handily solves a lot of practical problems in software engineering. Not just "at scale". Practical problems at any scale.
This is the ideal situation. Google already lacks control over all the Chromium forks, like Brave, Opera, Edge and ungoogled-chromium. They accept upstream patches voluntarily, and they can and do reject anything they disagree with. The shadier Google gets the more forks will reject upstream and instead share patches among themselves.
As long as Chromium is open source I don't see what there is to worry about. We literally have the code.
There's a lot to be gained by standardizing on Chromium as well. New features, improvements and optimizations only have to be implemented once instead of thrice, and developers only have to deal with bugs in one implementation instead of the union of bugs in all three.
This is fine; but still it hurts me to think that an open protocol of HTTP[S] and friends is effectively accessed by a single client at core. Yeah it's wrapped with different toppings by different vendors, but deep inside it's one client.
We're going from a world where we had IE, Google, Firefox and Safari as independent projects, we're going towards one with just one.
How is Windows any better? Last I checked installing things in Windows was still a matter of downloading random .exes from the Internet and running them as administrator, so all bets are off.
And there's no sandboxing at runtime either, everything has permission to do whatever the user can do.
I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.
Once programs are running on the machine with the ability to put things on-screen and read keyboard input, this is a very hard problem without hardware-level SAK-like mechanisms which AFAIK no consumer devices include today.
The updated mnt reform [0] has some potential for this kind of facility with a keyboard-embedded display connected to a standalone EC and a dedicated button on the keyboard for notifying the EC without the host's involvement. This should enable an actual SAK-like mechanism, where the EC takes over the keyboard for security-sensitive actions like password entry:
> The keyboard not only works as a USB HID device, but it also has a direct UART
> cable connection to the system controller on the motherboard. By pressing the
> circle key, you can interact directly with the system controller, bypassing
> the main SoC. To give you visual feedback for this interaction, we added a
> tiny 128 x 32 pixel OLED on top of the keyboard. From here, you can check
> charger and battery cell status/health without any operating system support on
> the main SoC (even while you’re still installing an OS). The keyboard OLED and
> direct interaction mechanism has more potential future uses, like a password
> manager/wallet or notification display.
It's a non-trivial problem even with hardware assistance, without any it seems impossible.
> I find it hard to believe that any contemporary operating system can robustly prevent a locally executing program from tricking the average desktop user into entering the administrator password equivalent to TFA's /tmp/sudo example, not on today's average computer.
Qubes OS can. Though it's not for the average users.
It's more that it makes said sudo much less effective. You still can get tricked inside the VM or a canny enough attacker will find a bypass for VM security.
It is a somewhat higher bar though.
The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent, website ID (login, address, credit card) and data theft, phishing and scams.
None of which is prevented by Qubes.
Evil maid attacks are frustrated though if you install its extra security features.
However, it is wise to remember that security is as strong as the weakest link, so do use it if you're an admin or dev.
> The point is moot, as the most destructive attacks are ransomware, which this limits but does not prevent
Qubes OS assumes (promotes and helps with) that you do not open random links inside your banking or important VM. You can even open links automatically in a disposable VM upon a mouse click. It should help here I guess.
> bypass for VM security
VT-d virtualization was broken only once by a software attack. An it was done by the Qubes founder.
Unfortunately in reality Windows doesn’t do much better. For instance the author likes to harp on about the insecurity of X11 while on Windows GUI programs have rather similar levels of access to each other, including to APIs that have impossible to fix buffer overflows that stem from their 80s style design.
Yes there is a (semi) Secure Attention Key but it isn’t required in many cases such as while requesting consent for elevation and you can set it to required but it comes with a warning that that breaks important things (and it does).
Which is a little weird, but cases where you'd want `isset` to treat variables intentionally set to null the same as variables that are entirely undeclared are considerably more frequent (just ran into one yesterday!) than cases where you'd need to carefully distinguish them.
An "Any type" is optional typing if you don't need to downcast it in order to use it, like the "any" type in TypeScript and Flow.
If the "Any" type is just a top type but you have to downcast it to use it, like in Kotlin, then it's not considered optional typing, since you still have to talk about types ;).
