InetAddress API extension proposal
Sergey Chernyshev
serge.chernyshev at bell-sw.com
Wed Mar 27 08:05:25 UTC 2024
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>
More information about the core-libs-dev
mailing list