30.12.2025 19:22:13 Dworkin Muller <[email protected]>:
> Alternatively, just set it up as a secret store, like is done with
> terminals.  Not quite as elegant/cool, but perhaps more practical.

In general, you're right. However the big difference (and why I think there's a 
solid use case for a factotum key) is that the machine that runs factotum has 
to be secure. If you have a terminal with its own factotum program, that's 
fine. The program is on a trusted machine. However, if your terminal boots off 
a fs, you have to trust the factotum program on that fs to not steal your keys 
when executed. If you run factotum in a remote session, you have to trust the 
server. If you have a single enclosed factotum key and no way for the host to 
download the secrets directly, then you can use it even on an untrusted machine.

Sure, you still need a way to edit the keys. Maybe a specific mount access 
using an additional secret for editing or something similar could be invented.

In any case, I think for a fully trusted environment you probably don't need a 
factotum key. I think the whole factotum and secstore stuff is built around 
this level of trust (you trust the grid). If you consider a public grid with 
multiple users and people who sign in as guests, I'd prefer to not have my 
secrets uploaded into the memory of a machine that I can't control myself, if 
possible. And people do set up grids like that. That's why I welcome 
experiments into that direction. Not to replace the current status quo, but to 
extend it in a compatible way for different use cases.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ta60752663ff08448-Mce4dd48da0c413713a2dbd66
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Reply via email to