Hi,
when running coverity checks on
src/jdk.crypto.ec/share/native/libsunec/impl/ecdecode.c we had a finding that
potentially the buffer "genenc" in function "gf_populate_params" could be
exceeded as the length of input strings for the strcat operations is not
checked. A check to satisfy cover
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
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
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
; [email protected]; Xueming Shen
Cc: Volker Simonis ; Andrew Luo
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
rom: Chris Hegarty
> Sent: Montag, 5. November 2018 13:20
> To: Langer, Christoph ; core-libs-dev [email protected]>; [email protected]
> Cc: nio-dev
> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions
>
> Hi Christoph,
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
; [email protected]; Xueming Shen
Cc: Volker Simonis ; nio-dev
Subject: Re: RFR 8213031: (zipfs) Add support f
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
> From: Chris Hegarty
> Sent: Montag, 5. November 2018 17:19
> To: Langer, Christoph ; core-libs-dev [email protected]>; [email protected]; Xueming Shen
>
> Cc: nio-dev
> Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions
>
>
> On
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
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
://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
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
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
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
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
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 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,
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 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 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 [email protected]
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: [email protected]
> Subject: Re: 8217579: TL
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
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-
> [email protected]
> Subject: Re: RFR [11u backport]: 8217579:
> TLS_EMPTY_RENEG
.
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 [email protected]>; Java
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
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,
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 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
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 ; [email protected];
OpenJDK Dev list
Subject: Re: [8u] Is it possible to bring root certificates to OpenJDK 8
[JEP319] ?
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: [email protected]
Subject: RFR(xxs): 8221407: Windows 32bit build error in
libsunmscapi/security.cpp
Hi all,
please review this tiny fix to the
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
> -Original Message-
> From: Sean Mullan
> Sent: Samstag, 27. April 2019 00:54
> To: Langer, Christoph ; security-
> [email protected]; Rajan Halade
> Subject: Re: Regarding JDK-8216577: Add GlobalSign's R6 Root certificate
>
> On 4/26/19 6:04 PM, La
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
> >> 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
Thank you, Rajan.
From: Rajan Halade
Sent: Dienstag, 30. April 2019 20:08
To: Langer, Christoph
Cc: [email protected]; [email protected]; Sean
Mullan
Subject: Re: RFR [backport to jdk and 11u]: 8216577: Add GlobalSign's R6 Root
certificate
Thanks Christop
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
: 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 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
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
Ping: can I please have a review for this?
From: Langer, Christoph
Sent: Donnerstag, 2. Mai 2019 14:55
To: '[email protected]' ; security-dev
Subject: [8u] RFR: 8189131: Open-source the Oracle JDK Root Certificates
(Integration for JEP 319: Root Certificates)
Hi,
as w
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
> Sent: Mittwoch, 8. Mai 2019 15:58
> To: Langer, Christoph ; security-dev [email protected]>
> 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
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-
> [email protected]' ; security-dev
>
> Subject: RE: [8u] RFR: 8189131: Open-source the Orac
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
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,
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
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 [email protected]>
> Subject: Re: RFR(S): 8224729:
> sun/
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
> > 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,
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
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 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 [email protected]
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 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: [email protected]; build-dev [email protected]>
> Subject: Re: RFR 8193255: R
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,
> 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
4:40
> To: Langer, Christoph ; jdk-updates-
> [email protected]
> 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,
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
; To: Langer, Christoph ; jdk-updates-
> [email protected]; 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,
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
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-
> [email protected]
>
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
; -Original Message-
> From: jdk-updates-dev On
> Behalf Of Langer, Christoph
> Sent: Mittwoch, 26. Juni 2019 17:30
> To: [email protected]
> Cc: security-dev
> Subject: [CAUTION] [11u]: RFR: Backport of 8215694: keytool cannot
> generate RSASSA-PSS certific
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
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
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: [email protected]
Cc: security-dev
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
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: [email protected]
Cc: security-dev
Subject: [11u] RFR: 8216039: TLS with BC and RSASSA-PSS breaks
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
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
nks
Christoph
From: Baesken, Matthias
Sent: Mittwoch, 4. September 2019 16:54
To: Langer, Christoph ;
[email protected]; [email protected]
Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider
initialization, after compiler on Windows changed
Hello Christ
again.
Thanks
Christoph
From: Langer, Christoph
Sent: Mittwoch, 4. September 2019 17:00
To: Baesken, Matthias ;
[email protected]; [email protected]; Aleksey
Shipilev
Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider
initialization, after compiler
mport javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
Thanks
Christoph
From: Baesken, Matthias
Sent: Montag, 23. September 2019 15:16
To: [email protected]
Cc: Langer, Christoph ; Zeller, Arno
Subject: RFR [XS] 8231357: sun/security/pkcs11/Cipher/T
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: [email protected]
Subject: [CAUTION] RFR: 8231222: f
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
: Valerie Peng ; [email protected]
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
+1
Thanks,
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Mittwoch, 9. Oktober 2019 20:58
> To: Rajan Halade ; security-
> [email protected]
> Cc: Langer, Christoph
> Subject: Re: RFR: 8231887: ComodoCA.java fails because certificate was
> rev
essage-
> From: Martin Balao
> Sent: Montag, 21. Oktober 2019 22:56
> To: Langer, Christoph ; jdk-updates-
> [email protected]
> Subject: Re: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC
> 6806)
>
> Hi Christoph,
>
> Can you please have a lo
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
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 ; [email protected]
Subject: Re:
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
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
; Langer, Christoph
Cc: [email protected]; 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,
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: [email protected]; security-dev
; Lindenmaier, Goetz
; Thomas Stüfe
Subject: RE: RFR(S): 8220348: [ntintel
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 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,
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 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 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
uar 2020 17:13
> To: Baesken, Matthias ; Langer, Christoph
> ; [email protected]
> 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
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-
> [email protected]
> Cc:
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: [email protected]
Subject: RFR: 8225128: Add exception for expiring DocuSign root to
VerifyCACerts test
May I request you to
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: [email protected]
Subject: [CAUTION] RFR [XS]: 8239333:
test/jdk/security/infra/java/security/cert/C
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: [email protected]
Cc: Langer, Christoph
Subject: RE: RFR [XS]: 8239457: call ReleaseStringUTFChars before early returns
in
Hi,
please review a change proposal regarding an issue in the Microsoft Security
API (mscapi).
Bug: https://bugs.openjdk.java.net/browse/JDK-8139436
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/
I stumbled over the issue when using an old IAIK security provider. It would
be the correct contract for
KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0)
return null;")
Mike
On 10/12/2015 5:04 PM, Langer, Christoph wrote:
Hi,
please review a change proposal regarding an issue in the Microsoft Security
API (mscapi).
Bug: http
[email protected]]
Sent: Donnerstag, 15. Oktober 2015 02:09
To: Langer, Christoph
Cc: [email protected]
Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete
data
Sorry for the top post, I'm wring this on an iPad on a plane.
It's perfectly acceptable for a p
Hi folks,
is there any feedback/review for this change?
Thanks
Christoph
From: Langer, Christoph
Sent: Mittwoch, 4. November 2015 12:11
To: 'Michael StJohns'
Cc: [email protected]
Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete
data
StJohns ; Langer, Christoph
Cc: [email protected]
Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete
data
Explicitly referencing the Sun JCE provider makes the jdk.crypto.mscapi module
depend on the java.base module.
And that’s OK.
I can sponsor this
care.
Christoph
From: Vincent Ryan [mailto:[email protected]]
Sent: Mittwoch, 11. November 2015 08:46
To: Mike StJohns ; Langer, Christoph
Cc: [email protected]
Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete
data
Explicitly referencing the Sun
1 - 100 of 140 matches
Mail list logo
