InetAddress API extension proposal

[Sergey Chernyshev]

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240327/eb7ed0f1/attachment-0001.htm>