Skip to content

Conversation

@kileyhykawy
Copy link
Contributor

As our organization was looking at what credentials/secrets we would need to expose to generate a system user, we noticed that the stock make-system-user needed both the signing key imported locally as well as have the brand account email/password. Ideally, we want to minimize access to the brand account because it has highly-privileged access to the Brand Store. We only want to provide access to the system-user signing private key and passphrase.

With this pull request, we have added an option to allow generating an auto-import.assert without needing the brand store SSO account.

  • The brand_id comes from the required brand option on the command line; with login, it comes from the account_id of the signed-in account.
  • The sign-key-sha3-384 comes from the SHA3-384 hash of the public part of the key name provided; it comes from the registered key part of the account information of the signed-in account.

One thing that logging in with brand account provides is that it verifies that the brand is correct and the given key is in fact registered to the brand account. In the no-login case, we don't get the verification but then, if that information is not valid, the generating auto-import.assert will not work on a brand device so no harm.

Sorry for the end-of-line whitespace trimming - hopefully it isn't important. I have it set by default on my editor to keep things clean.

…auto-import.

- Use brand passed in as account ID and get SHA3-384 hash from the local key provided.
- Since not logging in, we skip any verification that brand is correct and the given key is associated with brand.
@knitzsche
Copy link
Contributor

Hi Kiley: There is potential harm in the no-login case if the user selects a local key that is not registered to the brand account: the system-user assertion would not work, which could cause delays and other headaches. Would it meet your use case if for the --no-login case the user must be signed into snapcraft as the brand account? If so, then the current scan of local keys via 'snap keys' could be changed to 'snapcraft list-keys' and would fail if the output for the specific key includes 'not registered'. If that is also a problem, I might consider a message to the user clarifying that the specified key must be registered to the brand acount where the user is required to indicate assent.

…eeds to unsupported flag to be able to use the option. Fleshed out the documentation for no login to say that the key must be registered to brand account or bad things will happen.
… released that was still 12 so jumping up another version to 14.
@kileyhykawy
Copy link
Contributor Author

@anonymouse64 , since @knitzsche is probably not handling this repo any more, who can review this PR? Kyle and I talked before about making this no-login option hidden so it was only obvious to those who have looked at the code. By default the option does not appear with --help and you need to use --unsupported to find it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants