Using one for couple of months so far. I need it once a month for a couple of hours or so, but it saves me 3x more time, so money well spent. But wow, at 3x less price tag it a deal!
By the way, what can you tell about Roon as an active user? It costs as much as Qobuz, but it’s your responsibility to fill up your library and provide infrastructure - which is weird. Sure, it sponsors musicbrainz and lastfm for metadata and puts some nice UI, gets buddies in HiFi manufacturers, but what else?..
I’m very surprised that Roon does UNPnP for own port, potentially exposing home network through some zerodays. For that money it has to do reverse tunneling or something like that.
Local library playback has always been a challenge when the size is in tens of thousands. But after that the main challenge is headless networked playback from separate subnets - e.g. one great stereo system controlled by multiple members of the household from multiple devices
Genuine question, are there open source solutions to this? I use HomePods so audio can be controlled from any device and any rooms audio can be synced to another. Would love something more open.
there are so many great tools in the baseline core infrastructure. and there's so much NIH syndrome still.
appreciation and OS aside, systemd-creds relays long-lived creds into long-lived processes, and author's AI slop attempts at short-lived/on-demand injections. Apparently, author's AI slop gets a lot of iterations, but has not much of external scrutiny yet.
How funny it may sound, but I was recently researching around for these kinds of tools for the same exact purposes.
Where I got stuck was at the Secure Enclave storing biometric-crypted payloads in the keychain, but couldn’t get it to work without Apple Developer subscription for code signing, otherwise these features wouldn’t work. And nobody with an Apple Developer subscription wants to sign someone else’s code, obviously. I really wonder why Apple itself, or any other reputable company, didn’t publish an utility like this already - it’s also a trust issue, when you run code like this.
The issue is that /usr/sbin/security invocations can be obscured to read from keychain, but require password typing every time, which is annoying. And lazy people can just hit “trust” by mistake. And then it’s just another clear text, but more annoying to reach.
Even though, it may be possible to show a touchID prompt in two other scenarios:
- encrypting payload with a key stored in the enclave - then it becomes closer to SOPS approach. Age plugin for sops also supports using private keys on yubikey, by the way. But SOPS UX feels clunky.
- just calling the APIs to show touchID as part of the application logic, like all modern password managers do. But then you really have to trust the password manager or the tool that does it, because touchID doesn’t equal security in this case.
Some password managers support CLI, SDK, and Terraform providers for working with their secrets, but that requires an IPC enabled, potentially increasing the risk for the other secrets stored in the same password manager.
> potentially increasing the risk for the other secrets stored in the same password manager.
As pointed to me by a friend, this is one reason not to give in to the convenience of the secrets manager you already use.
My use case for fnox with keepassdb back-end was partially validated but as I mentioned elsewhere in the thread, having to set master password in an env var is a bit of snag for the workflow.
keepass is great, because it doesn't require any service to operate - it's just a file. technically, you are responsible for backing it up, but more centralized options possible. I used it for 4 years pre-touchID era in a corporate setting and it worked great. For a single device. UX was very "open source", but hey - it's a free software with other focus in mind.
i know other people partitioning their secrets into multiple keepassx vault files, so the argument about using the same password manager can be interpreted differently.
reply