[getdns-users] bindata string encoding?

[Daniel Kahn Gillmor]

On Thu 2015-07-09 16:15:32 -0400, Robert Edmonds wrote:
> I agree, if a field is defined to be a C-style NUL-terminated string,
> then by definition it ends at the first \0 byte and the string cannot
> contain embedded NULs.  But the version of the spec I'm looking at
> (https://getdnsapi.net/spec.html) only says that the 'version_string'
> bindata field represents a "string", without specifying how the string
> is encoded.  My confusion comes about because the string is passed
> through an interface (the getdns_bindata type) that also passes an
> explicit length.

I think i agree with Robert here; the spec allows and makes use of
null-terminated strings specifically in the presentation formats for DNS
labels, but every bindata instance is a length-prefixed string, not a C
string.

>> There are definitely places we're punting the bounds-checking to the
>> Python libraries and that may not be reasonable.
>
> Yeah, AFAICT, the Python binding is just passing the bindata 'data'
> field to PyString_FromString(), which then calls strlen() on it.  So
> there's no bounds-checking at all, it's relying on the 'data' field to
> be NUL-terminated.  That's why I recommend explicitly relying on the
> bounds information that the bindata type provides :-)

I think the right fix is for the python bindings to treat the string as
a proper bindata, but i also think that the bindata string returned from
the C library in getdns_get_api_info's version_string probably shouldn't
have the embedded NUL in it.  Fixing the python bindings before fixing
the C library is probably the safest way to go, though.

     --dkg