Beware of Biggest Fake conference in computer science

Beware of Biggest Fake conference in computer science

If you have any plans of participating in the world’s biggest 
fake computer science conference then you must look at the website https://sites.google.com/site/worlddump1

If the above link didn't work then see

http://worldcomp-fake-bogus.blogspot.com  
or
https://sites.google.com/site/dumpconf
or Google search using keywords: worldcomp, fake

Code review: 8010464: Evolve java networking same origin policy

Hi,

This is the webrev for the HttpURLPermission addition.
As well as the new permission class, the change
includes the use of the permission in java.net.HttpURLConnection.

The code basically checks for a HttpURLPermission in plainConnect(),
getInputStream() and getOutputStream() for the request and if
the caller has permission the request is executed in a doPrivileged()
block. When the limited doPrivileged feature is integrated, I will
change the doPrivileged() call to limit the privilege elevation to a single
SocketPermission (as shown in the code comments).

The webrev is at http://cr.openjdk.java.net/~michaelm/8010464/webrev.1/

Thanks
Michael

SSL/TLS cipher selection

Hello,

I discovered some unexpected behavior in how Java chooses cipher suites for 
SSL/TLS. I wanted to know if its method of cipher suite selection is 
documented somewhere so I could understand why it's not working right for me 
in certain cases. Notably, if I configure this preference list:

    public static String[] CIPHERS = {
        "TLS_RSA_WITH_AES_128_CBC_SHA",
        "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
        "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
        "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
        "SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA",
        "TLS_RSA_WITH_AES_256_CBC_SHA",
        "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
    };

and then use the default "openssl ciphers" list for OpenSSL 1.0.1e, only 
SSL_RSA_WITH_3DES_EDE_CBC_SHA gets selected even though the server preference 
places it below TLS_RSA_WITH_AES_128_CBC_SHA, which, while allowed by the RFC, 
is not what is normally done, and will reduce performance quite a bit.

When you look at the "openssl ciphers" list, you can see that they ranked 3DES 
above AES128 on their side, but it would really be better if the server 
preference took precedence instead of the client preference.

Another thing which would be nice to fix, would be if the javax.net.debug=ssl 
output would print the server-side cipher preferences in effect as well as the 
client-side ones like it does presently.

Non-standard socket options?

Incorrect handling of HTTP/1.1 "Expect: 100-continue" in HttpURLConnection

suggestions for improvement in java.net APIs

Howdy,

we investigated the APIs of java.net (OpenJDK Build b147) and published
our findings in Ottawa Linux Symposium 2012:

http://nw.dreamhosters.com/ols/ols2012/ols2012-komu.pdf

We two types of improvements to java.net disclosed in full detail in
section 4.3.1 of the publication. First, we suggest to fix a bug related
to UDP in multihoming scenarios (i.e., a host has multiple IP
addresses). Second, we suggest improvements that can improve either the
user experience (i.e. by improving latency in IPv6 environments) or
developers (after all, frameworks are a conveniency for the developers).
The suggestions for improvements are briefly summarized below.

Multihoming bug
---------------
* R3.2: Server-side multihoming for UDP does not work properly. The
framework should use SO_BINDTODEVICE option or sendmsg()/recvmsg()
interfaces in a proper way.

Suggested improvements (for better end-user or developer experience)
--------------------------------------------------------------------
* R2.2: The framework does not support parallel DNS look ups over IPv4
and IPv6 to optimize latency
* R3.3: The framework does not support parallel connect() over IPv4 and
IPv6 to minimize the latency for connection set-up

Please refer to  section 4.3.4 in the publication for a more elaborate
discussion of the improvements.

RFR JDK7188517

RFR 6594296: NetworkInterface.getHardwareAddress returns zero length byte array

This is a conformance issue where getHardwareAddress may incorrectly 
return a zero length byte array, rather than null. The spec allows for 
null, in fact it requires it for such cases. The issue is reproducible 
with newer versions of Windows, with IPv6 enabled.

The problem is in src/windows/native/java/net/NetworkInterface_winXP.c. 
PhysicalAddressLength can be 0, in which case the byte array should not 
be created, rather than creating a 0 length byte[].

 From msdn:
   "PhysicalAddressLength

    Type: DWORD

    The length, in bytes, of the address specified in the
    PhysicalAddress member. For interfaces that do not have
    a data-link layer, this value is zero."

Webrev:
   http://cr.openjdk.java.net/~chegar/6594296/webrev.00/webrev/

-Chris.

API change for 8010464: Evolve java networking same origin policy

Hi,

The is the suggested API for one of the two new JEPs recently submitted.

This is for JEP 184: HTTP URL Permissions

The idea here is to define a higher level http permission class
which "knows about" URLs, HTTP request methods and headers.
So, it is no longer necessary to grant blanket permission for any kind
of TCP connection to a host/port. Instead a HttpURLPermission restricts
access to only the Http protocol itself. Restrictions can also be imposed
based on URL paths, specific request methods and request headers.

The API change can be seen at the URL below:

http://cr.openjdk.java.net/~michaelm/8010464/api/

In addition to defining a new permission class, HttpURLConnection
is modified to make use of it and the documentation change describing this
can be seen at the link below:

http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html

All comments welcome.

Thanks

Michael.

SocketImplFactory

Are there any real-life examples of using SocketImplFactory?

I was hoping to find a way to redirect selected sockets, by IP address, to a different implementation of
sockets that could take advantage of a high-speed connection.  For this to work, I'd need to be able to
delegate all other sockets back to the standard implementation.  Unfortunately, it appears that most of
the classes I'd need to access are package-private so this approach wouldn't work.

A requirement is that applications would not require any source changes.  They would be unmodified and just
have things redirect dynamically when they create a Socket or ServerSocket.  I was thinking that this
feature would be enabled through a class that loads as a service and calls setSocketFactory.

Inheriting from Socket or ServerSocket doesn't help since I can't change the applications and I can't make
those classes revert to the default implementation when I don't want to use mine.

Is there any hope of something like this working?

Tom Salter  |  Software Engineer  |  Java & Middleware Development 
Unisys  |  2476 Swedesford Road  |  Malvern, PA  19355   |  610-648-2568 |  N385-2568 

RFR-JDK8012108