<div class="gmail_quote">On Fri Nov 28 2014 at 10:49:21 PM Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
On 28/11/14 01:26, Angus Lees wrote:<br>
> Context: <a href="https://review.openstack.org/#/c/135616" target="_blank">https://review.openstack.org/#<u></u>/c/135616</a><br>
><br>> If we're happy disabling the check for components being all-digits, then<br>
> a minimal change to the existing regex that could be backported might be<br>
> something like<br>
>   r'(?=^.{1,254}$)(^(?:[a-zA-Z0-<u></u>9_](?:[a-zA-Z0-9_-]{,61}[a-zA-<u></u>Z0-9])\.)*(?:[a-zA-Z]{2,})$)'<br>
><br>
> Alternatively (and clearly preferable for Kilo), Kevin has a replacement<br>
> underway that rewrites this entirely to conform to modern RFCs in<br>
> I003cf14d95070707e43e40d55da62<u></u>e11a28dfa4e<br>
<br>
With the change, will existing instances work as before?<br></blockquote><div><br></div><div>Yes, this cuts straight to the heart of the matter:  What's the purpose of these validation checks?  Specifically, if someone is using an "invalid" hostname that passed the previous check but doesn't pass an improved/updated check, should we continue to allow it?</div><div>I figure our role here is either to allow exactly what the relevant standards say, and deliberately reject/break anything that falls outside that - or be liberal, restrict only to some sort of 'safe' input and then let the underlying system perform the final validation.  I can see plenty of reasons for either approach, but somewhere in the middle doesn't seem to make much sense - and I think the approach chosen also dictates any migration path.</div><div><br></div><div>As they currently stand, I think both Kevin's and my alternative above _should_ be more liberal than the original (before the "fix") regex.  Specifically, they now allow all-digits hostname components - in line with newer RFCs.<br></div><div><br></div><div>However, TLD handling is a little different between the variants:</div><div>- Kevin's continues to reject an all-digits TLD (also following RFC guidance)</div><div>- mine and the original force TLDs to be all alpha (a-z; no digits or dash/underscore)</div><div><br></div><div>The TLD handling is more interesting because an unqualified hostname (with no '.' characters) hits the TLD logic in all variants, but the original has a "\.?" quirk that means an unqualified hostname is forced to end with at least 2 alpha-only chars.  As written above, mine is probably too restrictive for unqualified names, and this would need to be fixed.</div><div><br></div><div>As the above shows, describing regex patterns in prose is long, boring and inaccurate.  Someone who is going to have to approve the change should just dictate what they want here and then we'll go do that :P</div><div>I suggest they also consider the DoS-fix-backport and the Kilo-and-forwards cases separately.</div><div><br></div><div> - Gus</div></div>