Comment 8 for bug 946988

I believe that I have figured out what is going wrong, at least at a rudimentary level. I'm very unfamiliar with the codebase, so take this with a grain of salt (please).

I injected a bunch of print statements all over, focusing on the stack trace from the error output. This didn't particularly help until I printed the contents of "global.gpg_profile.passphrase" in the body of the validate_encryption_settings function: it was blank. I added another print statement immediately before to ensure that the python process had the proper environment variables (i.e. print(os.environ['PASSPHRASE'])): the passphrase was present in os.environ as expected.

It appears that the main duplicity python script does not try to load global.gpg_profile.passphrase if the backup type is "full" or "inc" (per lines 1313 of bin/duplicity):

    # full/inc only needs a passphrase for symmetric keys
    if not action in ["full", "inc"] or not globals.gpg_profile.recipients:
        # get the passphrase if we need to based on action/options
        globals.gpg_profile.passphrase = get_passphrase(1, action)

I think this conflicts with the new functionality introduced by validate_encryption_settings, as it is essentially verifying the first volume to ensure the encryption keys are correct.

So, a "full" backup doesn't load a value in globals.gpg_profile.passphrase, but if the last backup was found to be partial, validate_encryption_settings gets called, which leads to an operation (file read? gpg initialization?) that requires globals.gpg_profile.passphrase to be set. Hence GPG's complaint.

I've attached a patch that solves this issue for me, but I have no idea how it will affect other usage scenarios. The patch just adds a few lines in validate_encryption_settings to load globals.gpg_profile.passphrase if it hasn't been loaded already. Feels, hacky, but it's working for now.

Hope that helps!