Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

    • -1
    • +12
    ./ImmutableArtifactVerificationMetadata.java
  1. … 11 more files in changeset.
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

    • -1
    • +12
    ./ImmutableArtifactVerificationMetadata.java
  1. … 11 more files in changeset.
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

    • -1
    • +12
    ./ImmutableArtifactVerificationMetadata.java
  1. … 11 more files in changeset.
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

    • -1
    • +12
    ./ImmutableArtifactVerificationMetadata.java
  1. … 11 more files in changeset.
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

    • -1
    • +12
    ./ImmutableArtifactVerificationMetadata.java
  1. … 11 more files in changeset.
Add ability to ignore keys for a specific artifact

The use case for this is whenever signature for an artifact fails, but

for some reason the user still trusts the artifact. For example, a POM

file is different between different repositories because it happened

to be published twice with different timestamps.

In this case it is recommended to ignore the signature, however we

_will_ fallback on checksum verification.

    • -1
    • +12
    ./ImmutableArtifactVerificationMetadata.java
  1. … 11 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

    • -3
    • +24
    ./ImmutableArtifactVerificationMetadata.java
  1. … 62 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

    • -3
    • +24
    ./ImmutableArtifactVerificationMetadata.java
  1. … 61 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

    • -3
    • +24
    ./ImmutableArtifactVerificationMetadata.java
  1. … 60 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

    • -3
    • +24
    ./ImmutableArtifactVerificationMetadata.java
  1. … 62 more files in changeset.
Initial implementation of verification of signatures

This commit introduces _signature_ verification. Signature verification

is stronger than checksum verification and must be enabled explicitly,

by adding `<signature-verification>true</signature-verification>` to the

dependency verification configuration file.

Once such verification is enabled, Gradle will do its best to verify

the signature of artifacts. This means:

- it will try to download the .asc file associated with an artifact

- if it's present, it will automatically download the public keys

of the signature and verify that the file matches the signatures

- if _any_ of the signature verification fails, fails the build

- if a public key is not trusted explicitly, fails the build

- if signature verification succeeds, no checksum verification is

performed

Currently it's not possible to perform checksum verification for some

modules and signature verification for others. All modules must declare

all trusted keys.

If a key cannot be downloaded, verification will fail. It's not possible

to ignore a key for now. It's not possible to fallback to checksum

verification.

    • -3
    • +24
    ./ImmutableArtifactVerificationMetadata.java
  1. … 62 more files in changeset.
Make verification model more resilient to real world projects

Dogfooding the Gradle build with dependenvy verification proved to

be helpful. There are quite a few cases where we discover dependencies

which come from different repositories. Reposiories can also be mirrored

and sometimes the mirror doesn't mirror what is was supposed to.

The problem is that working around, for example by fixing the mirrors

or figuring out how to fetch a dependency from the right place can be

tricky. It's often easier to go and check the dependency and/or metadata

and approve it.

For this purpose, the verification metadata file now includes the

ability to have "alternate", trusted checksums. It also adds the ability

to tell where a checksum comes from, as indication to the reader. Checksums

generated by Gradle will be marked as such, and therefore a reader can

see that they are less "trustworthy" than checksums fetched by a human.

    • -7
    • +5
    ./ImmutableArtifactVerificationMetadata.java
  1. … 10 more files in changeset.
Make verification model more resilient to real world projects

Dogfooding the Gradle build with dependenvy verification proved to

be helpful. There are quite a few cases where we discover dependencies

which come from different repositories. Reposiories can also be mirrored

and sometimes the mirror doesn't mirror what is was supposed to.

The problem is that working around, for example by fixing the mirrors

or figuring out how to fetch a dependency from the right place can be

tricky. It's often easier to go and check the dependency and/or metadata

and approve it.

For this purpose, the verification metadata file now includes the

ability to have "alternate", trusted checksums. It also adds the ability

to tell where a checksum comes from, as indication to the reader. Checksums

generated by Gradle will be marked as such, and therefore a reader can

see that they are less "trustworthy" than checksums fetched by a human.

    • -7
    • +5
    ./ImmutableArtifactVerificationMetadata.java
  1. … 10 more files in changeset.
Make verification model more resilient to real world projects

Dogfooding the Gradle build with dependenvy verification proved to

be helpful. There are quite a few cases where we discover dependencies

which come from different repositories. Reposiories can also be mirrored

and sometimes the mirror doesn't mirror what is was supposed to.

The problem is that working around, for example by fixing the mirrors

or figuring out how to fetch a dependency from the right place can be

tricky. It's often easier to go and check the dependency and/or metadata

and approve it.

For this purpose, the verification metadata file now includes the

ability to have "alternate", trusted checksums. It also adds the ability

