Re: Getting ready for a release, wildcards
+1 to NOT making this a knob. On 4/20/22 15:07, Matt Selsky via devel wrote: Hi Hal, If you're sufficiently happy with my code change, then you can click "approve" and "merge" on https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1264 I would rather not add knobs unless someone asks for this to be a knob. Thanks, -Matt From: Hal Murray Sent: Wednesday, April 20, 2022 2:12 PM To: Matt Selsky Cc: devel@ntpsec.org ; Hal Murray Subject: Re: Getting ready for a release, wildcards [The mail system is in sloth mode again.] matthew.sel...@twosigma.com said: I don't think we should have a knob for disabling wildcards. This is not the sort of knob that operators expect (what other software provides such a knob?) and we're just adding another code path to test. I'll be interested in other opinions. Just because nobody else does it doesn't mean it's a bad idea. Somebody has to go first. If it's extra code on our end, think of all the code in OpenSSL that we don't exercise if we don't allow wildcards. I have running code. The default is to allow wildcards so nobody will get surprised. I can push later today. If you want to go the merge request route, somebody will have to give me a lesson. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel -- Richard ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Release, wildcards, etc
[Eric: There are a couple of preceding messages to devel in the mail someplace.] > I'd like to get https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1264 merged > and then do the release. > Is there anything else that we want in the release? I'm sorry that we have gotten off on the wrong foot (feet?). I'll try to review and maybe fill in a few blanks. It's time for a release in general. Fixing the wildcard bug is a good excuse to do it now. There is no rush or deadline. You are putting me in an awkward position by asking me to approve your patch when I want to do something else. I think your fix will do what you want. I haven't actually tested it. You have a simple fix for the wildcards. I have a more complicated one, with knobs that you don't like. If it wasn't for tangling with your fix, I would have just pushed this code. I'm not sure why you don't like my knobs. Several possibilities: 1) more code to test. There are 8 cases. I think I tested them all. If it will make you happy, I'll test again, being careful to check all 8 cases. 2) it's useless clutter I'd like to experiment with it. Other than general clutter, I can't think of any reason not to include my knobs. 3) you want to get the release out soon and don't want to think about knobs. As far as I know, there is no rush on the release. I'll help more with testing if my knobs are in. 4) others? I can't think of anything else that needs to go into this release. I have some code that adds another line to the (already noisy) client side logging for the KE exchange to display the SAN:DNS list from the certificate. I think it should go in, but I'll wait until after the release if you prefer. We should scan the issues and merge requests. (James has several that we have all been negligent about approving or providing feedback.) -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
Richard Laager said: > Sure, that's all true. But, I'm not sure why you felt the need to mention > this. That is how everything works. In general, it's not even guaranteed > that a TLS-speaking daemon knows its own (external) hostname. It obviously > can't know what is in the client's trust store. Somebody complained about being able to load a certificate with a wildcard that the same code wouldn't accept as a client. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
On Apr 20, 2022 7:50 AM, Matt Selsky via devel wrote:Hi Hal, I don't think we should have a knob for disabling wildcards. This is not the sort of knob that operators expect (what other software provides such a knob?) and we're just adding another code path to test. Are there any other release blockers? If not, I'll update the NEWS for the user-facing/high impact changes and cut a release candidate.Inconsistent output formatting for 'ntpq sysstats'? Bytes output of test data in 'waf check -v'? Potentual mac truncation in Python 3? Nah.___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
> I would rather not add knobs unless someone asks for this to be a knob. Nobody outside is ever going to ask for this knob. It's a grubby detail. Only geeks know that the concept exists. I want this knob so I/we can experiment. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
On 4/19/22 17:01, Hal Murray via devel wrote: One is to update the nts cert documentation to say that it doesn't do any checking on the certificate. - Present the certificate in _file_ as our certificate. + Present the certificate (chain) in _file_ as our certificate. + + + Note that there is no checking on the certificate. + In particular, it may have expired or may not cover the host name + used to get to this server or may not be signed by a CA that + is in the clients root-server collection. Sure, that's all true. But, I'm not sure why you felt the need to mention this. That is how everything works. In general, it's not even guaranteed that a TLS-speaking daemon knows its own (external) hostname. It obviously can't know what is in the client's trust store. The only one of those things it could possibly check is whether the certificate is expired. But I recommend against trying to do that. It's not an expectation that daemons check that. More importantly, as always in the NTP space, that can lead to chicken-and-egg problems. If I have an isolated (not connected to the Internet) server with GPS, it might not have correct time when ntpd starts, but will get it once the GPS locks. -- Richard OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
Hi Hal, If you're sufficiently happy with my code change, then you can click "approve" and "merge" on https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1264 I would rather not add knobs unless someone asks for this to be a knob. Thanks, -Matt From: Hal Murray Sent: Wednesday, April 20, 2022 2:12 PM To: Matt Selsky Cc: devel@ntpsec.org ; Hal Murray Subject: Re: Getting ready for a release, wildcards [The mail system is in sloth mode again.] matthew.sel...@twosigma.com said: > I don't think we should have a knob for disabling wildcards. This is not the > sort of knob that operators expect (what other software provides such a > knob?) and we're just adding another code path to test. I'll be interested in other opinions. Just because nobody else does it doesn't mean it's a bad idea. Somebody has to go first. If it's extra code on our end, think of all the code in OpenSSL that we don't exercise if we don't allow wildcards. I have running code. The default is to allow wildcards so nobody will get surprised. I can push later today. If you want to go the merge request route, somebody will have to give me a lesson. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
Re: Getting ready for a release, wildcards
[The mail system is in sloth mode again.] matthew.sel...@twosigma.com said: > I don't think we should have a knob for disabling wildcards. This is not the > sort of knob that operators expect (what other software provides such a > knob?) and we're just adding another code path to test. I'll be interested in other opinions. Just because nobody else does it doesn't mean it's a bad idea. Somebody has to go first. If it's extra code on our end, think of all the code in OpenSSL that we don't exercise if we don't allow wildcards. I have running code. The default is to allow wildcards so nobody will get surprised. I can push later today. If you want to go the merge request route, somebody will have to give me a lesson. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
