✘"\x07ntske/1"

[Achim Gratz]

Gary E. Miller via devel writes:
> Which is not what the hackathon people thought.

So, you can mind-read now and expect everyone else to do the same?  What
was the problem they've had and how didi they say they wanted to solve
it?

> Can you point out where in the API so I can ask the Hackathon people?

It's literally the first hit on "OpenSSL ALPN":
https://www.openssl.org/docs/man1.1.0/man3/SSL_set_alpn_protos.html

The first two API functions dealing with the protocols list require the
vector form, all the other ones deal with the vector elements.  The
vector form (opaque block of counted strings) is explqained under
"Notes".

> Do you know where this is in the NTPsec code?

It's in ntpd/nts_client.c and ntpd/nts_server of course.  Actually
that's probably a bug right there, the protocols list shouldn't get
defined in two places.  The client code needs the vector form, the
server code at the moment doesn't, but it likely will at some point in
time when there is more then one possibility for the protocol.

The disagreement probably was about how the server code compares the
strings.  The API description is pretty clear on that the "in" parameter
is just the char array of "inlen" characters (the counted string is
already split), so indeed the code (which Hal changed from what Christer
had originally committed seems wrong.

The correct algorithm would go something like this: for each permitted
protocol (just one for NTS at the moment), check if "inlen" matches the
length of the protocol string requested.  If it does, check if the two
same-length (unterminated) strings match.  If yes, accept the protocol
(the "out" parameter points to the start of the string in the vector
sans the length byte and the len parameter is the copy of the length
byte), otherwise reject.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada