your pubring.* permissions look too open, they should only be rw for the user …
Even after fixing the permissions the same error pops.
("gpg: WARNING: unsafe ownership on homedir '/home/zap2x/.snap/gnupg'\ngpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
what about the toplevel dir ?
$ ls -ld ~/.snap/
drwx------ 2 ogra ogra 4096 Sep 18 2016 /home/ogra/.snap/
drwx------ 3 zap2x zap2x 4096 feb 12 10:49 /home/zap2x/.snap/
same as yours…
Adding more info on gpg:
$ gpg --homedir /home/zap2x/.snap/gnupg --list-keys
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
/home/zap2x/.snap/gnupg/pubring.kbx
-----------------------------------
pub rsa4096 2016-01-01 [SCEA]
<identifier>
uid [ultimate] uc20-key
Also the key uc20-key is registered:
curl -s https://api.snapcraft.io/api/v1/snaps/assertions/account-key/<keyid> | jq
{
"headers": {
"account-id": "<AccountID>",
"authority-id": "canonical",
"body-length": "717",
"name": "uc20-key",
"public-key-sha3-384": "<id>",
"sign-key-sha3-384": "<id>",
"since": "2021-02-12T09:56:29Z",
"type": "account-key"
},
"body": "<Large ID>"
}
and the key is the same you used to sign the model assertion ?
Yeah, exactly the same.
Both sign-key-sha384
in the file .model
and the key passed in -k
parameter, are the same…
Could this be related to the fact that make-system-user does not have the ~/.snap/gnupg/
well configured? I saw that you can pass a --home-dir <path>
to the gpg
binary but nothing like that when calling make-system-user
…
make-system-user should just be calling out to snap sign -k ...
, which is what is using ~/.snap/gnupg/
.
Can you show the produced system user assertion?
Hello, this is the produced system assertion. I still dont get why can not be signed…
edit: there is a little typo on the pastebin command, but in reality there is a space between mypass
and -k
param.
The produced assertion you linked to does not actually contain the system-user assertion, it just includes the account and account-key assertions, so this explains why it is not used at all. We will need to figure out why it’s not signing that part, but also make-system-user should be updated to not produce anything in this scenario, it seems to be ignoring errors unfortunately
I’ll take a look calling out to snap sign
in shell instead.
Hey guys, new things around here. I was able to create a system user assertion (apparently using sudo one time breaks things, now my user-assertion is technically signed). Unfortunately, while using a virtual machine i am not able to create the user in the system even tho I have the auto-import.assert
on the root of an usb attached. Also I dont recieve any feedback of the system finding an assert
file…
Do you have any clue of what might be happening? AFAIK the uc20 should be able to create a new user at any time, isn’t it?
Nvm, got that last issue solved. I missunderstood something from the documentation.
When executing
$ sudo make-system-user --brand bJzr2XzZg6Qv6Z53dsjhg20975Skjs \ --model mymodel --key my-key-name --username <new-user-name> \ --email <new-user-email-address> --password <new-user-password>
I wrote: --model pcimage.model
instead of the model name inside the file.
A dumb mistake, but i am sure it happened to someone else too.