Re: [fpc-pascal] Return value of StrToHostAddr and StrToHostAddr6 in sockets unit
Per discussions, I've posted a proposed patch on bug 37060 https://bugs.freepascal.org/view.php?id=37060 I've also attached a test program that exercises the new functions. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 15/05/20 11:25 pm, Michael Van Canneyt wrote: On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: That must be a new record in bug fix speed. You fixed that within ten minutes of my message to the list! I forgot to mention in my message, but did mention in the bug report, that leading zeroes are also allowed, so you can parse: 01.1.1.1 Personally I don't think this is a problem (mathematically, you can add as many zeroes as you like), but I can imagine some do, so I fixed it. Well, the same argument could be made for allowing hexadecimal or other notations. But ip address representation formats aren't just numbers, they're textual representations meant for easy transmission between programs and across networks, and the standards documents are quite clear about what's allowed in them and what's not. If StrToHostAddr breaks with those standards and accepts addresses that other implementations won't, or rejects addresses others accept, that makes it unusable for programs that must operate in mixed language environments. In my own case, I'm writing a program to parse and validate SPF records, as defined in RFC7208. SPF records are read and processed by SMTP servers as they receive mail, so any tools that attempt to validate SPF records must not accept as valid any ipv4 or ipv6 address that the SMTP server won't also accept. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: That must be a new record in bug fix speed. You fixed that within ten minutes of my message to the list! I forgot to mention in my message, but did mention in the bug report, that leading zeroes are also allowed, so you can parse: 01.1.1.1 Personally I don't think this is a problem (mathematically, you can add as many zeroes as you like), but I can imagine some do, so I fixed it. Rev. 45368. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 15/05/20 10:48 pm, Michael Van Canneyt wrote: On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. https://bugs.freepascal.org/view.php?id=37080 As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Any number in any notation will be accepted as long as byte overflow isn't triggered. Thus, + in octets is accepted, but - is not, because the function detects that the octet is negative which then triggers overflow. Fixing this is outside the scope of the patch I'm preparing for 37060, but if no-one else feels inclined to look into this by the time I'm finished with that patch then I'll submit a new patch for it. Fixed. That must be a new record in bug fix speed. You fixed that within ten minutes of my message to the list! I forgot to mention in my message, but did mention in the bug report, that leading zeroes are also allowed, so you can parse: 01.1.1.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. https://bugs.freepascal.org/view.php?id=37080 As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Any number in any notation will be accepted as long as byte overflow isn't triggered. Thus, + in octets is accepted, but - is not, because the function detects that the octet is negative which then triggers overflow. Fixing this is outside the scope of the patch I'm preparing for 37060, but if no-one else feels inclined to look into this by the time I'm finished with that patch then I'll submit a new patch for it. Fixed. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. https://bugs.freepascal.org/view.php?id=37080 As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Any number in any notation will be accepted as long as byte overflow isn't triggered. Thus, + in octets is accepted, but - is not, because the function detects that the octet is negative which then triggers overflow. Fixing this is outside the scope of the patch I'm preparing for 37060, but if no-one else feels inclined to look into this by the time I'm finished with that patch then I'll submit a new patch for it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
