Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 10 Sep 2021 09:23:52 GMT, Masanori Yano wrote: > Could you please review the 8233674 bug fixes? > This problem is caused by the antivirus software opening the file for a short > time, so CreateFile() should be retried. Thank you for your comment. According to Microsoft KB316609, CreateFile() should be tried again a short time later. I think JarURLConnection should also be retried when antivirus software holds some files. https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/316609 - PR: https://git.openjdk.java.net/jdk/pull/5460
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai wrote: >> Julia Boes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> correct path handling > > src/jdk.httpserver/share/classes/module-info.java line 55: > >> 53: * [-o none|info|verbose] [-h to show >> options] >> 54: *Options: >> 55: *-b, --bind-address- Address to bind to. Default: 0.0.0.0 (all >> interfaces). > > I understand that the purpose of this simple server is for development and > testing only. But even then, for security considerations, would it be more > appropriate to default the bind address to a loopback address instead of > making it accessible potentially to entire public? In the past, application > servers which used to bind to all interfaces by default have now moved to > using the loopback address as a default to avoid such accidental exposing of > the server. We did consider defaulting to the loopback address, but this would limit the usefulness of the server too much in the default configuration as it can only be accessed from localhost. The goal of this JEP is an out-of-the-box web server with easy setup, so in this case we favour usability. The purpose of a web server is to make things accessible on the web so it is assumed that the developer is familiar with the terms this comes with. The concern of accidental exposure is alleviated by the informative output printed at start up, e.g. ```~ $ java-sb -m jdk.httpserver Serving /current/directory and subdirectories on 0.0.0.0:8000 http://123.456.7.891:8000/ ... Considering your point though, we can spell out all interfaces and describe the URL more clearly: ```~ $ java-sb -m jdk.httpserver Serving /current/directory and subdirectories on 0.0.0.0 (all interfaces) port 8000 Localhost URL: http://123.456.7.891:8000/ ... - PR: https://git.openjdk.java.net/jdk/pull/5505
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
Hello Julia, On 17/09/21 3:14 pm, Julia Boes wrote: On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai wrote: Julia Boes has updated the pull request incrementally with one additional commit since the last revision: correct path handling src/jdk.httpserver/share/classes/module-info.java line 55: 53: * [-o none|info|verbose] [-h to show options] 54: *Options: 55: *-b, --bind-address- Address to bind to. Default: 0.0.0.0 (all interfaces). I understand that the purpose of this simple server is for development and testing only. But even then, for security considerations, would it be more appropriate to default the bind address to a loopback address instead of making it accessible potentially to entire public? In the past, application servers which used to bind to all interfaces by default have now moved to using the loopback address as a default to avoid such accidental exposing of the server. We did consider defaulting to the loopback address, but this would limit the usefulness of the server too much in the default configuration as it can only be accessed from localhost. The goal of this JEP is an out-of-the-box web server with easy setup, so in this case we favour usability. The purpose of a web server is to make things accessible on the web so it is assumed that the developer is familiar with the terms this comes with. The concern of accidental exposure is alleviated by the informative output printed at start up, e.g. ```~ $ java-sb -m jdk.httpserver Serving /current/directory and subdirectories on 0.0.0.0:8000 http://123.456.7.891:8000/ ... I think this is still a really big risk. I say this based on some of my past experience with application servers (JBoss AS) where in older releases it used to do this same thing of binding to 0.0.0.0 by default and how that had lead to numerous (production) instances ending up being vulnerable. In the case there, the management console ended up being exposed and almost anyone over the internet could just access it to shutdown the server (through a JMX MBean). In the case of this simple server being proposed, I think it's a lot more riskier because unlike in the case of the application servers where the server would have preventive measures that wouldn't allow local filesystem access, the current server being proposed will end up exposing the user's local filesystem to the internet. It's my opinion and experience that log messages no matter how much they scream out, won't prevent this default out of the box usage. I'm not saying 0.0.0.0 should be disabled, but instead, IMO it should be the user who should explicitly use -b 0.0.0.0 to do that, so that they are at least responsible and aware of what they are doing. -Jaikiran
Re: RFR: 8273655: content-types.properties files are missing some common types [v2]
On Thu, 16 Sep 2021 18:06:53 GMT, Phil Race wrote: > I don't understand why these files are platform-specific. > And if each platform port does need one, where is the one for macOS ? I'm not an expert in the area, it's probably down to historic reasons? The Unix version would be for all Unix varieties, unless a more specific source file is provided (thanks to @Michael-Mc-Mahon). - PR: https://git.openjdk.java.net/jdk/pull/5506
Re: New candidate JEP: 418: Internet-Address Resolution SPI
We had a discussion about the naming and decided to go with InetAddressResolverProvider and InetAddressResolver names. I will update the JEP text to reflect that. With Kind Regards, Aleksei From: Aleksej Efimov Sent: Thursday, September 9, 2021 9:12 PM To: Mark Reinhold Cc: net-dev@openjdk.java.net ; Alan Bateman Subject: Re: New candidate JEP: 418: Internet-Address Resolution SPI Hi Mark, Given Alan's input on "name service" term and providers naming convention, do you still think that we should rename "java.net.spi.InetNameServiceProvider"? If yes, then maybe it would be better to name classes `InetAddressResolverProvider` and `InetAddressResolver` - it might help to highlight that it is used by `InetAddress` API. Thanks, Aleksei From: Alan Bateman Sent: Saturday, September 4, 2021 10:09 AM To: Mark Reinhold ; Aleksej Efimov Cc: net-dev@openjdk.java.net Subject: Re: New candidate JEP: 418: Internet-Address Resolution SPI On 03/09/2021 22:38, mark.reinh...@oracle.com wrote: > A suggestion, if I may ... > > Consider using the term “resolver” instead of “name service,” especially > in the names of the SPI classes and interfaces. > > That would avoid confusing the service of looking up names and addresses > with the service of providing a service to look up names and addresses. > That is, the service you’re defining is a provider of name services, > i.e., a name service service. This can lead to many annoying questions. > Is an instance of the SPI class `InetNameService` a name service, or a > name service service provider? Why isn’t the SPI class > `InetNameServiceProvider` named `InetNameServiceServiceProvider`? > > Using “resolver” would let you talk more simply about a “resolver > service,” and have clear and concise class and interface names (e.g., > `InetResolverProvider` and `InetResolver`). Thanks, it is always useful to get another set of eyes on this. We've been using "NameService" in all prototypes/exploration to date because "name service" is the term used in the API docs since around JDK 1.4. It might mean changing the phrasing in some of the existing API docs. For service providers then naming convention has mostly been to append "Provider". I think you are right here, it may be ambiguous or confusing when appended to "InetNameService". The intention of course was that the provider class be a factory for InetNameService objects, not "InetName". -Alan
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
Hello Bernd, On 17/09/21 3:37 am, Bernd Eckenfels wrote: I also wonder if it makes sense to either only serve files with public permissions, or at least Filter some critical files like .ssh/* and *.jks. FWIW - From what I can see in the proposed implementation as well as the JEP text, hidden files and symbolic links aren't served. So it should prevent listing/serving .ssh/ directory. -Jaikiran
Re: RFR: 8233674: JarURLConnection.getJarFile throws Exception if some process is holding the file
On Fri, 17 Sep 2021 08:46:52 GMT, Masanori Yano wrote: > Thank you for your comment. According to Microsoft KB316609, CreateFile() > should be tried again a short time later. I think JarURLConnection should > also be retried when antivirus software holds some files. > https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Archive/316609 This seems to be just general advice about dealing with sharing violations. I think it would be useful to hear from the Microsoft folks on whether every application on Windows is expected to retry to workaround interference from virus checkers or whether this is something that should be fixed by the virus checker vendors. If the JDK ends up putting in a workaround then it will require more broader changes, things will work inconsistently if limited to opening zip files and java.io. - PR: https://git.openjdk.java.net/jdk/pull/5460
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main method is run when the above >> command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given >> directory, similar to existing alternatives on other platforms and >> convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and >> customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional > commit since the last revision: > > correct path handling > _Mailing list message from [Jaikiran Pai](mailto:jai.forums2...@gmail.com) on > [build-dev](mailto:build-...@mail.openjdk.java.net):_ > > Hello Julia, > > On 17/09/21 3:14 pm, Julia Boes wrote: > > > On Thu, 16 Sep 2021 14:05:52 GMT, Jaikiran Pai wrote: > > > > Julia Boes has updated the pull request incrementally with one > > > > additional commit since the last revision: > > > > correct path handling > > > > src/jdk.httpserver/share/classes/module-info.java line 55: > > > > > > > > > > 53: * [-o none|info|verbose] [-h to > > > > show options] > > > > 54: *Options: > > > > 55: *-b, --bind-address- Address to bind to. Default: 0.0.0.0 > > > > (all interfaces). > > > > I understand that the purpose of this simple server is for development > > > > and testing only. But even then, for security considerations, would it > > > > be more appropriate to default the bind address to a loopback address > > > > instead of making it accessible potentially to entire public? In the > > > > past, application servers which used to bind to all interfaces by > > > > default have now moved to using the loopback address as a default to > > > > avoid such accidental exposing of the server. > > > > We did consider defaulting to the loopback address, but this would > > > > limit the usefulness of the server too much in the default > > > > configuration as it can only be accessed from localhost. The goal of > > > > this JEP is an out-of-the-box web server with easy setup, so in this > > > > case we favour usability. The purpose of a web server is to make things > > > > accessible on the web so it is assumed that the developer is familiar > > > > with the terms this comes with. > > > > > > The concern of accidental exposure is alleviated by the informative output > > printed at start up, e.g. > > ```~ $ java-sb -m jdk.httpserver > > Serving /current/directory and subdirectories on 0.0.0.0:8000 > > http://123.456.7.891:8000/ ... > > I think this is still a really big risk. I say this based on some of my > past experience with application servers (JBoss AS) where in older > releases it used to do this same thing of binding to 0.0.0.0 by default > and how that had lead to numerous (production) instances ending up being > vulnerable. In the case there, the management console ended up being > exposed and almost anyone over the internet could just access it to > shutdown the server (through a JMX MBean). > > In the case of this simple server being proposed, I think it's a lot > more riskier because unlike in the case of the application servers where > the server would have preventive measures that wouldn't allow local > filesystem access, the current server being proposed will end up > exposing the user's local filesystem to the internet. It's my opinion > and experience that log messages no matter how much they scream out, > won't prevent this default out of the box usage. > > I'm not saying 0.0.0.0 should be disabled, but instead, IMO it should be > the user who should explicitly use -b 0.0.0.0 to do that, so that they > are at least responsible and aware of what they are doing. > > -Jaikiran Thanks for sharing your experience on this, it's appreciated. 0.0.0.0 is common default for Apache httpd [1], Ngnix [2], the Python web server [3]. This being said, I want to make sure we're taking the right decision here so let me seek some further advice on this. [1] http://httpd.apache.org/docs/2.4/bind.html [2] https://docs.nginx.com/nginx/admin-guide/web-server/web-server/ [3] https://github.com/python/cpython/blob/3.4/Lib/http/server.py - PR: https://git.openjdk.java.net/jdk/pull/5505
Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v3]
On Thu, 16 Sep 2021 10:14:47 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the >> command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` >> module, an implementation class whose main method is run when the above >> command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given >> directory, similar to existing alternatives on other platforms and >> convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and >> customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request incrementally with one additional > commit since the last revision: > > correct path handling > _Mailing list message from [Jaikiran Pai](mailto:jai.forums2...@gmail.com) on > [core-libs-dev](mailto:core-libs-...@mail.openjdk.java.net):_ > > Hello Bernd, > > On 17/09/21 3:37 am, Bernd Eckenfels wrote: > > > I also wonder if it makes sense to either only serve files with public > > permissions, or at least Filter some critical files like .ssh/* and *.jks. > > FWIW - From what I can see in the proposed implementation as well as the > JEP text, hidden files and symbolic links aren't served. So it should > prevent listing/serving .ssh/ directory. > > -Jaikiran File system access is checked for the root directory and the requested resource (summarized in the CSR [1]). You're right that hidden files, symbolic links, and not-readable files are not served. Looking at the example of `.ssh/*`, I realize we missed the case where a component of the request path is hidden (or not readable), rather than the requested resource itself. For example, if `/` is the server's root directory, a request of `http://host:port/.ssl/config` would be successful because config is not hidden. A request of `http://host:port/.ssl` would get a 404. I'll update this to apply the isHidden and isReadable checks to the requested resource *as well as* all components of its path. No further group/owner/other permissions are checked - that's a can of worms we didn't want to get in to, given that this server is really not appropriate for serving file hierarchies that contain sensitive information. Again, it's a simple tool for development and testing purposes only. [1] https://bugs.openjdk.java.net/browse/JDK-8272571 - PR: https://git.openjdk.java.net/jdk/pull/5505
Re: New candidate JEP: 418: Internet-Address Resolution SPI
2021/9/17 3:03:25 -0700, aleksej.efi...@oracle.com: > We had a discussion about the naming and decided to go with > InetAddressResolverProvider and InetAddressResolver names. > I will update the JEP text to reflect that. That sounds fine. - Mark
