On Sun, 5 Dec 2021 16:44:05 GMT, Alan Bateman wrote:
> There are several thread safety issues in java.net.ServerSocket, issues that
> go back to at least JDK 1.4.
>
> The issue of most concern is async close of a ServerSocket that is initially
> created unbound and where close may be called at
* Daniel Fuchs:
> The platform built-in resolver that performs name-to-address
> resolution delegates to `getaddrinfo`. AFAICS `getaddrinfo` doesn't
> seem to provide this level of granularity in the error codes
> that it might return - though maybe distinguishing between
> some of the errors it r
* Richard Gibson:
> Probably the OpenJDK implementation, which currently appears to return
> even less information than the famously-restrained getaddrinfo. But
> I'd love to see use of something better such as getdns if that is not
> already the case.
Oh, I was asking about the other OpenJDK nam
* Richard Gibson:
> The OCI DNS team are fielding an increasing amount of usage by
> customers relying upon Java, and the lack of detail associated with
> java.net.UnknownHostException for differentiating e.g. timeout
> vs. NXDOMAIN vs. NODATA vs. SERVFAIL vs. REFUSED has cost a great deal
> of ti
* Benjamin Marwell:
> Well, I am stuck with Java 8 and if any LDAP server goes down, all
> java applications will, too. Python, .NET, etc. are not affected.
Surely that totally depends on the LDAP client implementation in use?
* Kim Barrett:
> And strlen is not even necessarily the best solution, as it likely
> introduces an additional otherwise unnecessary string traversal. For
> example, getFlags could be changed to reject an overly long ifname,
> without using strlen, thusly:
>
> strncpy(if2.ifr_name, ifname, siz
* Kim Barrett:
>> On Sep 4, 2020, at 7:50 AM, Florian Weimer wrote:
>>
>> * Daniel Fuchs:
>>
>>> Hi,
>>>
>>> On 02/09/2020 08:19, Florian Weimer wrote:
>>>> At least one of the bugs was in theory user-visible: the network
>&
* Daniel Fuchs:
> Hi,
>
> On 02/09/2020 08:19, Florian Weimer wrote:
>> At least one of the bugs was in theory user-visible: the network
>> interface code would return data for an interface that does not actually
>> exist on the system.
>
> WRT NetworkInterface.
* Magnus Ihse Bursie:
> Maybe we should have a common library for all native code where we
> supply our own string operation functions? It will then be much easier
> to make sure the implementation passes different compiler versions,
> and that we provide sane semantics (which isn't really the c
If I'm not mistaken, there are currently no concurrency guarantees in
the spec for Socket and SSLSocket.
Specifically, I'm interested whether two different threads can use the
the streams returned by getInputStream() and getOutputStream() without
synchronization. (This is useful for implementing
* Daniel Fuchs:
> Here is the new webrev - I believe I have addressed all your comments:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8231260/webrev.01
Looks good to me too. Sorry for the distraction earlier.
Thanks,
Florian
* Alan Bateman:
> On 04/10/2019 17:03, Florian Weimer wrote:
>> :
>> The kernel will do it atomically during connect, so there is no race
>> condition. With the change above, the port is selected and opened,
>> packets can arrive (from arbitrary addresses), and only
* Daniel Fuchs:
> Hi Florian,
>
> On 04/10/2019 16:25, Florian Weimer wrote:
>> Doesn't it introduce a race condition where the socket has a port and
>> queue packets, but the kernel will not perform source address checking
>> because it is unconnected?
&
* Florian Weimer:
> * Alan Bateman:
>
>> On 04/10/2019 16:25, Florian Weimer wrote:
>>> :
>>> @@ -873,10 +873,15 @@
>>> synchronized (stateLock) {
>>> ensureOpen();
>>> if (state
* Alan Bateman:
> On 04/10/2019 16:25, Florian Weimer wrote:
>> :
>> @@ -873,10 +873,15 @@
>> synchronized (stateLock) {
>> ensureOpen();
>> if (state == ST_CONNECTED)
>>
* Daniel Fuchs:
> Hi,
>
> Please find below a fix for:
>
> 8231260: (dc) DatagramChannel::disconnect changes the port of the
> local address to 0 (lnx)
> https://bugs.openjdk.java.net/browse/JDK-8231260
I remember looking at this a couple of years ago. I was mostly
concerned about the l
* Alan Bateman:
> On 23/01/2019 09:42, Florian Weimer wrote:
>> :
>> Do you plan to read from the socket buffer in the implementation of
>> available()? The problem is that even if there is currently data in the
>> socket buffer, further data that arrives later can cle
* Alan Bateman:
> This is a small change to add a method to sun.nio.ch.Net to get the
> number of bytes in the socket input buffer. The motive for adding this
> to make it possible for the socket adaptors to implement
> InputStream::available and also to support an alternative SocketImpl
> based o
On 06/01/2018 02:13 PM, Alan Bateman wrote:
I can't say for sure whether the kernels actually drop the socket buffer
or not. For the scenario, the connection reset is reported when writing
and on both Linux and macOS you can read the previously received bytes
in the socket buffer.
But there i
On 05/29/2018 04:26 PM, Norman Maurer wrote:
Yes thats what I am saying… I think if a write fails due a connection-reset a
read should still be possible until we are told by the OS that we also hit an
error here.
Are there implementations where the kernel does *not* zap the read
buffer when
* Roger Riggs:
> Updated in place.
> http://cr.openjdk.java.net/~rriggs/webrev-net-cleanup-8195059/
Doesn't this leak the file descriptor of SocketCleanable.register
throws?
On 08/23/2016 09:40 AM, Norman Maurer wrote:
Hi all,
I first asked this on nio-dev[0] but was asked to move this over to here:
I wonder if it would be possible to add a new IOException sub-class for
ECONNRESET. Often you receive these errors if a remote peer closed the
connection and you try
org/bugzilla/show_bug.cgi?id=14906>
(Also see rhbz#859965, currently not public.)
Would using nscd work for you?
--
Florian Weimer / Red Hat Product Security
On 08/18/2014 05:36 PM, Christos Zoulas wrote:
On Aug 18, 5:10pm, fwei...@redhat.com (Florian Weimer) wrote:
-- Subject: Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx
| On 02/28/2014 03:40 PM, Chris Hegarty wrote:
| > Either:
| > 1) FD_SETSIZE needs to be set to a larger
en an appropriate amount of memory
could be allocated and cast to an fd_set. The FD_SET macro will
write past FD_SETSIZE.
3) use poll
Why do we have to use select here?
--
Florian Weimer / Red Hat Product Security
a fix:
<http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011009.html>
The AES-GCM implementation still conses a lot in unrelated parts of the
code, but that's a separate fix.
--
Florian Weimer / Red Hat Product Security
On 02/14/2014 03:04 PM, Alan Bateman wrote:
On 14/02/2014 13:52, Florian Weimer wrote:
This patch removes support for old, pre-1.4 SocketImpl and
DatagramSocketImpl classes. Compiling these classes has been
impossible since 1.4 because 1.4 added new abstract methods to the
base classes.
Is
On 02/14/2014 05:45 PM, Chris Hegarty wrote:
On 14/02/14 14:04, Alan Bateman wrote:
On 14/02/2014 13:52, Florian Weimer wrote:
This patch removes support for old, pre-1.4 SocketImpl and
DatagramSocketImpl classes. Compiling these classes has been
impossible since 1.4 because 1.4 added new
This patch removes support for old, pre-1.4 SocketImpl and
DatagramSocketImpl classes. Compiling these classes has been impossible
since 1.4 because 1.4 added new abstract methods to the base classes.
Is this okay in principle? Could you create bug ID for this?
--
Florian Weimer / Red Hat
uivalently to UNIX sockets on other OSes, which I
already have some support for.
Naming is fundamentally different. With that caveat, it would be
possible to expose a socket-based interface, but application code would
have to adhere to the platform naming convention.
--
Florian Weimer / Red H
On 02/13/2014 02:21 PM, Alan Bateman wrote:
On 13/02/2014 12:54, Florian Weimer wrote:
Can we add further enumeration values to
java.net.StandardProtocolFamily? The spec does not say so, unlike
javax.lang.model.SourceVersion, and the code in the JDK expects a
binary flag, so I think the answer
r protocol
families would be to create a separate implementation of
java.net.ProtocolFamily?
--
Florian Weimer / Red Hat Product Security Team
* Alan Bateman:
> It should be feasible but it would likely be a platform/provider
> specific (mapping to the socket domain, translation to/from the socket
> address, etc.). It would be good if someone had the cycles to
> prototype this and come back with a proposal. Is this something you
> might
* Mark Wielaard:
> Aha. OK. I might be dense, but I don't think I am the only person not
> immediately making the link between these methods and the RFC 2133
> "Interface Identification" and how they are used as described in RFC
> 2292 for selecting the outgoing interface.
For the record, RFC 213
* David M. Lloyd:
> Doing this: UnixSocketChannel.open(String) or similar seems more
> correct to me.
You need to do this twice, for SOCK_STREAM and SOCK_DGRAM.
> If you go the route of using SocketChannel.open(SocketAddress), for
> example, now you've got instanceof checks for each socket type.
* Alan Bateman:
[Extensible socket types]
> This is a good topic. For stream and datagram oriented protocols then
> it would indeed be desirable to allow for communication domains other
> than IP. In theory it should be possible to use a SocketImpl for this
> but there are checks in the Socket AP
* Christopher Hegarty:
> I just sent a mail to the nio-discuss [1] mailing list requesting
> feedback on a proposed Java API for SCTP. If you are interested in
> this topic please read this mail which provides a some details and a
> link to the API. Feedback is really welcome.
I've been wondering
* Alan Bateman:
> Search for a ~1996 paper on DNS spoofing attacks from Princeton
> University as that gives useful background on this topic and is the
> original reason for the caching.
That paper is probably out of date by now. Interaction of expiry and
poisoning hasn't been fully understood b
* cormac mullally:
> Firstly as some of you may know "type 0 routing header" has caused a
> bit of controversy (see http://www.natisbad.org/ especially this
> presentation http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf)
> and it seems that there is some security concerns. Does anyone have
>
39 matches
Mail list logo
