TXT record parsing can fail if the record contains binary data

[johnmgithub]

The DNS discovery spec (RFC 6763) allows binary data to be included (see section 6.5) in TXT records.

"The value is opaque binary data. Often the value for a particular attribute will be US-ASCII [RFC20] or UTF-8 [RFC3629] text, but it is legal for a value to be any binary data."

"Authors defining DNS-SD profiles SHOULD NOT generically convert binary attribute data types into printable text using hexadecimal representation, Base-64 [RFC4648], or Unix-to-Unix (UU) encoding"

If a TXT record does contain binary data the readStringsFromBuffer method can fail, as it uses label.length() to count its bytes read rather than using stringLength directly. That can result in the byte count being one fewer than it should be. Here is a corrected version of readStringsFromBuffer to accommodate that:

public static List<String> readStringsFromBuffer(ByteBuffer buffer, int length) {
    List<String> strings = new ArrayList<>();
    int bytesRead = 0;
    do {
        int stringLength = buffer.get() & 0xFF;
        String label = readLabel(buffer, stringLength);
        bytesRead += stringLength + 1;
        strings.add(label);
    } while (bytesRead < length);
    return strings;
}

[darmbrust]

fixed in the above commit on my fork, if you need a release, see https://github.com/Sagebits/hola/releases/tag/v0.2.4-sagebits

also published to maven central as

<dependency>
	<groupId>net.sagebits</groupId>
	<artifactId>hola</artifactId>
	<version>0.2.4-sagebits</version>
</dependency>