Hi Bernd,

Thank you for your comments! inet_addr() is POSIX.1, please see https://pubs.opengroup.org/onlinepubs/9699919799/functions/inet_addr.html

In its common implementation inet_addr() is just

u_long
inet_addr(cp)
        register  const  char  *cp;
{
        struct  in_addr val;

        if  (inet_aton(cp, &val))
                return  (val.s_addr);
        return  (INADDR_NONE);
}

In turn, inet_aton() is what's described - it either recognizes the hex/octal bases or relies on strtoul().

RFC 3493 section 6.1 specifies a protocol-independent node name and service name translation:

  "If the specified address family is AF_INET or AF_UNSPEC,
   address strings using Internet standard dot notation as specified in
   inet_addr() are valid."

In the discussion of .ofLiteral() it was not concluded that .ofPosixLiteral() would be insecure or undesirable. From the 'security issues' point of view, it is a new method, it won't change the behavior of old apps. If any code (a csrf filter) written in Java recognized (knowing what it does) additional literal address formats, it would only be an improvement (in detection). The good reason is bringing compatibility with standard tools relying on inet_addr() into Java, that would actually help overcoming the confusion between the standards. A real world example could be a Java program parsing HOSTS file (it allows hexadecimal address segments).


Am 26.03.24 um 20:10 schrieb Bernd Eckenfels:
Would be helpful to point to the posix standard/requirement which mandates 
this. Do you mean a single Unix api description or a posix command spec? I 
don’t think I know of any such things.

Wikipedia claims A POSIX-conforming variant of inet_aton, the inet_pton() 
function, supports only the four-decimal variant of IP addresses.[10]

And can you also justify a bit more who needs that octal compatibility? Over 
the years a lot of confusion (zero padding) and security issues (csrf filters 
not catching all formats) have been found, so it’s really not a good idea to 
implement it for no good reason. I think this was also the conclusion for the 
ofLiteral() api.

Sergey Chernyshev wrote on 26. Mar 2024 17:51 (GMT +01:00):

Hello Core Libs Dev team,

I would like to propose a PR to extend the InetAddress API in JDK 23,

Reply via email to