why is GPG_ERR_SEXP_ZERO_PREFIX an error for gcry_sexp_canon_len()?

[Daniel Kahn Gillmor]

On Tue 2019-05-21 10:32:21 +0200, Werner Koch wrote:
> On Fri, 17 May 2019 01:59, dkg at fifthhorseman.net said:
>> Hm, i don't see this text on that webpage at all.  Can you tell me where
>> you're getting it from?
>
> Second heading ("References and Documentarion"), first line:
>
> SEXP 1.0 guide (text) --> http://people.csail.mit.edu/rivest/Sexp.txt
>
>> But the choice gcrypt makes is also inconsistent with this list -- why
>> say "no empty octet-strings" but not "no empty lists", for example?
>
> Because it has been implemented in this way 17 years ago and any changes
> now may result in broken applications.

Do you have an example of an application that might be broken by
dropping this constraint?

Nothing in the documentation of libgcrypt guarantees that
gcry_sexp_canon_len() will continue to enforce this constraint.  Rather,
it says "for a valid S-expression, it should never return 0", but it
does in fact return zero for the valid S-expression (x: "").

I've opened https://dev.gnupg.org/T4534, which identifies the
inconsistency between the documentation and the behavior of the
function.

If gcrypt intends to rigidly enforce arbitrary limits like this, it
needs to declare it explicitly, so that applications that need to deal
with S-expressions from the outside world (which may actually contain
zero-length octet strings) can select a more suitable library for
S-expression parsing.

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20190521/54914c4c/attachment.sig>