Hello are you fine with changing from file.getAbsolutePath()to
file.getName() ?
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.8/src/java.base/share/classes/java/util/jar/Manifest.java.frames.html
206 static String getErrorPosition(String filename, final int lineNumber) {
20
Hi Matthias,
I think it would be enough to drop the privileged section and just return
"filename" as is. (without conveting to a file object).
I also agree with Sean that the common parts of the new
src/java.base/share/classes/sun/security/util/SecurityProperties.java should be
aligned with sr
> I think it would be enough to drop the privileged section and just return
> "filename" as is. (without conveting to a file object).
OK, any objections on this ?
> I also agree with Sean that the common parts of the new
> src/java.base/share/classes/sun/security/util/SecurityProperties.java sho
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
- SocketExceptions class has been adjusted to new
sun.security.util.SecurityProperties
- Attributes getErrorPosition adjusted (see proposal of Christoph " I think
it would be enough to drop the privileged section and just
On 9/8/18 11:42 AM, Wang Weijun wrote:
Thinking about this again. Looks like the absolute path is not necessary. Even
if there are multiple files using the same name, they will be in different
directories, no matter absolute or relative. Suppose the jarPath info is used
for debugging purpose m
On 9/10/18 4:21 AM, Baesken, Matthias wrote:
I think it would be enough to drop the privileged section and just return
"filename" as is. (without conveting to a file object).
OK, any objections on this ?
No, this is fine with me.
--Sean
> On Sep 10, 2018, at 9:59 PM, Baesken, Matthias
> wrote:
>
> New webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
Looks fine to me.
>
> - SocketExceptions class has been adjusted to new
> sun.security.util.SecurityProperties
> - Attributes getErrorPosition adjuste
On 9/10/18 9:59 AM, Baesken, Matthias wrote:
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.9/
- SocketExceptions class has been adjusted to new
sun.security.util.SecurityProperties
- Attributes getErrorPosition adjusted (see proposal of Christoph " I think it would
be
> On Sep 10, 2018, at 10:35 PM, Sean Mullan wrote:
>
>> After the changes I wonder - should the jarPath category be renamed to
>> jarFile (or something else) ?
>
> Yes, renaming it to "jarFile" makes more sense. You will need to update the
> CSR with this change too.
Well, maybe eit
Hi Sean, Max,
do you think we need property jdk.includeInExceptions=jar at all, if
we don't resolve the absolute path?
@Matthias:
small remark to the code:
src/java.base/share/classes/sun/security/util/SecurityProperties.java
36 public static String privilegeGetOverridable(String propName) {
> On Sep 10, 2018, at 10:46 PM, Langer, Christoph
> wrote:
>
> Hi Sean, Max,
>
> do you think we need property jdk.includeInExceptions=jar at all,
> if we don't resolve the absolute path?
I think so. File path is still sensitive.
In fact, I tend to believe people usually use absolute path
Xuelei,
Here is the latest webrev:
http://cr.openjdk.java.net/~apetcher/8171279/webrev.04/
I modified the TLS implementation so that it uses X509EncodedKeySpec
when interacting with the provider. I did a small amount of refactoring
in X509Key to expose the functionality I needed to do this.
See inline below.
It also occurred to me that we could use Provider properties here. We
have the "ImplementedIn" property, and we can similarly add a standard
"Branchless" property. I think my preferred solution is still to use
separate providers, and perhaps use a read-only "Branchless" prope
On 9/10/2018 8:14 AM, Adam Petcher wrote:
Xuelei,
Here is the latest webrev:
http://cr.openjdk.java.net/~apetcher/8171279/webrev.04/
I modified the TLS implementation so that it uses X509EncodedKeySpec
when interacting with the provider. I did a small amount of refactoring
in X509Key to exp
Can I have the links to the new formulas that you will be used? Are
they part of any current standards?
Thanks,
Xuelei
On 8/23/2018 10:50 AM, Adam Petcher wrote:
I'm starting work on yet another ECC JEP[1], this time with the goal of
developing improved implementations of existing algorithms,
On 9/7/18 9:31 PM, Weijun Wang wrote:
Please review the change at
http://cr.openjdk.java.net/~weijun/8205507/webrev.00/
Looks good.
--Sean
Here I cached the keys for each signature method. Running 100 times on
solaris-sparcv9 and the longest duration is 10 minutes, much shorter than t
Hi,
> > do you think we need property jdk.includeInExceptions=jar at
> all, if we don't resolve the absolute path?
>
> I think so. File path is still sensitive.
>
> In fact, I tend to believe people usually use absolute paths for JAR files (or
> maybe made absolute by using a file:// URL somewhe
The paper[1] containing the proposed formulas is referenced in the JEP.
As far as I know, they are not part of any standard. If you know of any
standardized, complete EC point arithmetic formulas, then let me know. I
think it is okay to use these formulas as long as they produce the same
result
Please review a patch to have the Source Launcher be able to work when a
security manager is enabled.
There are 4 parts to the work: an update to the default policy file, an
update to the source launcher itself, updates to tests, and a custom
security manager to help with testing.
1. src/jav
On 09/10/2018 08:50 AM, Adam Petcher wrote:
See inline below.
It also occurred to me that we could use Provider properties here. We
have the "ImplementedIn" property, and we can similarly add a standard
"Branchless" property. I think my preferred solution is still to use
separate providers, a
On 9/10/2018 1:23 PM, Adam Petcher wrote:
The paper[1] containing the proposed formulas is referenced in the JEP.
Thanks!
As far as I know, they are not part of any standard. If you know of any
standardized, complete EC point arithmetic formulas, then let me know.
I don't know, either.
I th
> On Sep 11, 2018, at 3:29 AM, Langer, Christoph
> wrote:
>
> Ok, maybe it should be named "priviledgedGetOverridable" then.
Ah yes. My mistake.
On 9/10/18 5:13 PM, Weijun Wang wrote:
On Sep 11, 2018, at 3:29 AM, Langer, Christoph wrote:
Ok, maybe it should be named "priviledgedGetOverridable" then.
Ah yes. My mistake.
Small spelling nit: there's no "d" before "g", so this should likely be
privilegedGetOverridable
s'mark
23 matches
Mail list logo
