Hal Murray <hmur...@megapathdsl.net>:
> That's not the question I was trying to ask.
Ah.
> I was inquiring about reading keys from the keys file. You are talking about
> bits on the wire.
>
> It's actually more complicated than length==5 for MD5. The type (MD5) is
> also in the keys file. I don't know what the code actually does.
If you read ntpkeygen I think matters will become clearer.
> I believe the plan is to switch to a type+length+body format for packet
> extensions. Backward compatibility requires adding dummy extensions if
> required to avoid the magic lengths the current code understands or maybe
> just make the total length more than the longest of the grandfathered
> lengths. (No need for NTPv5, at least for this reason.)
You're right about "the plan". The conservative way to do NTPv5 would just
be as a bunch of defined extension types, one for new auth key types.
> I just looked at the code to answer my question.
>
> * Finally, get key and insert it. If it is longer than 20
> * characters, it is a binary string encoded in hex;
> * otherwise, it is a text string of printable ASCII
> * characters.
>
> If ntpq has code to read passwords from the keyboard, we should copy that
> hack.
The hack is just the Python getpass() library function. Easy stuff.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
