Re: RFR: 8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref) [v2]
On Wed, 25 Nov 2020 08:53:18 GMT, Сергей Цыпанов wrote: >> Hello, while working with `java.net.URL` I've found unused package-private >> method `URL.set(String protocol, String host, int port, String file, String >> ref)` which can be safely removed from JDK. Testing: tier1, tier2 >> >> Could someone crate an issue for tracking of this simple change? > > Сергей Цыпанов has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains two additional > commits since the last revision: > > - Merge branch 'master' into url > - 8255477: Remove unused method URL.set(String protocol, String host, int > port, String file, String ref) Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/779
Re: RFR: 8255477: Remove unused method URL.set(String protocol, String host, int port, String file, String ref)
On Thu, 26 Nov 2020 14:48:14 GMT, Daniel Fuchs wrote: >> @dfuch >> Recent run has some errors: >> java/net/MulticastSocket/SetOutgoingIf.java: Re-test IPv6 (and specifically >> MulticastSocket) with latest Linux & USAGI code >> java/net/MulticastSocket/Test.java: IPv4 and IPv6 multicasting broken on >> Linux >> java/time/test/java/time/format/TestDateTimeFormatterBuilder.java: >> sun/security/pkcs11/Secmod/AddTrustedCert.java: make sure we can add a >> trusted cert to the NSS KeyStore module >> sun/security/util/HostnameMatcher/NullHostnameCheck.java: Verify hostname >> returns an exception instead of null pointer when creating a new engine >> First two are related to unavailable network, for them I have `Unexpected >> exception for MulticastSender(wlp1s0): java.net.SocketException: Network is >> unreachable` and `java.net.SocketException: Network is unreachable` >> >> For the third I have >> test >> test.java.time.format.TestDateTimeFormatterBuilder.test_dayPeriodParse(NARROW, >> en_US, 1, 30, "at night"): failure >> java.time.format.DateTimeParseException: Text 'at night' could not be >> parsed, unparsed text found at index 1 >> at >> java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2055) >> at >> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1880) >> at >> test.java.time.format.TestDateTimeFormatterBuilder.test_dayPeriodParse(TestDateTimeFormatterBuilder.java:645) >> Which also seems to be not related to `URL`. >> For the forth I have >> --System.err:(21/1603)-- >> java.security.KeyStoreException: >> sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ATTRIBUTE_READ_ONLY >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1050) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetCertificateEntry(P11KeyStore.java:516) >> at >> java.base/java.security.KeyStore.setCertificateEntry(KeyStore.java:1228) >> at AddTrustedCert.main(AddTrustedCert.java:106) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:831) >> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: >> CKR_ATTRIBUTE_READ_ONLY >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_CreateObject(Native >> Method) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.storeCert(P11KeyStore.java:1568) >> at >> jdk.crypto.cryptoki/sun.security.pkcs11.P11KeyStore.engineSetEntry(P11KeyStore.java:1046) >> ... 9 more >> And the last one is >> javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is >> disabled or cipher suites are inappropriate) >> at >> java.base/sun.security.ssl.HandshakeContext.(HandshakeContext.java:172) >> at >> java.base/sun.security.ssl.ClientHandshakeContext.(ClientHandshakeContext.java:98) >> at >> java.base/sun.security.ssl.TransportContext.kickstart(TransportContext.java:238) >> at >> java.base/sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:107) >> at NullHostnameCheck.handshake(NullHostnameCheck.java:124) >> at NullHostnameCheck.main(NullHostnameCheck.java:100) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) >> at java.base/java.lang.Thread.run(Thread.java:831) > > Thanks Sergey! > > These errors are strange but I agree: they don't seem to be related to URL; > Let me try to build & test your changes in our test system. > > best regards, > > -- daniel I believe the errors are caused by the branch not being uptodate with the master. After rebasing my tests have come back green. Unless I hear objections, I'll sponsor this fix for you. - PR: https://git.openjdk.java.net/jdk/pull/779
icmp and raw sockets on linux
I'm new to the list and although I have skimmed through the archive and the open bugs to look at discussions about icmp echo for non root users in linux, I didn't see this solution. We are all aware that you need to have root privileges in order to use raw sockets. It recently came to my attention however that my copy of ping isn't setuid root which made me wonder how the iputils maintainer managed to send an icmp packet as a non root user. Turns out it's surprisingly trivial, they use SOCKET_DGRAM instead of SOCKET_RAW and the body of the datagram is an icmp structure. Now, being as it's not a raw socket, we can't control the contents of the ident portion of the icmp header, it gets overwritten by the kernel (the sequence is untouched by the kernel however). Now, since the kernel sets the ident field "en passant" I know of no way to know what that value was set to which means correlating and identifying the echo reply needs to do something other than use the ident field. What I tried was to put the user PID in the data structure right after the timestamp, and use that for comparison when we get an icmp reply. It all seems to check out (at least on my machine,) the icmp packets look good in wireshark, so the first thing I'm wondering is what the catch must be, because this seems like a simple solution and I'm wondering why it was never done like this. I realize that there is a process to have submit patches, and I have no problem with that but I really had to ask the question here first to see if there was something I was overlooking. I can provide a patch file if anyone wants to take a look, it's about six small changes in Inet4AddressImpl.c Cheers, Jamie
Re: icmp and raw sockets on linux
Hello, Good find Jamie, The change for this is from 2010, so it should be in all recent Linux kernels (not sure if this means no fallback is needed - maybe keep the tcp fallback) https://lwn.net/Articles/420800/ BTW the article also,mentions there is a way to do this in MacOS also. Gruss Bernd -- http://bernd.eckenfels.net Von: net-dev im Auftrag von Jamie Le Tual Gesendet: Samstag, November 28, 2020 3:43 AM An: net-dev@openjdk.java.net Betreff: icmp and raw sockets on linux I'm new to the list and although I have skimmed through the archive and the open bugs to look at discussions about icmp echo for non root users in linux, I didn't see this solution. We are all aware that you need to have root privileges in order to use raw sockets. It recently came to my attention however that my copy of ping isn't setuid root which made me wonder how the iputils maintainer managed to send an icmp packet as a non root user. Turns out it's surprisingly trivial, they use SOCKET_DGRAM instead of SOCKET_RAW and the body of the datagram is an icmp structure. Now, being as it's not a raw socket, we can't control the contents of the ident portion of the icmp header, it gets overwritten by the kernel (the sequence is untouched by the kernel however). Now, since the kernel sets the ident field "en passant" I know of no way to know what that value was set to which means correlating and identifying the echo reply needs to do something other than use the ident field. What I tried was to put the user PID in the data structure right after the timestamp, and use that for comparison when we get an icmp reply. It all seems to check out (at least on my machine,) the icmp packets look good in wireshark, so the first thing I'm wondering is what the catch must be, because this seems like a simple solution and I'm wondering why it was never done like this. I realize that there is a process to have submit patches, and I have no problem with that but I really had to ask the question here first to see if there was something I was overlooking. I can provide a patch file if anyone wants to take a look, it's about six small changes in Inet4AddressImpl.c Cheers, Jamie
