On Wed, 18 Jan 2023 21:56:13 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 20 -> JDK 21
This pull request has now been integrated.
Changeset: fc9f8baf
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.org/jdk/commit/fc9f8baf56a362ad60d0e6dc8953690b80d3
Stats: 564 lines
Forwardport JDK 20 -> JDK 21
-
Commit messages:
- Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
- 8300275: SegmentScope.isAccessibleBy returning incorrect values
- 8300195: Fall-through issue occurs when using record pattern in switch
statements
- 8295723: security
On Fri, 13 Jan 2023 21:30:06 GMT, Joe Darcy wrote:
> With generalized see and link tags that can refer to anchors (JDK-8200337),
> the see and link tags in core libraries should be updated to use this feature
> when possible. This PR covers such updates for java.base.
This pull request has now
On Fri, 13 Jan 2023 22:54:47 GMT, Joe Darcy wrote:
>> With generalized see and link tags that can refer to anchors (JDK-8200337),
>> the see and link tags in core libraries should be updated to use this
>> feature when possible. This PR covers such updates for java.base.
>
> Joe Darcy has updat
On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad wrote:
> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on
> a `byte[]` subrange. It can profitably use the recently introduced
> `ArraysSupport::vectorizedHashCode` method to see a speed-up, which
> translates to a s
`ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a
`byte[]` subrange. It can profitably use the recently introduced
`ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates
to a small but significant speed-up on `ZipFile` creation.
Before:
Ben
On Wed, 18 Jan 2023 13:42:12 GMT, Eirik Bjorsnos wrote:
>> When introducing the call to isInMetaInf in isSigningRelated, I accidentally
>> broke the matching of MANIFEST.MF and SIG-* files.
>>
>> When fixing this regression, I now match against the full path instead of
>> the existing prefix s
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
On Wed, 18 Jan 2023 12:57:17 GMT, Eirik Bjorsnos wrote:
>> I agree this deserves a cleanup, and since we're already deep into it it can
>> make sense to fix this in this PR.
>>
>> I have introduced SignatureFileVerifier.isInMetaInf as a common method to
>> replace duplicated logic in JarVerifi
On Wed, 18 Jan 2023 09:51:35 GMT, Eirik Bjorsnos wrote:
>> While `JarSigner` has not normalize to uppercase, the check is the same. As
>> for `/META-INF/`, it must be very broken now since
>> `JarFile::maybeInstantiateVerifier` is using
>> `JUZFA.getManifestName(this,true)` to read the manifes
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
On Tue, 17 Jan 2023 16:11:42 GMT, Weijun Wang wrote:
>> This duplicated check annoyed me also, but the existing checks have
>> different behavior:
>>
>> - JarVerifier.beginEntry normalizes the path to uppercase, them checks that
>> it starts with "META-INF/" or "/META-INF/"
>> - JarSigner.sign
On Wed, 18 Jan 2023 09:47:29 GMT, Eirik Bjorsnos wrote:
>> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
>> files reside in META-INF directly, and not in a subdirectory of META-INF.
>>
>> The mentioned call sites needs updates to check and ignore such files.
>>
>> A
On Tue, 17 Jan 2023 16:46:28 GMT, Weijun Wang wrote:
>> I started there, but ran into some problems:
>>
>> SignatureFileVerifier.isSigningRelated calls isBlockOrSF, but it removes the
>> "META-INF/" prefix from the path first. So we can't assume that input to
>> isBlockOrSF is the full path.
>
> Some call sites of SignatureFileVerifier.isBlockOrSF fails to check that
> files reside in META-INF directly, and not in a subdirectory of META-INF.
>
> The mentioned call sites needs updates to check and ignore such files.
>
> A new test VerifyUnrelatedSignatureFiles is added which verifies t
20 matches
Mail list logo
