configuration files in ${java.home}/lib/security
As part of preparing for modules in the future [1], we need to look at
configuration (and other) files in the JDK and see whether such files
could eventually move to module-private locations.
There are several files in ${java.home}/lib/security and I'm trying to
get a feel for how common it is for developers or customers to edit
them. The specification for java.security.Policy and
java.security.KeyStore define the name/location of java.security and we
need to decide whether these can be changed to non-normative references.
I know from discussion with Sean on jigsaw-dev and elsewhere that some
customers may change the preference order of providers but this is
something that needs to be re-examined anyway as part of deploying
security providers as service providers. I'm mostly interested in the
other settings at this time and whether it is common or not to change
them. Also the other files, including java.policy. I realize we might
not have actual data but as such files are in the JDK image then I could
imagine it being problematic when upgrading the JDK.
Thanks,
-Alan.
[1] http://openjdk.java.net/jeps/162
hg: jdk8/tl/jdk: 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions; ...
Changeset: 32452042b781 Author:naoto Date: 2012-10-16 10:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32452042b781 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) doesn't work as expected with custom extensions 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred to the custom service provider 8000615: JRE adapter: timezone name of en_US is changed when extension directory is added Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! test/java/util/Locale/LocaleProviders.java ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.sh ! test/java/util/PluggableLocale/ProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java ! test/java/util/PluggableLocale/providersrc/LocaleNameProviderImpl.java
Re: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server
BTW, both 7068321 and 8000954 are in Open, should be In Progress.
On 10/15/2012 6:27 PM, Xuelei Fan wrote:
On 10/16/2012 7:12 AM, Brad Wetmore wrote:
Looks good.
The main update is to add final keyword to the new methods in
SSLParamaters. I prefer to use the final because I don't see a
requirement to override them.
Let me know when the new CCC is ready, I'll approve it.
The CCC for this fix, 7068321 has been finalized. I submitted a new CCC
to add the final keyword:
https://jbs.oracle.com/bugs/browse/JDK-8000954
I will fill the new CCC after the push of 7068321.
Are you going to contact IETF?
Yes, I will.
Almost there.
I think we get all spec review, code review done.
I think so.
I will push the
changeset after the CCC get approved, and pay more time on CPU bugs.
You could push both together and put everything in just one changeset,
but of course up to you.
I don't think there's anything else for me to do, let me know if you're
waiting on something.
Brad
Thanks,
Xuelei
Brad
On 10/13/2012 6:26 AM, Xuelei Fan wrote:
New webrev: http://cr.openjdk.java.net./~xuelei/7068321/webrev.14/
The main update is to add final keyword to the new methods in
SSLParamaters. I prefer to use the final because I don't see a
requirement to override them. But I can go with the version with or
without the final keyword. I think you properly don't need to review
other parts of the webrev any more, no other major update.
Thanks,
Xuelei
On 10/13/2012 10:17 AM, Xuelei Fan wrote:
I have no access to office network, just a quick reply. I want add
final keyword for the new methods in SSLParameters. See below.
Sent from my iPad
On Oct 13, 2012, at 8:00 AM, Brad Wetmore
bradford.wetm...@oracle.com wrote:
I guess you didn't need to have me as reviewer before going final
with
the CCC?
The CCC has been finalized. ;-) I though you have done with spec
review.
Anyway, we still can make updates on specification within new bugs.
That's fine, I just wasn't sure if you needed someone to approve
the final version of the spec to move it to the next state.
Just a comment:
459/468: Currently you have serverNames and sniMatchers as package
private variables, so the ClientHandshaker/ServerHandshaker *could*
inherit these variables rather than have a separate get methods.
Or you
could make them private and keep the get calls.
Good catch!
I can look at your latest if you like, but probably not necessary.
I will send the new webrev tonight my time.
I'm just not seeing why this implies that it requires *EVERY* name
must
match. This just says we can do one of two things upon receipt of an
unrecognized hostname: continue on, or alert/close. We can be very
restrictive (ALL/AND) or less so (at least one/OR), and still be
within
the RFC, I think.
I agree with your parser.
In our spec, it is required that once a SNIMatcher is defined, it
will be used to recognized the server name in the SNI extension.
Where? We do say in SNIMatcher:
Servers can use Server Name Indication (SNI) information to
decide if
specific {@link SSLSocket} or {@link SSLEngine} instances should
accept a connection.
But I don't think we have ever said that it MUST match or must
match all
or even what the implementation must do if there is a match
failure. Nor
should we specify that in the API, IMHO. That's implementation
behavior.
I may have different options on this point. I think, it must be a
specified behavior in Java. Otherwise, it is very confusing about
how to
use 1+ server names in server side.
I am going suggest we ask for guidance from IETF about this. It is
not clear from RFC 6066 how to handle multiple SNI types, even
reading very generously between the lines. See below.
Let's start from the logic of the design. If the specification is not
clear, I will rewrite the spec according to our agreement.
Let's start from the requirement. I think once a SNIMatcher is defined
in SSL parameters, it MUST be used to perform the match operations if
the corresponding server name appears in the SNI extension.
Otherwise,
what will happens? See the example:
1. SNI extension contains HostName, www.example.com.
2. Server side defines SNIMatcher for HostName, to accept
www.example.org. Server does not accept www.example.com.
3. What's the result of the handshake? Is the SNI extension is
accetable?
www.example.org != www.example.com. I would say fail handshake with
unknown_hostname.
If we do not define the spec about how to use SNIMatcher. The
answer to
#3 is unclear. Because if a SNIMatcher may be used to perform match
operation, and may be not used to perform match operation, then the
server may accept the SNI extension, may ignore the SNI extension, may
reject the SNI extension. It is useless to define SNIMatcher.
I think the requirement is clear that it is a must to use
SNIMatcher to
perform the match operation if the corresponding server name
appears in
the SNI
Re: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server
On 10/17/2012 9:30 AM, Xuelei Fan wrote: On 10/17/2012 4:57 AM, Brad Wetmore wrote: You could push both together and put everything in just one changeset, but of course up to you. Good. Please review the CCC request, I will fast-track the request. http://ccc.us.oracle.com/8000954 I don't think there's anything else for me to do, let me know if you're waiting on something. I think you are done, ;-) except the above CCC review. I still need to wait for the approval of the CCCs. Thanks, Xuelei
Re: Code review request, JEP 114, 7068321 Support TLS Server Name Indication (SNI) Extension in JSSE Server
Approved. Brad On 10/16/2012 6:30 PM, Xuelei Fan wrote: On 10/17/2012 9:30 AM, Xuelei Fan wrote: On 10/17/2012 4:57 AM, Brad Wetmore wrote: You could push both together and put everything in just one changeset, but of course up to you. Good. Please review the CCC request, I will fast-track the request. http://ccc.us.oracle.com/8000954 I don't think there's anything else for me to do, let me know if you're waiting on something. I think you are done, ;-) except the above CCC review. I still need to wait for the approval of the CCCs. Thanks, Xuelei
hg: jdk8/tl/langtools: 8000673: remove dead code from HtmlWriter and subtypes
Changeset: 2013982bee34 Author:jjg Date: 2012-10-16 21:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2013982bee34 8000673: remove dead code from HtmlWriter and subtypes Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java
