Control: forwarded -1 https://dev.gnupg.org/T7176
On 2024-06-24 Baptiste Beauplat <lykn...@debian.org> wrote: > On Mon, 2024-06-24 at 18:43 +0200, Andreas Metzler wrote: > > Thank you, I have forwarded this to the upstream tracker. > Thanks a lot. > To give out a bit more context, we got an python Exception on > mentors.debian.net triggered by an upload, signed by sq (Sequoia). > The tool apparently adds a random binary salt to the signature as > notation data, which is then present in the status output. > We read the status output as utf-8 encoded data (perhaps wrongfully) > and python failed to decode the output because the salt was neither > escaped properly nor valid utf-8 output. > I do expect we will not be the only one affected by this issue. > I'd like to point out that other function in gpg seem to escape char > over 127 (such as in `print_hashline` from `g10/gpg.c`). [...] Hello, This has been closed upstream as not-a-bug with the following rationale: | The point here is to escape control characters so that we do not run | into problems when reading the stuff. Escaping non-ascii (c >127) is | not required and would put a lower limit on the number of (utf-8) | characters we can print via the status lines. | Note also that we use almost everywhere ascii versions of the | character checks. Thus I would not consider this a bug. And later: | Reading the original bug report it is clear that this is not a gpg bug | but a problem in the Python code. This should only be read as utf-8 if | the NOTATION_FLAGS line indicated that this is human readable. In my test with sqop no NOTATION_FLAGS were set for the salt. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
