snapcraft register-key doesn't use U1 SSO login credentials

[Víctor R. Ruiz]

Test case.
- snap create-key <key name>
- snapcraft login (and introduce U1 SSO credentials).
- snapcraft register-key <key name>

Expected result.
- snapcraft is logged and registers the key name.

Actual result.
- snapcraft register-key asks again for U1 SSO credentials.

Tested with snapcraft 2.19

[Leo Arias (elopio)]

I think this is by design. But I will ask Celso or Colin to confirm.

[Sergio Schvezov (sergiusens)]

El 26/10/16 a las 12:10, Leo Arias escribió:
> I think this is by design. But I will ask Celso or Colin to confirm.
>

To solve this we need to pass the macaroon that snapcraft gets onto
snapd as snapd has the lower level logic to actually create the key.

[Colin Watson (cjwatson)]

This is intentional. Registering a key is a security-sensitive operation and requires independent authentication: the macaroon that grants authority to register a key must be fresh (generated in the last five minutes) and it must contain a specific permission that is not a subset of that granted by "snapcraft login". The credentials granted by "snapcraft login" are longer-lived and persist on disk, and we intentionally ensure that there are no persistent credentials that permit registering a new key that an attacker could use to upload snaps on behalf of the user.

I would simply amend the test case to delete the "snapcraft login" step here.

Sergio: That's incorrect. snapd does not require a macaroon here, as it does not communicate with the store.

[Sergio Schvezov (sergiusens)]

El 30 oct. 2016 5:25 PM, "Colin Watson" <email address hidden> escribió:
>
> This is intentional. Registering a key is a security-sensitive
> operation and requires independent authentication: the macaroon that
> grants authority to register a key must be fresh (generated in the last
> five minutes) and it must contain a specific permission that is not a
> subset of that granted by "snapcraft login". The credentials granted by
> "snapcraft login" are longer-lived and persist on disk, and we
> intentionally ensure that there are no persistent credentials that
> permit registering a new key that an attacker could use to upload snaps
> on behalf of the user.
>
> I would simply amend the test case to delete the "snapcraft login" step
> here.
>
> Sergio: That's incorrect. snapd does not require a macaroon here, as it
> does not communicate with the store.

Your comments make sense. I wonder if we should tweak the messaging a bit
and remove the double login request too.

[Colin Watson (cjwatson)]

Is there a document somewhere that recommends running login before register-key? I couldn't find it on snapcraft.io if so.

[Zygmunt Krynicki (zyga)]

I'm closing the snapd side of this task. Please provide additional information if my understanding is incorrect.