#52 Feature: Disable automatic GPG imports

[Matthijs Kooijman]

I was trying restoration of backups on another machine and had synced the config to the other machine, excluding the private key. Then running duply, it noticed the sign private key was missing (which is intentional) and tried to import it. Rather than noticing that the private key was not present, it imported the public key and set it to autotrust. This was a bit annoying because of the autotrust bug (I was still running 2.2), but even with that fixed, I think it will try to import the same key on every run.

This made me realize that automatically importing a key and more importantly automatically setting it to ultimate trust, is really not something I want to happen. Setting a key to trusted is something that should be done consciently IMHO. If somehow an incorrect key would find its way into my key backup, this would end up being marked as trusted, making this also a (small) vector for privilege escalation.

For me, I'd probably just want to disable importing of keys completely, and do it manually. A step more complex would be to let duply handle the importing but only when explicitly requested, or only after explicit approval (but this requires the issue in the first paragraph to be fixed, to prevent a prompt on every run to import a key that is not available).

[ede]

I was trying restoration of backups on another machine and had synced the config to the other machine, excluding the private key. Then running duply, it noticed the sign private key was missing (which is intentional) and tried to import it. Rather than noticing that the private key was not present, it imported the public key and set it to autotrust. This was a bit annoying because of the autotrust bug (I was still running 2.2), but even with that fixed, I think it will try to import the same key on every run.

it shouldn't. importing should only happen if a saved key does not exist in your keyring.

This made me realize that automatically importing a key and more importantly automatically setting it to ultimate trust, is really not something I want to happen. Setting a key to trusted is something that should be done consciently IMHO. If somehow an incorrect key would find its way into my key backup, this would end up being marked as trusted, making this also a (small) vector for privilege escalation.

it's getting a bit academic here. if you can't trust the content of your profile, you probably can trust your backup anymore. that's why you should keep a copy of your profile safely somewhere and not just simply copy the latest from the old box ;)

For me, I'd probably just want to disable importing of keys completely, and do it manually. A step more complex would be to let duply handle the importing but only when explicitly requested, or only after explicit approval (but this requires the issue in the first paragraph to be fixed, to prevent a prompt on every run to import a key that is not available).

although i do not generally agree with your conclusions i see no hurt in making it possible to disable ex-/importing keys. default will surely stay status quo though

..ede

[Matthijs Kooijman]

it shouldn't. importing should only happen if a saved key does not exist in your keyring.

Here's what happens:
- Duply considers using the first GPG key id as the sign key, so it needs the private key for that.
- This private key is not available in the keyring, so it tries to import it.
- It imports the public key
- It fails to import the private key, since it is not present (I excluded it while syncing the duply profile to this machine).

So, every time I start duply, it goes through these same steps again.

it's getting a bit academic here. if you can't trust the content of your profile, you probably can trust your backup anymore.

That's certainly true, but that only extends to the backup. When keys are inserted and trusted into my keyring without confirmation, I also can no longer trust my GPG setup, or any GPG-signed incoming email, which is a lot bigger than just not trusting my backups.

default will surely stay status quo though

Yeah, for most people it is probably fine. Though it might still be worthwhile to add a confirmation when importing keys, so people can at least tell when something fishy is going on when duply asks to import a key when it does not make sense.

Another approach, I realized, could be to let duply keep its own, private, keyring and import (and generate) keys into that. It would probably be useful to use keys from both this private and the default keyring (e.g. when decrypting with your personal regular GPG key that is in the default keyring), but I suspect gpg kan access multiple keyrings already.

If you would then have some duply generate-key command to generate a new key in this private keyring and also limit exporting secret keys from this private keyring only, you would maybe also solve #50 in an elegant way: Duply would only export private keys that it auto-generated or imported itself, and any keys manually generated by the user in their default keyring would never leave that default keyring?

[ede]

On 20.07.2020 11:53, Matthijs Kooijman wrote:

it shouldn't. importing should only happen if a saved key does not exist in your keyring.

Here's what happens:
- Duply considers using the first GPG key id as the sign key, so it needs the private key for that.
- This private key is not available in the keyring, so it tries to import it.
- It imports the public key
- It fails to import the private key, since it is not present (I excluded it while syncing the duply profile to this machine).

So, every time I start duply, it goes through these same steps again.

