Thanks! I'm actually familiar with retrowin32. I even contributed a few commits to get Solitaire running in it. But Rust has a steep learning curve for me.
Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice "feature"?
> [...] doesn't that mean the implementation is just... finished?
I don't think that it _necessarily_ means that, e.g. all projects that haven't had a release since 2019 aren't finished? Probably most of them are simply abandoned?
On the other hand, a finished implementation is certainly a _possible_ explanation for why there have been no releases.
In this specific case, there are a handful of open bugs on their issue tracker. So that would indicate that the project isn't finished.
"Isn't 10-15% faster compression, and 5-10% faster decompression, a very nice «feature»?"
Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays. Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me.
> Although much code can be optimized to get it to run 10-15% faster, if that comes at the expense of legibility then such "feature" get rejected nowadays.
Makes sense, and I'd probably make the same call if I was a maintainer and someone submitted a patch which increased performance at the cost of maintainability...
> Translating an existing codebase into a language that makes things more difficult¹ and (because of that) has (and most likely will have) fewer engineers willing to working in it looks very much akin to applying legibility-affecting optimizations to me.
Here I have to personally disagree. I think that Rust is easier than both C and C++. Especially when coming into an already existing project.
The chance of me contributing to a Rust project is higher than to a C project, because I feel more comfortable in knowing that my code is "correct". It's also easier to match the "style" since most Rust projects follow the same structures and patterns, whereas in C it can vary wildly.
E.g. I contributed my first feature to Valkey (Redis fork, C codebase) recently, and figuring out how the tests worked took me quite some time. In fact, in the end I couldn't figure out how to run a specific test so I just ran all tests and grepped the output for my test name. But the tests take tens of minutes to run so this was sub-optimal. On the other hand, 99% of all Rust projects use `cargo test`, and to run a single test I can just click the play button in my editor (Zed) that shows up next to the test (or `cargo test "testname"`).
(with this said, I think that Valkey is a really well structured code base! Great work on their part)
Anyhow, this is just to illustrate my experience. I'm sure that for someone more used to C or C++ they would be more productive in that. And I could go on for ages on all the features that make me miss Rust every day at work when I have to work in other languages, especially algebraic data types!
(not the one you asked, but can chime in with some info)
This was a long time ago, but the way I did it was to use XcodeGen (1) and a simple Makefile. I have an example repo here (2) but it was before Swift Package Manager (using Carthage instead). If I remember correctly XcodeGen has support for Swift Package Manager now.
On top of that I was coding in VS Code at the time, and just ran `make run` in the terminal pane when I wanted to run the app.
Now, with SwiftUI, I'm not sure how it would be to not use Xcode. But personally, I've never really vibed with Xcode, and very much prefer using Zed...
If anyone is interesting in an example, here's mine:
> Based on your GitHub activity, you seem to have a penchant for projects that blend modern development practices with a touch of nostalgia. You're drawn to high-performance tools written in Rust, like 'bat' and 'fd', which reimagine classic Unix utilities. Your interest in 'fnm' and 'mise' suggests you're always looking for ways to streamline your development environment. The 'embassy' and 'retrowin32' projects hint at a fascination with both cutting-edge embedded systems and retro computing. You also appear to have a soft spot for quirky, niche projects like 'Factorio-SAT' and 'pokeyellow', which combine programming with gaming in unexpected ways.
and the roast:
> Oh, look at you, Mr. 'I-follow-940-repos-but-can't-decide-on-a-single-language-to-master'! You're like a kid in a candy store, but instead of candy, it's programming languages, and instead of a store, it's GitHub. I bet you start more side projects than you finish cups of coffee. Your GitHub profile is basically a museum of 'I'll get back to this someday' exhibits. You probably dream in Rust, wake up to Node.js, and spend your lunch breaks reverse-engineering Game Boy ROMs. I'm surprised you haven't tried to rewrite your coffee maker's firmware in WebAssembly yet. But hey, at least when the apocalypse comes, you'll be the go-to person for debugging Factorio optimizations on a Windows 95 machine using a command-line interface. Stay weird, you beautiful, overenthusiastic nerd!
> From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end):
They use the exploit to get dropped into a root shell, and then asks the TPM to unlock the disk for them, which it promptly does.
Technically, but really the fault lies in the OS for providing an exploitable prompt that doesn't break the chain of custody of the boot process on failure.
Ubuntu developer here. I don't think that's fair. The OS, as shipped today, isn't designed with this threat model in mind. It's correct to say that for TPM-based LUKS unlock to be safe, the initramfs must not allow the user to take control of it. But that's a new requirement introduced when the user modified their system to configure TPM-based LUKS unlock. This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!
That's not to say that an improvement can't be made as we move towards a future where TPM+LUKS might be the norm - just that you can't retrospectively claim fault on an OS that doesn't claim to support that.
> This isn't the responsibility of an OS that doesn't ship with that support, and in fact, prior to TPMs, it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!
And it still is perfectly reasonable behavior. Any distribution that decides (perhaps as a consequence of this) that on any boot process abnormality the default response is to enter an immediate reboot loop would be called crazy.
> it was perfectly reasonable to allow the user to take control of the initramfs prior to LUKS unlock!
It’s still looks perfectly reasonable, just PCR should be fed with some value before that, maybe a hash of initramfs file? It seems to be reasonable as at this moment the state of the operating system differs from the one properly booted, which seems to fit the idea of secure boot.
This way it would be possible to still unlock LUKS with a pass phrase but not access TPM keys locked for configuration when initramfs shell is not running.
I still don't understand why people believe that you can have any expectation in these ludicrous scenarios.
Like, you are dropping a general purpose computer into the middle of Russia, expect to be able to command it remotely to do anything, even remotely update it and reboot it; and at the same time never bother to come check it up in person or even have minimum chassis intrussion detection. Do people really expect this to work just by adding some TPM craziness?
The article is just connecting a keyboard sniffer/simulator but it would have been as easy to do anything to the network traffic, SSD, motherboard/CPU JTAGs, RTC, etc.
Well, it's sorta possible. Just not with the TPM, and not in general purpose computing applications.
Games consoles are super locked down, to prevent piracy, and some modern consoles have gone years without a successful hack, despite being in the physical possession of the attacker. The iphone's activation lock is extremely hard to bypass, and even cops and border guards struggle to extract users' data.
Simply buy your PC from your operating system vendor directly, and forego options like being able to replace components and being able to install your own software, allowing the memory and PCI bus to be encrypted. Add some cloud backup features so the device can wipe itself at the drop of a hat without losing your data. After that, just have your OS vendor produce perfect code with no exploits, and you're secure!
I did. It says 'From here it’s easy to manually use the TPM to unlock the disk with the Clevis tooling and mount the root volume for hacking (it takes a few tries sometimes, but it gets there in the end)'
However screenshot says 'Unsealing failing'. Yet Ubuntu-lv is mounted.
I don't follow how Luks password was guessed for it.
There wasn't a password necessary, the TPM was an unlocking mechanism.
Secure Boot with TPM-backed disk encryption works off of a series of numbered hashes. The idea of TPM based FDE is that the machine will use Secure Boot to boot only a software chain that the end-user trusts not to contain authentication bypasses. In Secure Boot, the EFI firmware provides hashes of each stage in the boot chain to the TPM, and the TPM only unlocks the full-disk encryption key (really the key encryption key, since the TPM isn't fast enough to actually decrypt the disk) slot if each stage / configuration is valid.
This issue breaks that chain. In some sense it's an illustration of this system being silly conceptually, but it is a real issue IMO.
No LUKS password was guessed, clevis-disk-unlock command in the last screenshot used the TPM to provide a key to a LUKS keyslot for getting at the actual decryption key to decrypt the disk. The TPM should have had information about the boot state to be able to refuse to provide the key, but didn't.
103 Early Hints is "experimental technology" (according to MDN) and isn't supported by Safari and Firefox. In Chrome it's only supported when using HTTP/2 or later (Firefox Nightly support it for HTTP/1).
It's still a bit of a weird format, because it has an offset and a zone. What does your example mean, given that it has an offset of +1 hour, on a date when in the zone you've specified, the offset is +0?
For more fun, what does 2024-11-23T08:52:02+00:00[Europe/London] mean now, and what does it mean if the UK switches to a +1 hour offset all year round in 2023?
If i understand the proposal correctly, the actual moment in time represented by one of these is given by the time and the offset. The bit in square brackets is just metadata. The spec says:
> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.
e.g. `Box::leak(Box::new( ... ))`