Package: python-debian
Version: 0.1.21
Severity: normal
The GpgInfo class has trouble with multiple signatures (as anticipated in the
code). Specifically, parsing gpgv output where there are multiple signatures
results in the last signature output from gpgv overwriting all previous
signature output. For example, with a GpgInfo modified to show the output from
gpgv, we see that the first signature is missing from the GpgInfo dict at the
end.
In [1]: deb822.GpgInfo.from_file("InRelease")
[GNUPG:] SIG_ID yrzgfYqxMsicYATRfe4Eb0Y2zTI 2013-06-01 1370075920
[GNUPG:] GOODSIG AED4B06F473041FA Debian Archive Automatic Signing Key
(6.0/squeeze) <ftpmaster@....>
[GNUPG:] VALIDSIG 9FED2BCBDCD29CDF762678CBAED4B06F473041FA 2013-06-01
1370075920 0 4 0 1 2 01 9FED2BCBDCD29CDF762678CBAED4B06F473041FA
[GNUPG:] SIG_ID UHfPUE8iBAo1hWxJ7OJANR1eElw 2013-06-01 1370075920
[GNUPG:] GOODSIG 8B48AD6246925553 Debian Archive Automatic Signing Key
(7.0/wheezy) <ftpmaster@....>
[GNUPG:] VALIDSIG A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553 2013-06-01
1370075920 0 4 0 1 2 01 A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553
Out[1]:
{'GOODSIG': ['8B48AD6246925553',
'Debian Archive Automatic Signing Key (7.0/wheezy) <ftpmaster@....>'],
'SIG_ID': ['UHfPUE8iBAo1hWxJ7OJANR1eElw', '2013-06-01', '1370075920'],
'VALIDSIG': ['A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553',
'2013-06-01',
'1370075920',
'0',
'4',
'0',
'1',
'2',
'01',
'A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553']}
or an even weirder situation where one key is in the keyring and the other
isn't:
In [2]: deb822.GpgInfo.from_file("DummyInRelease")
[GNUPG:] SIG_ID UyOIE2DGhwjpPEJ0gsqP39gZ4Bo 2013-06-03 1370270543
[GNUPG:] GOODSIG 9FE8B8CD71C5D1A8 Stuart Prescott <stuart@....>
[GNUPG:] VALIDSIG BE65FD1EF4EA08F323D43C6D9FE8B8CD71C5D1A8 2013-06-03
1370270543 0 4 0 17 2 01 BE65FD1EF4EA08F323D43C6D9FE8B8CD71C5D1A8
[GNUPG:] ERRSIG BBC17EBB1396F2F7 1 8 01 1370270543 9
[GNUPG:] NO_PUBKEY BBC17EBB1396F2F7
Out[2]:
{'ERRSIG': ['BBC17EBB1396F2F7', '1', '8', '01', '1370270543', '9'],
'GOODSIG': ['9FE8B8CD71C5D1A8', 'Stuart Prescott <stuart@...>'],
'NO_PUBKEY': ['BBC17EBB1396F2F7'],
'SIG_ID': ['UyOIE2DGhwjpPEJ0gsqP39gZ4Bo', '2013-06-03', '1370270543'],
'VALIDSIG': ['BE65FD1EF4EA08F323D43C6D9FE8B8CD71C5D1A8',
'2013-06-03',
'1370270543',
'0',
'4',
'0',
'17',
'2',
'01',
'BE65FD1EF4EA08F323D43C6D9FE8B8CD71C5D1A8']}
Note that the valid() method would report that this last example was a valid
signature because one of the signatures was VALIDSIG, despite the fact that
the other was ERRSIG (or EXPSIG or KEYEXPIRED or ...).
The uid() method is presumably completely unused as it does nothing so that's
not too much of a problem for multiple signatures, but the fundamental data
structure of GpgInfo being a dict with keys of the gpgv code (i.e the SIG_ID,
GOODSIG, VALIDSIG) above is at odds with supporting multiple signatures.
I can imagine GpgInfo behaving like a dict for compatibility reasons and moving
instead to a GpgInfo.signatures list that is a list of dict objects that look
like the current GpgInfo dict. It's not obvious how to successfully split the
gpgv output into blocks for that sort of list of signatures -- the output above
makes it tempting to assume that SIG_ID is a header for signature information,
but /usr/share/doc/gnupg/DETAILS.gz cautions:
SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp>
This is emitted only for signatures of class 0 or 1 which
have been verified okay.
So any BADSIG or ERRSIG (like NO_PUBKEY) would not emit this separator:
(forcing a BADSIG by changing the signed data)
[GNUPG:] BADSIG AED4B06F473041FA Debian Archive Automatic Signing Key
(6.0/squeeze) <ftpmaster@....>
(one VALIDSIG and one ERRSIG/NO_PUBKEY)
[GNUPG:] SIG_ID UyOIE2DGhwjpPEJ0gsqP39gZ4Bo 2013-06-03 1370270543
[GNUPG:] GOODSIG 9FE8B8CD71C5D1A8 Stuart Prescott <stuart@....>
[GNUPG:] VALIDSIG BE65FD1EF4EA08F323D43C6D9FE8B8CD71C5D1A8 2013-06-03
1370270543 0 4 0 17 2 01 BE65FD1EF4EA08F323D43C6D9FE8B8CD71C5D1A8
[GNUPG:] ERRSIG BBC17EBB1396F2F7 1 8 01 1370270543 9
[GNUPG:] NO_PUBKEY BBC17EBB1396F2F7
An alternative approach that saves trying to split out which lines relate to
which signature is to interpret the lines from gpgv as currently done but store
them in a list rather than a dict. This makes methods like valid() a little
harder as it would need to iterate the list rather than just look in the dict
keys, but more importantly it would break all current users of GpgInfo that
relied on it being a dict. I assume we can't really do that, but do we really
want a list of parsed gpgv output being stored as well as the mushed-together
dict to maintain compatibility?
Trying to turn semi-structured output into a data structure is always going to
be problematic -- any suggestions on how do so here?
cheers
Stuart
-- System Information:
Debian Release: 7.0
APT prefers stable-updates
APT policy: (550, 'stable-updates'), (550, 'proposed-updates'), (550,
'stable'), (70, 'testing'), (60, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-debian depends on:
ii python 2.7.3-4
ii python-chardet 2.0.1-2
ii python2.6 2.6.8-1.1
ii python2.7 2.7.3-6
Versions of packages python-debian recommends:
ii python-apt 0.8.8.2
Versions of packages python-debian suggests:
ii gpgv 1.4.12-7
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
