3 ms·

> and collapses any sequence of ":0000:" to "::" Which is an error. Any ip like 2001:0000:0000::1 is going to be incorrect. It willingly produces errors. Wh

> and collapses any sequence of ":0000:" to "::" Which is an error. Any ip like 2001:0000:0000::1 is going to be incorrect. It willingly produces errors. Whoever wrote this didn't even spend a few seconds thinking about the structure of IPv6 addresses. > I don't see anything problematic with it. Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself.

cpburns2009 1y ago
It only operates on a 32 digit IPv6 address so it won't already be abbreviated. My phrasing was inexact. It replaces only the first sequence of any number of ":0000:" to "::".
remram 1y ago
> Any ip like 2001:0000:0000::1 is going to be incorrect. This is neither a possible input nor a possible output of that code.
- dontdoxxme 1y ago
  That example doesn't work, but an IPv6 address like: 3fff:0020:: Would be in the IP SAN as 3fff0020000000000000000000000000, which this code expands: "3fff0020000000000000000000000000" .toLowerCase() .match(/.{1,4}/g) .join(":") .replace(/\b:?(?:0+:?){2,}/, "::") '3fff::20:0000:0000:0000:0000:0000:0000' Which has one too many parts and doesn't parse as an IPv6 address. But like mentioned this is just presentation code. I don't want to waste time if this isn't actually a bug, but maybe someone on the LetsEncrypt trial could actually make a cert to see if IP addresses formatted like that are a problem in reality...
  - remram 1y ago
    That one does look like a bug. I stand corrected.
ephou7 1y ago
> Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself. It's not. And the sequence you describe is not even parsed because colons are not part of the IPv6 extension of the SAN. PLease educate yourself before spilling such drivel.
ranger_danger 1y ago
> Any ip like 2001:0000:0000::1 is going to be incorrect How so?

cpburns2009 1y ago

It only operates on a 32 digit IPv6 address so it won't already be abbreviated. My phrasing was inexact. It replaces only the first sequence of any number of ":0000:" to "::".

remram 1y ago

> Any ip like 2001:0000:0000::1 is going to be incorrect. This is neither a possible input nor a possible output of that code.

dontdoxxme 1y ago
That example doesn't work, but an IPv6 address like: 3fff:0020:: Would be in the IP SAN as 3fff0020000000000000000000000000, which this code expands: "3fff0020000000000000000000000000" .toLowerCase() .match(/.{1,4}/g) .join(":") .replace(/\b:?(?:0+:?){2,}/, "::") '3fff::20:0000:0000:0000:0000:0000:0000' Which has one too many parts and doesn't parse as an IPv6 address. But like mentioned this is just presentation code. I don't want to waste time if this isn't actually a bug, but maybe someone on the LetsEncrypt trial could actually make a cert to see if IP addresses formatted like that are a problem in reality...
- remram 1y ago
  That one does look like a bug. I stand corrected.

ephou7 1y ago

> Other than it being completely wrong and requiring a regex to be compiled for an amount of work that's certainly less than the compilation itself. It's not. And the sequence you describe is not even parsed because colons are not part of the IPv6 extension of the SAN. PLease educate yourself before spilling such drivel.

ranger_danger 1y ago

> Any ip like 2001:0000:0000::1 is going to be incorrect How so?