Opaque gpg failures
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
simplestreams |
Confirmed
|
Medium
|
Unassigned |
Bug Description
I just hit this traceback from simplestreams 0.1.0~bzr341-
«
$ uvt-simplestrea
Traceback (most recent call last):
File "/usr/bin/
uvtool.
File "/usr/lib/
args.func(args)
File "/usr/lib/
tmirror.
File "/usr/lib/
content, payload = reader.
File "/usr/lib/
return raw, self.policy(
File "/usr/lib/
content, keyring=
File "/usr/lib/
raise e
subprocess.
$
»
The error seems to have gone away by itself, but this bug isn't about that. The bug is here to say that it'd be very helpful to see gpg's standard error output.
One thing the error message does tell me is that this is not a case of a signature failing to verify. Because in that situation, gpg returns 1.
It looks to me like the invalid-signature error is the whole point of read_signed, so it seems unfair and confusing to lump that error in with systemic failures. I would suggest defining and documenting a specific exception class for "signature failed to verify." Then, uvtool would have the option of catching that error separately and presenting it in a friendlier form — while pulling out all the debugging stops for other failures.
Any legacy implementations of read_signed would still raise the old error, and legacy applications built on simplestreams wouldn't treat the new error specially. I don't know if that matters; the one incompatibility that comes to mind would be for applications that specifically catch CalledProcessError to deal with it specially.
Changed in simplestreams: | |
status: | New → Confirmed |
importance: | Undecided → Medium |