ttwoch, 7. April 2021 23:42
> To: Doerr, Martin ; jdk-updates-dev d...@openjdk.java.net>; security-dev
> Cc: Lindenmaier, Goetz ; Langer, Christoph
>
> Subject: Re: [11u] RFR: 8226374: Restrict TLS signature schemes and named
> groups
>
> The backport looks fine, except t
Hi Martin,
looks good to me.
Best regards
Christoph
From: Doerr, Martin
Sent: Dienstag, 30. März 2021 14:01
To: jdk-updates-dev ; security-dev
Cc: Langer, Christoph
Subject: [11u] RFR: 8254631: Better support ALPN byte wire values in SunJSSE
Hi,
JDK-8254631 is backported to 11.0.12-oracle
g, 23. März 2021 16:25
To: jdk-updates-...@openjdk.java.net; security-dev
Cc: Lindenmaier, Goetz ; Langer, Christoph
Subject: [11u] RFR: 8206925: Support the certificate_authorities extension
Hi,
JDK-8206925 was backported to 11.0.10-oracle, but it’s still missing in the
Open Source vers
Hi Martin,
this backport looks good to me.
Best regards
Christoph
From: Doerr, Martin
Sent: Donnerstag, 18. Februar 2021 12:11
To: security-dev ;
jdk-updates-...@openjdk.java.net
Cc: Langer, Christoph ; Lindenmaier, Goetz
Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore
Hi Matthias,
this looks correct. Thanks for taking care of it.
Best regards
Christoph
From: Baesken, Matthias
Sent: Freitag, 21. Februar 2020 13:18
To: security-dev@openjdk.java.net
Cc: Langer, Christoph
Subject: RE: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns
in
Hi Matthias,
this makes sense. Change looks fine. Thanks for doing it.
Cheers
Christoph
From: security-dev On Behalf Of
Baesken, Matthias
Sent: Dienstag, 18. Februar 2020 10:56
To: security-dev@openjdk.java.net
Subject: [CAUTION] RFR [XS]: 8239333:
test/jdk/security/infra/java/security/cert/C
Hi Rajan,
looks good. Thanks for doing this.
Best regards
Christoph
From: security-dev On Behalf Of Rajan
Halade
Sent: Freitag, 14. Februar 2020 22:15
To: security-dev@openjdk.java.net
Subject: RFR: 8225128: Add exception for expiring DocuSign root to
VerifyCACerts test
May I request you to
ption(
"TEST FAILED: couldn't determine EE certificate
status", cvpe);
Best regards
Christoph
> -Original Message-
> From: Baesken, Matthias
> Sent: Donnerstag, 30. Januar 2020 09:25
> To: Sean Mullan ; security-
> d...@openjdk.java.net
> Cc:
uar 2020 17:13
> To: Baesken, Matthias ; Langer, Christoph
> ; security-dev@openjdk.java.net
> Subject: Re: [CAUTION] RFR [XS]: 8237869: exclude jtreg test
> security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.
> java because of instabilities - was : RE: jtreg t
Hi Matthias,
the entry in ProblemList.txt can't refer to 8237869, which is the bug that
you're using to submit the exclusion. It must refer to the item that shall
resolve the underlying issue which probably is Oracle's private bug that Sean
referred to.
@Sean: In the interest of backportabilit
Hi Goetz,
this looks good to me. I compared security.cpp after I've applied your changes
to the version in jdk/jdk and there are only the changes missing that come with
newer changes JDK-8223003 and JDK-8223063.
Thanks for backporting this.
Cheers
Christoph
> -Original Message-
> From
Hi,
Just FWIW: JDK-8234245 fixed an issue where a wrong checksum was used in the
test update that came with JDK-8232019. So, both can probably marked fixed with
one change (e.g. adding both bugs to the submit message...)
Cheers
Christoph
> -Original Message-
> From: jdk8u-dev On Behal
Hi Severin,
same here, looks good - when VerifyCACerts passes, everything is correct.
Cheers
Christoph
> -Original Message-
> From: security-dev On Behalf Of
> Severin Gehwolf
> Sent: Donnerstag, 19. Dezember 2019 11:10
> To: Volker Simonis
> Cc: jdk8u-dev ; security-dev d...@openjdk.
Hi Severin,
this looks good - when VerifyCACerts passes, everything is correct.
We shall definitely try to backport "JDK-8193255: Root Certificates should be
stored in text format and assembled at build time" somehow, to have easier
certificate backports.
Cheers
Christoph
> -Original Mess
Hi Martin,
ok, you are the author – so I won’t insist. 😊
Best regards
Christoph
From: Doerr, Martin
Sent: Freitag, 6. Dezember 2019 12:22
To: Langer, Christoph
Cc: core-libs-...@openjdk.java.net; security-dev
; Lindenmaier, Goetz
; Thomas Stüfe
Subject: RE: RFR(S): 8220348: [ntintel
; Langer, Christoph
Cc: core-libs-...@openjdk.java.net; security-dev
; Lindenmaier, Goetz
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
Hi Thomas and Christoph,
thanks for the reviews.
Other code in java.security.jgss also uses these #defined checks:
src
Hi Martin,
thanks for looking into this and coming up with this patch. The test failures
were quite annoying 😊
In hotspot, there is coding to define a macro "ATTRIBUTE_ALIGNED(x)". I'd
rather like to see that we define such a macro in the JDK code as well and use
it. I think it would make the
Hi Martin,
looks good.
Best regards
Christoph
> -Original Message-
> From: security-dev On Behalf Of
> Martin Balao
> Sent: Montag, 11. November 2019 23:35
> To: security-dev ; Sean Mullan
>
> Subject: RFR 8233946: Add @since 13 annotation to
> KerberosPrincipal.KRB_NT_ENTERPRISE field
That's great, thanks Sean.
I'll take care of backporting the other items as well.
/Christoph
From: Seán Coffey
Sent: Freitag, 8. November 2019 17:03
To: Langer, Christoph ; Sean Mullan
; Valerie Peng ; OpenJDK Dev
list
Cc: Joe Darcy ; jdk-updates-...@openjdk.java.net
Subject: Re:
Hi Valerie, Sean,
may I please ask you to add yourself as reviewer to the backport CSR
JDK-8233825: "Update SunPKCS11 provider with PKCS11 v2.40 support" [0]. It is a
CSR for backporting JDK-8080462 to OpenJKD 11u. Oracle did that already for
11.0.6 but with the internal ccc process. Joe indica
essage-
> From: Martin Balao
> Sent: Montag, 21. Oktober 2019 22:56
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Subject: Re: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC
> 6806)
>
> Hi Christoph,
>
> Can you please have a lo
+1
Thanks,
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Mittwoch, 9. Oktober 2019 20:58
> To: Rajan Halade ; security-
> d...@openjdk.java.net
> Cc: Langer, Christoph
> Subject: Re: RFR: 8231887: ComodoCA.java fails because certificate was
> rev
: Valerie Peng ; security-dev@openjdk.java.net
Cc: Langer, Christoph
Subject: RE: Re: RFR [XS] 8231357:
sun/security/pkcs11/Cipher/TestKATForGCM.java fails on SLES11 using
mozilla-nss-3.14
Hi Valerie / Christoph ,
New webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8231357.2
Hi Matthias,
looks good to me.
One minor style nit: You could close the else case in line 335 with "}" and
then have just one throw e; after the whole if else block.
Best regards
Christoph
From: Baesken, Matthias
Sent: Dienstag, 24. September 2019 10:30
To: Langer, Christoph ; se
Hi Matthias,
your change looks good to me. Don't forget to update the copyright years before
pushing.
Best regards
Christoph
From: security-dev On Behalf Of
Baesken, Matthias
Sent: Donnerstag, 19. September 2019 16:28
To: security-dev@openjdk.java.net
Subject: [CAUTION] RFR: 8231222: f
mport javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
Thanks
Christoph
From: Baesken, Matthias
Sent: Montag, 23. September 2019 15:16
To: security-dev@openjdk.java.net
Cc: Langer, Christoph ; Zeller, Arno
Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/T
again.
Thanks
Christoph
From: Langer, Christoph
Sent: Mittwoch, 4. September 2019 17:00
To: Baesken, Matthias ;
security-dev@openjdk.java.net; jdk-updates-...@openjdk.java.net; Aleksey
Shipilev
Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider
initialization, after compiler
nks
Christoph
From: Baesken, Matthias
Sent: Mittwoch, 4. September 2019 16:54
To: Langer, Christoph ;
security-dev@openjdk.java.net; jdk-updates-...@openjdk.java.net
Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider
initialization, after compiler on Windows changed
Hello Christ
Hi,
please review the backport of this testfix to JDK11 updates.
Bug: https://bugs.openjdk.java.net/browse/JDK-8204203
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/
The backport differs in that sun/security
Hi,
please review the problemlisting of
javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java in jdk11u. There's an
issue with the test, tracked by JDK-8212096. We see this issue in 11u testing,
too. In jdk/jdk resp. jdk/jdk13, the test is excluded, so I think we should
exclude it in 11u a
Ping...
Can somebody please have a look at this backport? Regression testing shows no
problems...
Thanks
Christoph
From: Langer, Christoph
Sent: Donnerstag, 4. Juli 2019 15:11
To: jdk-updates-...@openjdk.java.net
Cc: security-dev
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
Ping...
would somebody please eyeball this backport? No regressions seen in testing...
Thanks
Christoph
From: Langer, Christoph
Sent: Donnerstag, 4. Juli 2019 15:11
To: jdk-updates-...@openjdk.java.net
Cc: security-dev
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
Hi,
please help reviewing the backport of JDK-8216039 to jdk11u-dev.
Since predecessor patch JDK-8211122 could not be applied to JDK 11 updates,
some manual work is necessary.
In src/java.base/share/classes/java/security/Signature.java and
src/java.base/share/classes/sun/security/util/Signatur
Hi Paul,
thanks for your review.
> In CertAndKeyGen.java, does generate() need a throws declaration?
It doesn't. IllegalArgumentException is a RuntimeException and as such doesn't
need a throws declaration. And InvalidKeyException is obviously not needed and
was removed in the original changes
; -Original Message-
> From: jdk-updates-dev On
> Behalf Of Langer, Christoph
> Sent: Mittwoch, 26. Juni 2019 17:30
> To: jdk-updates-...@openjdk.java.net
> Cc: security-dev
> Subject: [CAUTION] [11u]: RFR: Backport of 8215694: keytool cannot
> generate RSASSA-PSS certific
Hi,
I made a mistake when bringing JDK-8226880 to 11u. The patch introduced coding
of JDK-8205476 that should not be there. Here is a patch to fix this.
Bug: https://bugs.openjdk.java.net/browse/JDK-8226880
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8226880.11u.0/
As the backport is in
level
assert but maybe we'll need to take some (backout?) action here for 11.0.4,
too...
Thanks
Christoph
> -Original Message-
> From: Andrew John Hughes
> Sent: Donnerstag, 27. Juni 2019 06:09
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
>
Hi,
please help reviewing the backport of JDK- 8215694: keytool cannot generate
RSASSA-PSS certificates. The patch doesn't apply cleanly but the rejects are
only minor. The Item is needed as prerequisite to apply JDK-8216039.
Bug: https://bugs.openjdk.java.net/browse/JDK-8215694
Original Change
; To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net; security-dev
> Subject: Re: OpenJDK 11u backport of JDK-8148188: Enhance the security
> libraries to record events of interest
>
> Hi Christoph,
>
> On 22/06/2019 2:25 pm, Langer, Christoph wrote:
> > H
Hi,
I pushed the backport of JDK-8148188 [0] to jdk11u-dev [1] on Friday. I was
wondering why no 11.0.5 backport JBS item was created. I then manually created
JDK-8226636 [2], but the minute I had created it I got an idea what the reason
for that strange JBS/hgupdater behavior was (all other pu
4:40
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Cc: security-dev
> Subject: RE: [11u] RFR: 8208698: Improved ECC Implementation
>
> Hi Christoph,
>
> looks like quite some manual resolution just because of a small conflicting
> change in one fil
Hi Max,
> But you changed
>
>everyone (yes, everyone) has been loading cacerts with a null password
> and they are able to read all certificate inside.
>
> to
>
>everyone (yes, everyone) who loads cacerts with a null password is able to
> read all certificates inside.
>
> I *did* mean
Hi Max,
I've already made some updates to the wording in the CSR.
In the specification section, it should probably also not mention the source
location src/java.base/share/lib/security/cacerts as it is about to be
eliminated by JDK-8193255. It should rather refer to
/lib/security/cacerts, I th
Hi Max,
this looks all good to me now :)
Best regards
Christoph
> -Original Message-
> From: build-dev On Behalf Of
> Weijun Wang
> Sent: Freitag, 31. Mai 2019 05:01
> To: Erik Joelsson
> Cc: security-dev@openjdk.java.net; build-dev d...@openjdk.java.net>
> Subject: Re: RFR 8193255: R
Hi Max,
first of all, thanks for doing this enhancement. That'll really help in the
future when downstream vendors merge in additional certificates (or remove
some) like we do with SapMachine. Currently we have to resolve manually
everytime cacerts is modified.
As for the dependencies: if you
Hi Sean,
thanks for the review. I've addressed your points:
http://cr.openjdk.java.net/~clanger/webrevs/8224729.2/
Thanks
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Dienstag, 28. Mai 2019 15:18
> To: Langer, Christoph ; security-dev d...@openjdk.ja
Hi,
please review this backport of JDK-8208698: Improved ECC Implementation.
Bug: https://bugs.openjdk.java.net/browse/JDK-8208698
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8208698.11u/
The patch did not apply cleanly
Hi,
please review this small cleanup which started off under a different subject
[0] but turned out to be the wrong thing to do. Still the cleanup parts seem to
be valuable, so requesting a review for that here.
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8224729.1/
Bug: https://bugs.op
> > As for Bug JDK-8224729: Shall I just close the ticket, dropping a comment
> about the ignorance of the author or shall I repurpose it to do the other
> cleanups in LDAPCertStoreImpl.java that I suggested? Don't know if these
> are appreciated... what do you think?
>
> Either way, the debugging
Hi Rajan,
thanks for this. Problem list update would be then:
http://cr.openjdk.java.net/~clanger/webrevs/8224727.1/
Please review.
Thanks
Christoph
> -Original Message-
> From: Rajan Halade
> Sent: Freitag, 24. Mai 2019 18:52
> To: Langer, Christoph
> Cc: Sean Mullan
these are appreciated...
what do you think?
Best regards
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Freitag, 24. Mai 2019 14:02
> To: Langer, Christoph ; security-dev d...@openjdk.java.net>
> Subject: Re: RFR(S): 8224729:
> sun/
Hi,
please review this fix for an issue that I've discovered when working with test
security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java.
It fails when the test tries to do the CRL verification of the certificate. It
has issues in the LDAP implementation because of t
Hi,
please review the problem listing of
security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
and
security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java
until JDK-8202651 and JDK-8215546 are resolved.
Bug: https://bugs.openjdk.java.net/brows
Hi Rajan, Sean,
first of all, thanks for the update on the tests.
As I see, there are still open questions for the ActalisCA test. So I'm
wondering whether the fix for ComodoCA can be pushed as fix for
https://bugs.openjdk.java.net/browse/JDK-8215546 ?
Furthermore, can we also exclude the Acta
t system and have to exclude them locally.
/Christoph
> -Original Message-
> From: Doerr, Martin
> Sent: Dienstag, 14. Mai 2019 10:22
> To: Langer, Christoph ; 'jdk8u-
> d...@openjdk.java.net' ; security-dev
>
> Subject: RE: [8u] RFR: 8189131: Open-source the Orac
> Sent: Mittwoch, 8. Mai 2019 15:58
> To: Langer, Christoph ; security-dev d...@openjdk.java.net>
> Subject: Re: RFR(XS): 8223555: Cleanups in cacerts tests
>
> Hi Christoph,
>
> Did you see compiler warning for the files? I tried with the JDK
> repository build, no compile
Hi,
please review this small change which contains a few minor cleanups to the
tests for the CA certificates. I had it in my mercurial queue for quite some
time and always wanted to contribute it 😊
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223555.0/
Bug: https://bugs.openjdk.java.net
Ping: can I please have a review for this?
From: Langer, Christoph
Sent: Donnerstag, 2. Mai 2019 14:55
To: 'jdk8u-...@openjdk.java.net' ; security-dev
Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates
(Integration for JEP 319: Root Certificates)
Hi,
as w
Hi,
as was already discussed and requested on the mailing lists ([0], [1]), I
hereby propose a change to add the root certificates of upstream OpenJDK to
OpenJDK 8 updates.
The main bug that (initially) brought the Oracle certificates to OpenJDK is
8189131: Open-source the Oracle JDK Root Cert
Hi Sean,
sounds good. I’ll create an 11.0.4 bug before pushing to jkd11u-dev.
I assume you’ll take care of jdk12u?
Thanks
Christoph
From: Seán Coffey
Sent: Donnerstag, 2. Mai 2019 10:25
To: Langer, Christoph
Cc: Rajan Halade ; Sean Mullan
; security-dev
Subject: Re: RFR: 8222137: Remove T
: Langer, Christoph
Cc: Sean Mullan ; security-dev
; Seán Coffey
Subject: Re: RFR: 8222137: Remove T-Systems root CA certificate
I have created needed backports including 12-pool, 11-pool, 8-pool, and 7-pool.
These are assigned to Sean C. for now. Please co-ordinate with him.
Thanks,
Rajan
On
Hi Rajan,
I’ll take this to jdk11 updates. What about jdk12 updates? I can process both
releases, if you want.
Best regards
Christoph
From: security-dev On Behalf Of Rajan
Halade
Sent: Dienstag, 30. April 2019 20:39
To: Sean Mullan ; security-dev
Subject: RFR: 8222137: Remove T-Systems root
Thank you, Rajan.
From: Rajan Halade
Sent: Dienstag, 30. April 2019 20:08
To: Langer, Christoph
Cc: security-dev@openjdk.java.net; jdk-updates-...@openjdk.java.net; Sean
Mullan
Subject: Re: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root
certificate
Thanks Christop
> >> It should be in 11.0.3-oracle. The backport issue is Confidential so
> >> maybe that is why you thought it wasn't.
> > Yep, that explains it. Any particular reason that the 11.0.3-oracle
> > backport is
> confidential? Could you make it public? Just asking...
>
> Fixed.
Thanks!
> >> JDK 13
Hi,
the change to add GlobalSign's R6 Root certificate has only been pushed to
jdk12 updates (12.0.1) so far. According to [0], it was an oversight to not
have it added to jdk/jdk. I also want to bring it to 11u.
Taking the change to both, jdk/jdk and jdk-updates/jdk11u-dev does not apply
clea
> -Original Message-
> From: Sean Mullan
> Sent: Samstag, 27. April 2019 00:54
> To: Langer, Christoph ; security-
> d...@openjdk.java.net; Rajan Halade
> Subject: Re: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate
>
> On 4/26/19 6:04 PM, La
Hi,
In JBS I can find the bug JDK-8216577: Add GlobalSign's R6 Root certificate [0].
This change has gone into 12.0.1 and also 12.0.2 but it's not part of JDK13
(jdk/jdk) and also not of JDK11 (e.g. 11.0.3-oracle, 11.0.4-oracle). Could you
please shed some light into this unusual proceeding? Us
Hi Thomas,
looks good to me.
Best regards
Christoph
From: security-dev On Behalf Of Thomas
Stüfe
Sent: Montag, 25. März 2019 14:13
To: security-dev@openjdk.java.net
Subject: RFR(xxs): 8221407: Windows 32bit build error in
libsunmscapi/security.cpp
Hi all,
please review this tiny fix to the
ttps://github.com/AdoptOpenJDK/openjdk-build/tree/master/security
From: Martijn Verburg
Sent: Freitag, 22. März 2019 20:38
To: Sean Mullan
Cc: Langer, Christoph ; jdk8u-...@openjdk.java.net;
OpenJDK Dev list
Subject: Re: [8u] Is it possible to bring root certificates to OpenJDK 8
[JEP319] ?
Hi Sean,
> > Now my questions are: Is it legally possible to bring these root
> > certificates
> also into OpenJDK 8? Since it is a JEP, can the “feature” be added to OpenJDK
> 8 via an update release? And, last but not least, would there be interest in
> the community for that at all?
>
> I can
Hi,
I recently came across a scenario where I wanted to use a self-built OpenJDK 8
in a maven build and it could not download artefacts due to missing root
certificates. I helped myself by replacing the cacerts with some other version
from a later OpenJDK and came over the issue. However, I’ve
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
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
.
Module-info and CSR have been adopted, too.
Thanks in advance for reviewing.
Best regards
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 21. Januar 2019 10:17
> To: 'Alan Bateman'
> Cc: nio-dev ; OpenJDK Dev list d...@openjdk.java.net>; Java
Thanks Sean. Pushed with the replacement as you suggested.
> -Original Message-
> From: Sean Mullan
> Sent: Donnerstag, 31. Januar 2019 21:03
> To: Langer, Christoph ; security-
> d...@openjdk.java.net
> Subject: Re: RFR [11u backport]: 8217579:
> TLS_EMPTY_RENEG
Hi,
please review the backport of the fix for 8217579 to jdk11u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8217579
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217579.11u/
Original review thread:
https://mail.openjdk.java.net/pipermail/security-dev/2019-January/019256.html
The patch
Hi Sean,
to me this looks fine. +1
The test should be really valuable in the future.
Thanks & Best regards
Christoph
> -Original Message-
> From: security-dev On Behalf Of
> Sean Mullan
> Sent: Montag, 28. Januar 2019 22:25
> To: security-dev@openjdk.java.net
> Subject: Re: 8217579: TL
Hi Sean,
thanks for looking at this. I agree. Will remove othervm...
Best regards
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Donnerstag, 24. Januar 2019 17:43
> To: Langer, Christoph ; OpenJDK Dev list
> ; OpenJDK Network Dev list d...@openjdk.java.net
Hi Goetz,
thanks for the review.
I've added the comment as you suggested:
http://cr.openjdk.java.net/~clanger/webrevs/8217657.1/
Will run it through our nightly tests before submitting...
/Christoph
From: Lindenmaier, Goetz
Sent: Donnerstag, 24. Januar 2019 08:48
To: Langer, Chri
Hi,
please review a small test update.
Bug: https://bugs.openjdk.java.net/browse/JDK-8217657
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217657.0/
I'd like to move the test for the correct default value of security property
"jdk.includeInExceptions" into an own testcase in the jdk.secu
Hi security experts,
one of our customers is running into an issue with a Tomcat application after
JDK-8211883 [1]. It seems that because of adding NULL to
jdk.tls.disabledAlgorithms, the pseudo cipher suite
TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled. Seems like, according to
CipherSuite.ja
Hi Alan,
first of all, thank you for your input on this.
> I think the approach to explore are:
>
> 1. zipfs supports PosixFileAttributeView without subsetting. If
> readAttribute(file, BasicFileAttributes.class) succeeds then
> readAttribute(file, PosixFileAttributes.class) should also succeed,
Hi Alan,
> I will try to get time next week to reply to you on this. Part of the
> issue with your current approach is that it breaks PosixFileAttribtues.
> There are also issues trying to force the API to optionally support a
> subset of POSIX attributes on some zip entries and not on others. So
into your work. Seeing how things
are going with this POSIX permission topic, I’m sure you’ll be done with a
patch for 8182117 much earlier than me 😉.
Best
Christoph
From: Lance Andersen
Sent: Samstag, 12. Januar 2019 15:01
To: Langer, Christoph
Cc: Alan Bateman ; nio-dev ;
OpenJDK Dev list
the
zip file system provider can be accessed and new zip filesystems can be created.
Please kindly review this.
Thank you and best regards
Christoph
> -Original Message-
> From: Langer, Christoph
> Sent: Dienstag, 8. Januar 2019 09:27
> To: 'Alan Bateman' ; Volker S
his is the right way to go? Should we maybe do the spec update of
the permission methods in a separate change?
Best regards
Christoph
> -Original Message-
> From: Alan Bateman
> Sent: Montag, 7. Januar 2019 21:46
> To: Volker Simonis
> Cc: Langer, Christoph ; nio-dev d...@o
://bugs.openjdk.java.net/browse/JDK-8213082
Please review both, CSR and changeset and let me know if this is good now or
what else needs to be addressed.
Thanks and best regards,
Christoph
From: Volker Simonis
Sent: Freitag, 21. Dezember 2018 17:34
To: Langer, Christoph
Cc: Java Core Libs
Hi all,
here comes the updated webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8213031.3/
I've rebased the change to the current state of the JDK depot. Thanks to
Volker, the test has been enhanced and now also tests more copy operations
(from zip file system to zip file system and from zi
Hi Alan,
> Adding support for POSIX file permissions to the zip APIs is problematic
> as we've been discussing here. There are security concerns and also
> concerns that how it interacts with JAR files and signed JAR in
> particular. I don't disagree that we can come to agreement on zipfs
> suppor
> From: Chris Hegarty
> Sent: Montag, 5. November 2018 17:19
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; security-dev@openjdk.java.net; Xueming Shen
>
> Cc: nio-dev
> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions
>
>
> On
Hi Chris
> The reason I asked about the CSR scope clarification is that it was
> unclear to me what the ultimate intentions are, given that the previous
> mails ( linked to from the CSR ) did have Java SE API changes ( in the
> java.util.zip package ).
>
> Are you now happy to reduce the scope of
lling to have a look from security perspective?
Thanks & Best regards
Christoph
From: Alan Bateman
Sent: Montag, 5. November 2018 11:23
To: Langer, Christoph ; core-libs-dev
; security-dev@openjdk.java.net; Xueming Shen
Cc: Volker Simonis ; nio-dev
Subject: Re: RFR 8213031: (zipfs) Add support f
rom: Chris Hegarty
> Sent: Montag, 5. November 2018 13:20
> To: Langer, Christoph ; core-libs-dev d...@openjdk.java.net>; security-dev@openjdk.java.net
> Cc: nio-dev
> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions
>
> Hi Christoph,
Hi,
Ping.
May I get reviews/substantial feedback on this zipfs enhancement?
Bug: https://bugs.openjdk.java.net/browse/JDK-8213031
CSR: https://bugs.openjdk.java.net/browse/JDK-8213082
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/
Thanks
Christoph
From: Langer, Christoph
Sent
i/java.base/java/nio/file/attribute/PosixFileAttributeView.html
Thanks in advance for reviewing.
Best regards
Christoph
From: Alan Bateman
Sent: Montag, 29. Oktober 2018 13:06
To: Langer, Christoph ; core-libs-dev
; security-dev@openjdk.java.net; Xueming Shen
Cc: Volker Simonis ; Andrew Luo
erspective.
Thanks
Christoph
From: Langer, Christoph
Sent: Freitag, 26. Oktober 2018 17:13
To: core-libs-dev ; nio-dev
; 'Xueming Shen'
Cc: Schmelter, Ralf ; 'Volker Simonis'
Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions
Hi,
please review this e
Hi Matthias,
I generally support this enhancement of IOExceptions to include path
information.
I also think that we should protect this with the java.security property
"jdk.includeInExceptions" and agree that "path" would be a good choice since it
is generic enough to be used in other places w
Looks good to me.
> -Original Message-
> From: Baesken, Matthias
> Sent: Mittwoch, 12. September 2018 11:27
> To: Sean Mullan ; Langer, Christoph
> ; Weijun Wang
> Cc: security-dev@openjdk.java.net; core-libs-...@openjdk.java.net
> Subject: RE: [RFR] 8205525 : Impro
n by a system property of the
same name"
Best regards
Christoph
> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 11. September 2018 13:29
> To: Weijun Wang
> Cc: Langer, Christoph ; Sean Mullan
> ; security-dev@openjdk.java.net; core-libs-
> d...
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
1 - 100 of 140 matches
Mail list logo
