Looks good.
--Sean
On 2/12/19 10:31 PM, Weijun Wang wrote:
The -genkeypair command mistakenly lists -destalias in its option table.
Here is the simple patch:
*diff --git
a/src/java.base/share/classes/sun/security/tools/keytool/Main.java
b/src/java.base/share/classes/sun/security/tools/keyto
On 2/12/19 6:28 PM, Open eSignForms wrote:
Thanks for the update, Sean. I'm a bit perplexed because I found the
original code works under Java 9 and Java 10, so it seems like the
change occurred in Java 11.
Sorry, that was a typo, I meant to say JDK 11.
I don't see the modified version of th
I would highly suggest implementing your own for a much better
understanding.
I did implement something like what you want and in so doing realized I
like their decision. ie. See the heirarchy here
https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/web
I forgot about and forgot to mention there is a special backpressure in the
webpieces implementation.
Say A connects through socket to B and B has this webpieces
channelmanager. Let's say C is the client code of B. If C does not
consume the data fast enough from A, channelmanager deregisters the
Thanks, Sean. I was able to find the updated test case source code.
A preliminary review seems to show worthwhile changes to our code. That
is, the namespaces and such seem to make sense as you have them.
In particular, the use of:
domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig
Hi Xuelei,
There were 2 distinct cases of change of behaviour.
- The "CN=invalid2.invalid, OU="No SNI provided" reliably works without
SNI in Java 8 but is indeed fixed by having an SNI included which perhaps
was needed all along. This one is reported by XMPP/TLS connection from
talk.g
I checked the ETSI XAdES spec
(http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf) and it doesn't
show any namespace on their entries for their QualifyingProperties
element and all sub-elements under the ETSI example's element .
But, their specification does show element should
be under
Hi Amir,
Could you build OpenJDK by yourself? If it is doable, I could send your
a patch to disable the extension so that you can confirm if and which
extension is the underlying problem.
Thanks,
Xuelei
On 2/13/2019 1:16 PM, Amir Khassaia wrote:
Hi Xuelei,
There were 2 distinct cases of c
Hi,
Could I get the CSR reviewed:
https://bugs.openjdk.java.net/browse/JDK-8218932
The internal package com.sun.net.ssl had been deprecated since JDK 1.4,
and was not exported in the java.base module since JDK 9. Application
cannot use them directly now. It should be safe to remove them i
Unfortunately I no longer have the device that replicates the problem :(
and other similar ones never showed in the first place.
Traditionally I would make TLS handshakes stay identical across JDK
versions to ensure compatibility as working with various devices and
vendors would show up a multitude
Hi,
maybe two points.
1) Older lotus notes server have the problem.
2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
3) Maybe it would be an good idea to build an set of client hello's with
different options.
Or even an generator. Than you send if and check the result si
Hi Christoph,
Just starting to take a peek at this and noticed one quick thing in your test:
Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
——
You do not need the test.dir property or the permission added to test.policy
to access it, just reference the jar a
Hi Thomas,
Can you confirm its tied to new extensions to TLS 1.2 client hello and
whether you diagnosed which one was the problem in Lotus Notes case ?
On Thu, Feb 14, 2019 at 9:05 AM Thomas Lußnig wrote:
> Hi,
>
> maybe two points.
>
> 1) Older lotus notes server have the problem.
> 2) The prob
Hi,
i check the old mails. In your case the problem was about the EC-Group
extensions. If the server receive an unknown group he break the
handshake with an alert. What was interesting is the fact it did not
break after client hello but after Client-RSA-Key with alert
illgegalParameter. I man
Hi Lance,
thanks for looking.
> Just starting to take a peek at this and noticed one quick thing in your test:
>
> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
> ——
>
> You do not need the test.dir property or the permission added to test.policy
> to access i
While this is somewhat similar its still a little different to what I was
asking because you can control named groups right now with the system
property, eg. jdk.tls.namedGroups (yes its global not ideal) and also at
the socket level but at least you dont have to drop TLS level.
For the other exten
Hi Christoph
> On Feb 13, 2019, at 5:30 PM, Langer, Christoph
> wrote:
>
> Hi Lance,
>
> thanks for looking.
>
>> Just starting to take a peek at this and noticed one quick thing in your
>> test:
>>
>> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
>> ——
>>
Well, I have found that my verify routines are failing. I added the
following lines to the main() test method of your fixed code after the
signature is done to attempt to validate the generated signed XML:
try {
System.err.println("Verifying signedXml...");
Hi, I'd like to report a bug that may confuse others as they diagnose TLS
handshakes.
The extension logging seems to be affected in JDK 11.0.2, these come up as
empty in client hello (see below) from Oracle JDK 11.0.2
==
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:48.620
A
This bug will be addressed in JDK 11.0.3 and 12. See also:
https://bugs.openjdk.java.net/browse/JDK-8210974
Thanks,
Xuelei
On 2/13/2019 3:58 PM, Amir Khassaia wrote:
Hi, I'd like to report a bug that may confuse others as they diagnose
TLS handshakes.
The extension logging seems to be a
Thanks Xuelei, I clearly missed the report somehow
On Thu, Feb 14, 2019 at 2:26 PM Xuelei Fan wrote:
> This bug will be addressed in JDK 11.0.3 and 12. See also:
> https://bugs.openjdk.java.net/browse/JDK-8210974
>
> Thanks,
> Xuelei
>
> On 2/13/2019 3:58 PM, Amir Khassaia wrote:
> >
> > Hi
Hi Lance,
thanks for the detailed explanation, sounds great. I’ll work that in in my next
edition 😊
Best regards
Christoph
From: Lance Andersen
Sent: Mittwoch, 13. Februar 2019 23:53
To: Langer, Christoph
Cc: Alan Bateman ; nio-dev ;
Java Core Libs ; OpenJDK Dev list
; Volker Simonis
Subj
22 matches
Mail list logo
