Package: assword
Version: 0.10-1
Severity: normal
I have a policy of only using a signing-capable subkey for a few
years, creating a new one shortly before the old one expires. This
lets me delete my secret keys after they've been used for a while.
This lets me retire keys, limiting the time window for any key
compromise.
I just had such a subkey rotation; my old signing-capable subkey is
now expired, though i have a new one.
assword fails badly in this situation!
0 dkg@alice:~$ assword gui
Traceback (most recent call last):
File "/usr/bin/assword", line 11, in <module>
load_entry_point('assword==0.10', 'console_scripts', 'assword')()
File "/usr/lib/python3/dist-packages/assword/__main__.py", line 553, in main
func(args)
File "/usr/lib/python3/dist-packages/assword/__main__.py", line 343, in gui
db = open_db(keyid)
File "/usr/lib/python3/dist-packages/assword/__main__.py", line 51, in open_db
db = assword.Database(DBPATH, keyid)
File "/usr/lib/python3/dist-packages/assword/db.py", line 56, in __init__
cleardata = self._decryptDB(self._dbpath)
File "/usr/lib/python3/dist-packages/assword/db.py", line 103, in _decryptDB
data, _, vfy = self._gpg.decrypt(encdata)
File "/usr/lib/python3/dist-packages/gpg/core.py", line 347, in decrypt
raise errors.BadSignatures(verify_result)
gpg.errors.BadSignatures: EDB2E74F56FCF2B67297B73524ECFF5AFF68370A: Key expired
1 dkg@alice:~$
While the key is indeed expired, the signature that was made that
we're validating was made *before* the expiration.
I think the right thing to do would be to verify the signature based
on its timestamp. This means, of course, that a compromised key could
just make backdated signatures, so you'd want to have some additional
verifications as a double-check. Additional verifications might help
to limit the potential damage:
a) if there are any timestamps in the cleartext that post-date the
signature date, something is wrong.
b) if the filesystem timestamp for the encrypted db is "significantly
different" (not sure exactly what measurements to use here) than
the signature date, something is wrong.
c) if the signature date is in the future, then something is wrong.
d) if the signature date is "far in the past" (again, not sure
exactly what metrics to use) and is made by an expired subkey,
then something is wrong.
e) because of (d), we might want assword to offer to update the
signature if we see a recent valid signature made by an expired
subkey, and a new signing-capable subkey is available.
In the meantime, my workaround is to do "e" manually:
mv .assword/db .assword/db.previous
gpg --status-fd=2 --decrypt < .assword/db.previous | gpg -r $PGPID --encrypt
--sign > .assword/db
--dkg
-- System Information:
Debian Release: stretch/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (200,
'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages assword depends on:
ii python3-gi 3.22.0-2
ii python3-gpg 1.8.0-3
pn python3:any <none>
Versions of packages assword recommends:
ii python3-xdo 0.3-2
ii xclip 0.12+svn84-4
assword suggests no packages.
-- no debconf information
