Using `` to interpolate command arguments is very clever! What's missing is a discussion on how you do quoting (for example, how to ls a directory with spaces in name)
Anyway, what kills this for me is the need to add await before every command.
> Text scaling doesn't need to replicate zoom. If you use font-relative units like em and rem everywhere that you set a length, everything will scale up the same way as browser zoom.
> Instead, only use font-relative units on things like text, images and icons. You don't need to use it on properties like margin, padding or gap.
> If you do that, there's more room for the content, which is especially important on portrait mobile devices.
So, for margin and padding, one should use px? Or is there a better unit?
Security certifications are one reason. OpenSSL maintains a module for FIPS compliance, which includes an entire boatload of weak and broken algorithms nobody else bothers with.
It is. There are other related issues like at some point RedHat patched back options removed/changed in openSSH 7.0 because
* they upgraded a major release (6.x to 7.x) in "stable" channel of their distro
* their customers ran some ancient stuff that required those options.
We've failed a security audit because our checks just compared OpenSSH version ("if version is above this it doesn't need any change in config") while Red Hat's OpenSSH version was downgraded to earlier version settings/security issues
A number of projects like Firefox and the Linux kernel uses them. It's boring at that point. The generated code is C and assembly can be used like any library, but it has been formally verified.
But, there is ring and rustls too. A number of projects are shifting to it
here is some actual security: encrypted /boot, encrypted everything other than the boot loader (grub in this case)
sign grub with your own keys (some motherboards let you to do so). don't let random things signed by microsoft to boot (it defeats the whole point)
so you have grub in an efi partition, it passes secure boot, loads, and attempts to unlock a luks partition with the user provided passphrase. if it passed secure boot it should increase confidence that you are typing you password into the legit thing
so anyway, after unlocking luks, it locates the kernel and initrd inside it, and boots
the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech
however, this is still better than, at failure, letting anything run
sophisticated attackers will defeat this, but they can also add a variety of attacks at hardware level
I’d much rather have tamper detection. Encryption is great should the device is stolen but it feels like the wrong tool for defending against evil maids. All I’d want is that any time you open the case or touch the cold external ports (ie unbolted) you have to re-authenticate with a master password. I’m happy to use cabled peripherals to achieve this.
Chaining trust from POST to login feels like trying to make a theoretically perfect diamond and titanium bicycle that never wears down or falls apart when all I need is an automated system to tell me when to replace a part that’s about to fail.
Sorry, I wasn’t clear enough. We’re talking about three things here:
(1) Encryption: fast and fantastic, and a must-have for at-rest data protection.
It is vulnerable to password theft though. An attacker might insert evil code between power-on and disk-password-entry. With a locked down BIOS / UEFI, the only way to insert the code is to take the boot drive out of the device, modify it, put it back, and hope no one notices. “Noticing” in this case is done by either:
(2) Trust chaining: verify the signatures of the entire boot process to detect evil code.
(3) Tamper detection: verify the physical integrity of the device.
My point is that (1) is a given, and out of (2) or (3), I’d rather have the latter than deal with the shoddiness of the former
> the reason I don't do it is.. my laptop is buggy. often when I enable secure boot, something periodically gets corrupted (often when the laptop powers off due to low power) and when it gets up, it doesn't verify anything. slightly insane tech
Reminds me of my old Chromebook Pixel I wiped chromeos from. Every time it booted I had to press Ctrl-L (iirc) to continue the boot, any other keypress would reenable secure boot and the only way I knew to recover from that was to reinstall chromeos, which would wipe my linux partition and my files with it. Needless to say, that computer taught me good backup discipline...
Doing secure boot properly is kind of difficult. There are a bunch of TPM measurement registers for various bits and bobs (kernel, initramfs, cmdline, lots more). Using UKIs simplifies it a lot, but it’s not trivial to do right at the moment.
Unix permissions were written at a time where the (multi user) system was protecting itself from the user. Every program ran at the same privileges of the user, because it wasn't a security consideration that maybe the program doesn't do what the user thinks it does. That's why in the list of classic Unix tools there is nothing to sandbox programs or anything like that, it was a non issue
And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model
Anyway I already linked this elsewhere in this thread but in this comment it's a better fit https://xkcd.com/1200/
>And today this is.. not sufficient. What we require today is to run software protected from each other. For quite some time I tried to use Unix permissions for this (one user per application I run), but it's totally unworkable. You need a capabilities model, not an user permission model
Unix permissions remain a fundamental building block of Android's sandbox. Each app runs as its own unix user.
I feel like apparmor is getting there, very, very slowly. Just need every package to come with a declarative profile or fallback to a strict default profile.
I don't understand this criticism. Most agents today are running with no sandboxing at all. Every person has to figure out how they will sandbox each agent (run under bubblewrap? container-use? what about random MCP servers, do they need to be sandboxed separately?) on an ad hoc basis. Most people don't bother with it.
And then you see the recent vulnerabilities in opencode for example. The current model is unsustainable
It would be great if desktop Linux adopted a better security model (maybe inspired by Android). So far we got this https://xkcd.com/1200/ and it's not sufficient
Indeed, pgmq is exactly the Postgres queueing system that you would build from scratch (for update skip locked and all that), except it's already built. Cloud providers should install this extension by default - it's in a really sweet spot for when you don't want or need a separate queue
What about having PDF readers have a restricted mode where it has limited capabilities, with the option to "trust" a PDF to enable potentially dangerous features?
The reason to soft delete is to preserve the deleted data for later use. If you need to not query that data for a significant amount of the system use that 75% soft deletes is a performance problem, then you either need to move the soft deleted data out of the way inside the table (partition) or to another table entirely.
The correct thing to do if your retention policy is causing a performance problem is to sit down and actually decide what the data is truly needed for, and if you can make some transformations/projections to combine only the actual data you really use to a different location so you can discard the rest. That's just data warehousing.
Data warehouse doesn't only mean "cube tables". It also just means "a different location for data we rarely need, stored in a way that is only convenient for the old data needs". It doesn't need to be a different RDBMS or even a different database.
Anyway, what kills this for me is the need to add await before every command.
reply