to tell where a checksum comes from, as indication to the reader. Checksums

generated by Gradle will be marked as such, and therefore a reader can

see that they are less "trustworthy" than checksums fetched by a human.

    • -7
    • +5
    ./ImmutableArtifactVerificationMetadata.java
  1. … 10 more files in changeset.
Make verification model more resilient to real world projects

Dogfooding the Gradle build with dependenvy verification proved to

be helpful. There are quite a few cases where we discover dependencies

which come from different repositories. Reposiories can also be mirrored

and sometimes the mirror doesn't mirror what is was supposed to.

The problem is that working around, for example by fixing the mirrors

or figuring out how to fetch a dependency from the right place can be

tricky. It's often easier to go and check the dependency and/or metadata

and approve it.

For this purpose, the verification metadata file now includes the

ability to have "alternate", trusted checksums. It also adds the ability

to tell where a checksum comes from, as indication to the reader. Checksums

generated by Gradle will be marked as such, and therefore a reader can

see that they are less "trustworthy" than checksums fetched by a human.

    • -7
    • +5
    ./ImmutableArtifactVerificationMetadata.java
  1. … 10 more files in changeset.
De-duplicate entries based on file name instead of artifact id

Because Gradle internally sometimes uses `DefaultModuleComponentArtifactIdentifier`

or `ModuleComponentFileArtifactIdentifier` for the same artifact depending on the

context, we can't rely on equality here. This commit changes the internal verification

structure to rely on the file name which is more consistent and fixes duplication

issues.

    • -6
    • +29
    ./ImmutableArtifactVerificationMetadata.java
  1. … 7 more files in changeset.
De-duplicate entries based on file name instead of artifact id

Because Gradle internally sometimes uses `DefaultModuleComponentArtifactIdentifier`

or `ModuleComponentFileArtifactIdentifier` for the same artifact depending on the

context, we can't rely on equality here. This commit changes the internal verification

structure to rely on the file name which is more consistent and fixes duplication

issues.

    • -6
    • +29
    ./ImmutableArtifactVerificationMetadata.java
  1. … 7 more files in changeset.
De-duplicate entries based on file name instead of artifact id

Because Gradle internally sometimes uses `DefaultModuleComponentArtifactIdentifier`

or `ModuleComponentFileArtifactIdentifier` for the same artifact depending on the

context, we can't rely on equality here. This commit changes the internal verification

structure to rely on the file name which is more consistent and fixes duplication

issues.

    • -6
    • +29
    ./ImmutableArtifactVerificationMetadata.java
  1. … 7 more files in changeset.
De-duplicate entries based on file name instead of artifact id

Because Gradle internally sometimes uses `DefaultModuleComponentArtifactIdentifier`

or `ModuleComponentFileArtifactIdentifier` for the same artifact depending on the

context, we can't rely on equality here. This commit changes the internal verification

structure to rely on the file name which is more consistent and fixes duplication

issues.

    • -6
    • +29
    ./ImmutableArtifactVerificationMetadata.java
  1. … 7 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Generate checksum file for dependency verification

This commit introduces the generation of a dependency

verification metadata file from the CLI. If the user

calls `--write-verification-metadata`, then an XML

file is generated (`gradle/verification-metadata.xml`).

This file will contain the checksums for all artifacts

required by a build, which includes:

- plugin artifacts

- jars and other artifacts requested via a `configuration`

- secondary artifacts (javadocs, classifiers, ...)

It does NOT include metadata of those artifacts (pom files,

ivy files, Gradle Module metadata).

It isn't required to resolve any configuration to get this

behavior: the build will automatically process all resolvable

configurations and _try_ to resolve them automatically. All

artifacts resolved during this process are going to be automatically

downloaded (if not already). Then SHA-1 and SHA-512 checksums

are computed for all those artifacts.

The current format is an XML file planned to support more than

just artifacts: module metadata AND signature information is

planned.

See #11398

    • -0
    • +26
    ./ArtifactVerificationMetadata.java
    • -0
    • +26
    ./ComponentVerificationMetadata.java
    • -0
    • +41
    ./ImmutableArtifactVerificationMetadata.java
    • -0
    • +41
    ./ImmutableComponentVerificationMetadata.java
  1. … 28 more files in changeset.
Spike generating an XML file with SHA512 checksums

  1. … 6 more files in changeset.
Spike generating an XML file with SHA512 checksums

    • -0
    • +39
    ./ArtifactVerification.java
    • -0
    • +39
    ./ComponentVerification.java
    • -0
    • +32
    ./DependencyVerifier.java
    • -0
    • +69
    ./VerificationsBuilder.java
  1. … 5 more files in changeset.