For DETAILS, most of the output is UTF-8, while for NOTATION*, there's some non-valid UTF-8 binary data mixed in. We've had some cases where Python scripts assume all of status-fd's output is valid UTF-8 and then they fail to decode it.
Would it be possible to always escape the remaining data (>=0x80) for NOTATION* for status-fd?
The question is who shall correct the wrong encoding of notation data (assuming it is flagged as human readable). Escaping is a solution but needs a lot of extra bytes.
In you case, is that marked as human readable ?
That's a good question. Looking at https://datatracker.ietf.org/doc/draft-koch-librepgp/, it doesn't really specify what encoding is used for "human-readable" notation, so I'd personally lean towards encoding it to stay on the safe side. Unless I'm mistaken, status-fd will only be used locally, so escaping overhead should not be a problem.
In our case, it's not marked as human readable.
Since rfc2440 the PGP specs say:
Unless otherwise specified, the character set for text is the UTF-8
[](#RFC3629) encoding of Unicode [](#ISO10646).
So this is what should be expected from human readable. Given your case a change to escape all non-ascii if not human readable should work.
Alright, I change it from for notation data (and name).
[GNUPG:] NOTATION_NAME foo@foo.org [GNUPG:] NOTATION_FLAGS 0 1 [GNUPG:] NOTATION_DATA bla%20bla%20��%20blub
with change:
[GNUPG:] NOTATION_NAME foo@foo.org [GNUPG:] NOTATION_FLAGS 0 1 [GNUPG:] NOTATION_DATA bla%20bla%20%81%82%20blub
Test data created with
fortune | gpg -s -N "foo@foo.org=bla bla $(printf '\x81\x82') blub"
A general change to always escape status lines for non-ascii has a large risk of regression. Thus the limitation to notation.