Hey! Michal from the engineering team behind here. There are some painful experiences from the journey - async in Django, background processing in Python, scaling agent workflows with growing codebase. Happy to talk!
100% - Apple wouldn’t be so stupid as to move the private host keys to an unencrypted partition when the Secure Enclave is _right there_. No way is the Secure Enclave too slow for this - it’s exactly what it’s designed to do!
As far as I aware you can't actually do 100% of crypto needed for SSH auth inside the SEP itself. Might be I missed something, but I tried to find a way before and there was none. This would obviously be most secure.
What you can do though is use Secure Enclave powered app for storing and managing access to the keys. So basically app like "secretive" run on your normal OS, but isolated and only it can access keys, use them and there no export function even with admin privileges.
AFAIK this will fail if there is a local root exploit on macOS, but still much better than keeping keys in plain text.
You can generate and store your private SSH key in the secure enclave, there's even an SSH agent that does that for you: https://github.com/maxgoedjen/secretive
But that's it.
Anything more complicated is not possible. You can't even upload your existing key into the SE.
AFAIK "secretive" SSH agent is not actually running inside SEP when it using the keys. So when keys are actively used they are exposed in main OS RAM and only protected by macOS security model (so are safe unless there is jailbreak / actual root exploit).
So "secretive" and similar software is not as secure as let's say hardware token.
If I'm wrong please correct me, but when I researched the topic I come to this conclusion.
Ah, I see that Secretive is a victim of feature creep. I think it still can use the SE to store the private key, but it also has more ways to do it.
This is the initial inspiration for Secretive: https://github.com/sekey/sekey - it uses the SE to generate and store the actual private key, so it never leaves the machine. Hence its limitations.
Again - I could be really wrong about Secretive. Sadly their documentation dont make it very clear and I myself don't have enough time to actually to go read the code and figure out how it works exactly.
That TrueNAS ARM fork is great. I've set it up in VMWare Fusion on Mac mini M4 and it runs!
With Thunderbolt 4 M.2 NVMe enclosure, you can plug in M.2 SATA adapter to connect 8 SATA III drives. Little Pico PSU to power the HDDs and it makes a really low powered NAS.
My plan is to give TrueNAS a spin with two drives and if it is stable, move everything into it.
Ten years ago, I worked in a small non-profit development shop that used Github issues for all project management. Checkboxes were used as both subtasks and ACs. Now that I think back, it worked really well. I don't think we even had Slack (we used Google Talk).
It is important to know, that our ruling party is a populist left wing all the time promising one. So whatever might be proposed might not have enough push to be implemented.
We are using Percy [1] for this and are extremely happy with this. Almost zero effort to set up, just some time to get random data out of our tests to have stable visual output.
Just out of curiosity, how is that module tested? It is one new file without a single test. How people know it works and change it knowing it still works?
There isn't a very good automated testing strategy for ansible modules. If you look in the documentation there are examples that should exercise all the code paths, so a future developer can validate it is still working by running it with those examples. So much of the logic of the module requires you to interact with boto that without a substantial mocking of that interface the tests would be effectively worthless.
