Open yellowsquid opened 3 years ago
@yellowsquid strange that there are no more logs available. Do you know where the signing key is located at? It is possible (and quite probable) that rua
doesn't have access to this part of the filesystem: https://github.com/vn971/rua#safety
I wonder how to easily make makepkg
more verbose to explain the reason of the failure.. It doesn't seem to have a --verbose
flag that one could pass. Any ideas?
Signing key is in ~/.gnupg/pubring.kbx
.
GPG has a --verbose
option. I'll try and add it and report my findings.
@yellowsquid maybe some other files in ~/.gnupg
are needed for makepkg signing as well. You can try adding wrap_args+=(--bind-try ~/.gnupg ~/.gnupg)
to ~/.config/rua/wrap_args.d
, which will effectively give makepkg full access to ~
. Or even give the insecure access to everything for testing, wrap_args+=(--bind ~ ~)
, and then shrink it to only the required minimum
GPG has a
--verbose
option. I'll try and add it and report my findings.
I've got a little more output now.
gpg: using pgp trust model
gpg: no default secret key: No secret key
gpg: signing failed: No secret key
It definitely seems that some directories are missing for package signing. In fact, just looking at the man-page for gpg
, you find this option:
--secret-keyring file
This is an obsolete option and ignored. All secret keys are stored in the
‘private-keys-v1.d’ directory below the GnuPG home directory.
Looks like the problem can be resolved with the following:
wrap_args+=(--bind-try ~/.gnupg/private-keys-v1.d ~/.gnupg/private-keys-v1.d)
@yellowsquid it would be nice to solve the problem for other people as well though.
Do you have ideas on how to do that? Alternatives I see so far:
makepkg
and is safe to read the private keys. Maybe it's a bit paranoid, but I'd really like to go security/isolation-firstAny thoughts or ideas are welcome
* always allow access to private GPG keys. This sucks security-wise and I won't really use that, mentioning just to see the alternatives
Personally I think that read-only access is sufficient, behind a command-line flag.
I doubt this will be a common issue if I am the first person to report it. In that case, the majority of people will benefit by never exposing the private keys.
For people who do want to sign packages, the private keys should definitely be read-only. When creating keys, GPG gives plenty of warnings if they're not given a passphrase. This means packages should only be exposed to encrypted, read-only private keys, which the user will explicitly opt-in to.
* split the full build into non-signing part that executes arbitrary build-time code of PKGBUILD, and the signing part which only involves `makepkg` and is safe to read the private keys. Maybe it's a bit paranoid, but I'd really like to go security/isolation-first
You can run makepkg
with the --nosign
flag. Then separately sign the package with gpg
. A problem with this approach is parsing makepkg.conf
to get the user-specified signing key. It might be possible to run makepkg
to only sign the package using the --noxxx
options. I couldn't work out how after playing around for 5-10 minutes though.
@yellowsquid not related to this issue but just a small personal comment: if you want to make those keys read-only, bind them with --ro-bind
or --ro-bind-try
I have
makepkg
configured to sign packages. I expectedrua
to be able to sign packages it builds.Command used:
Output:
This happens when the signing key both does and does not have a passphrase.