ic, that's because of the invalid secret key file. makes sense now.

it's getting a bit academic here. if you can't trust the content of your profile, you probably can trust your backup anymore.

That's certainly true, but that only extends to the backup. When keys are inserted and trusted into my keyring without confirmation, I also can no longer trust my GPG setup, or any GPG-signed incoming email, which is a lot bigger than just not trusting my backups.

surely it's a convenience functionality, which in turn lessens security in a sense. agreed.

default will surely stay status quo though

Yeah, for most people it is probably fine. Though it might still be worthwhile to add a confirmation when importing keys, so people can at least tell when something fishy is going on when duply asks to import a key when it does not make sense.

that sounds reasonable.

Another approach, I realized, could be to let duply keep its own, private, keyring and import (and generate) keys into that. It would probably be useful to use keys from both this private and the default keyring (e.g. when decrypting with your personal regular GPG key that is in the default keyring), but I suspect gpg kan access multiple keyrings already.

the gpg man pages read as if multiple keyrings are supported since forever. so good idea.

If you would then have some duply generate-key command to generate a new key in this private keyring and also limit exporting secret keys from this private keyring only, you would maybe also solve #50 in an elegant way: Duply would only export private keys that it auto-generated or imported itself, and any keys manually generated by the user in their default keyring would never leave that default keyring?

keeping a keyring within profile-folder/ itself would actually make im/exporting keys redundant, as they would be ready and available all the time. not sure if keyring files are interchangeable between gpg versions though.

..ede

[Matthijs Kooijman]

ic, that's because of the invalid secret key file. makes sense now.

Not invalid, but missing (probably what you meant, but just to prevent misunderstanding). It seems that duply does not check whether the private key backup file is present before deciding to try an import.

[ede]

On 20.07.2020 13:29, Matthijs Kooijman wrote:

ic, that's because of the invalid secret key file. makes sense now.
Not invalid, but missing (probably what you meant, but just to prevent misunderstanding). It seems that duply does not check whether the private key backup file is present before deciding to try an import.

hmm, will have to check that. would be a bug :).. ede

[ede]

sorry for the delay. today i checked and could reproduce it. what i did

1. run a backup against a new keypair
2. rename the exported secret key in profile to *.sav
3. gpg --delete-secret-key it
4. run a duply verify

output is the below. importing the public key, when it is available is obviously wrong. i'll disable that and make the warnings more explanatory.

watch out for the next release.. ede

:~> ./duply_dev/duply_wrap keyimp restore /tmp/keyimp.restore
Start duply v2.2.2, time is 2020-12-27 18:01:06.
Using profile '/home/user/.duply/keyimp'.
Using installed duplicity version 0.7.17, python 2.7.6 (/usr/local/python-2.7.6/bin/python2), gpg 2.0.9 (Home: ~/.gnupg), awk 'GNU Awk 3.1.6', grep 'GNU grep 2.5.2', bash '4.3.30(1)-release (i686-pc-linux-gnu)'.
Import keyfile '/home/user/.duply/keyimp/gpgkey.6B6875B0.pub.asc' to keyring (OK)
Autoset trust of key '6B6875B0' to ultimate (OK)
Signing disabled. First GPG_KEY entry's '6B6875B0' private key is missing.
Checking TEMP_DIR '/tmp' is a folder and writable (OK)
Test - Encrypt to '6B6875B0' (OK)
Test - Decrypt (DISABLED) - No matching secret key available.
Test - Compare (DISABLED) - File not found. Nothing to compare.
Cleanup - Delete '/tmp/duply.14179.1609088466_*'(OK)

--- Start running command RESTORE at 18:01:06.759 ---
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sun Dec 27 17:29:10 2020
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: verschlüsselt mit 2048-Bit ELG Schlüssel, ID 54296424, erzeugt 2011-06-12
"no pass"
gpg: Entschlüsselung fehlgeschlagen: Kein geheimer Schlüssel
===== End GnuPG log =====

18:01:07.469 Task 'RESTORE' failed with exit code '31'.
--- Finished state FAILED 'code 31' at 18:01:07.469 - Runtime 00:00:00.709 ---

[ede]

closing as double pubkey import is adressed already.

for disabling gpg key im/exports refer to https://sourceforge.net/p/ftplicity/feature-requests/50/