-
-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for a more flexible GPG auth model #376
Comments
I love it. I think it would do the job entirely and fits all use cases. |
I think it's a great idea as well. I vote yes. |
Key installation doc here |
And integrated into ash_history here |
@flammit & @osresearch : This was merged and can be closed, no? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently there is a single gpg keyring that is used to determine which keys are trusted in a Heads installation. Unfortunately, there are now different ways
gpgv
is used ininit
:In the future, there will probably be additional uses:
It seems like maintaining a few key rings would be sufficient to cover a wide range of cases:
/.gnupg/user/
: valid sigs to do anything in Heads/.gnupg/admin/
: additional valid sigs to access a recovery shell to wipe/re-provision hardware (but not access user's key material)/.gnupg/distro/
: additional valid sigs to ISO bootOn a standard reproducible build, Heads would have empty
user
andadmin
ring, and thedistro
ring would contain whatever standard distro keys are available (e.g. qubes, tails, alpine, etc.). An installer could then usecbfstool
/ #357 to add a public key intoadmin
or necessary public key and private key stubs touser
.@osresearch @tlaurion @zaolin @kakaroto @kylerankin thoughts?
The text was updated successfully, but these errors were encountered: