Niels Möller nisse@lysator.liu.se writes:
The documentation of base64_decode_update says
@var{dst} should point to an area of size at least BASE64_DECODE_LENGTH(@var{src_length}). The amount of data generated is returned in *@var{dst_length}.
(and similarly for base16_decode_update).
[...]
Suggestion: Make dst_length an input parameter as well (similar to, e.g., the rsa_decrypt functions). If decoding would produce more bytes than there is space for, decoding fails.
I think I'd like to do this change. It seems to be a rather important usecase to decode base64 input where the binary data is of known size, e.g., an ed25519 key or signature. Question is if it's to much breakage to change the semantics of existing functions, rather than inventing new names.
A related question: What about the nettle_armor interface, can that be deleted? It is defined in nettle-meta.h, with function types defined in nettle-types.h (with comment claiming that they are experimental). They're not mentioned in the manual, and I find no usage in codesearch.debian.net (only matches I can find are commented out mention of symbols in https://sources.debian.org/src/box64/0.3.4+dfsg-1/src/wrapped/wrappedlibnett...).
Regards, /Niels