duplicity-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Duplicity-tracker] [bug #25976] Signed Backups Now Required


From: Corey Seliger
Subject: [Duplicity-tracker] [bug #25976] Signed Backups Now Required
Date: Mon, 23 Mar 2009 13:47:37 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 (.NET CLR 3.5.30729)

URL:
  <http://savannah.nongnu.org/bugs/?25976>

                 Summary: Signed Backups Now Required
                 Project: duplicity
            Submitted by: seliger
            Submitted on: Mon 23 Mar 2009 01:47:35 PM GMT
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I used to be able to run jobs exactly like this:

duplicity \
inc \
--asynchronous-upload \
--timeout 600 \
--num-retries 25 \
--encrypt-key "${PUBKEY}" \
--tempdir /export/backup/tmp \
--archive-dir /export/backup/archive \
--exclude-globbing-filelist /etc/backups/${THISHOST}.exc \
--include-globbing-filelist /etc/backups/${THISHOST}.inc \
--volsize 8 \
/ \
scp://address@hidden/${THISHOST}


I previously never needed specify the --sign-key parameter, but when I
upgraded to 0.5.12 (was previously using 0.5.03), I could not run an
incremental without it. Otherwise I would end up with:

===== Begin GnuPG log =====
gpg: encrypted with 1024-bit ELG-E key, ID 8FCBFF0E, created 2008-11-06
"Core Software Systems (Web Hosting Infrastructure)
<address@hidden>"
gpg: public key decryption failed: bad passphrase
gpg: decryption failed: secret key not available
===== End GnuPG log =====
GPG Failed, see log above


Not really understanding why I needed it, I apppended --sign-key "${PUBKEY}"
to my backup line. That allowed me to get an incremental backup in, but it has
essentially broken my previous backups since the full backup taken the night
prior did not require me to use --sign-key. When I run a verify against a file
in my backup set I get this:

Running 'sftp  -oServerAliveInterval=15 -oServerAliveCountMax=1
address@hidden' (attempt #1)
sftp command: 'mkdir web-a-002'
sftp command: 'cd web-a-002'
sftp command: 'ls -1'
Last full backup date: Sun Mar 22 00:45:03 2009
Using temporary directory /export/backup/tmp/duplicity-rRhEiy-tempdir
Running 'scp  -oServerAliveInterval=15 -oServerAliveCountMax=1
address@hidden:web-a-002/duplicity-full.2009-03-22T00:45:03-04:00.vol1.difftar.gpg
/export/backup/tmp/duplicity-rRhEiy-tempdir/mktemp-GcW0E8-1' (attempt #1)
Difference found: File . has type dir, expected reg
===== Begin GnuPG log =====
gpg: encrypted with 1024-bit ELG-E key, ID ********, created 2008-11-06
"Core Software Systems (Web Hosting Infrastructure)
<address@hidden>"
===== End GnuPG log =====
Volume was signed by key None, not ********


I would expect this message because the original backup I took was unsigned.
So now I am in a catch 22 situation. 

I have traced it to this block of code in the duplicity code (starting at
line 708):

        else:  # attempt incremental
            if not (pubkey_only() and globals.archive_dir) and
globals.encryption:
                globals.gpg_profile.passphrase = get_passphrase(1)
            check_last_manifest(col_stats) # not needed for full backup
            sig_chain = check_sig_chain(col_stats)
            if not sig_chain:
                if not pubkey_only() and globals.encryption:
                    globals.gpg_profile.passphrase = get_passphrase(2)
                full_backup(col_stats)
            else:
                incremental_backup(sig_chain)


Looking through the code, this is how I realized I needed to specify the
--sign-key because if I did not, I would never pass through logic which calls
get_passphrase(). That therefore causes the GPG error I describe above when
attempting to run an incremental. (It never attempts to pick up the passphrase
I specified...)

That leads me to the next two questions:

1) Is it really necessary to pass in a --sign-key? If so, when did that
become a requirement?

2) If it is not a requirement to pass in a --sign-key, I strongly feel that
this is a bug.

3) If it is a requirement, can there be more documentation to state what key
I should be using to sign the backups? The public or private key?









    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?25976>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]