HttpServerFixture.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.

  1. … 63 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.

  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.

  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.

  1. … 63 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.

  1. … 63 more files in changeset.
Improve advice for dealing with insecure HTTP script plugins

  1. … 6 more files in changeset.
Make IDEA happy with a Groovy test fixture

Revert "Revert "Merge remote-tracking branch 'origin/sg/merges/pr-9419'""

This reverts commit 0625bc7420e55e87730673231af6ad45dd04f47a.

  1. … 90 more files in changeset.
Revert "Revert "Merge remote-tracking branch 'origin/sg/merges/pr-9419'""

This reverts commit 0625bc7420e55e87730673231af6ad45dd04f47a.

  1. … 90 more files in changeset.
Revert "Merge remote-tracking branch 'origin/sg/merges/pr-9419'"

This reverts commit 2f79026f5e127a8175e25844522237615b19ed52 because of a performance regression,

reversing changes made to 7f1e66079ce629ecde3e09e549e9796ab85761dc.

  1. … 90 more files in changeset.
Add integration tests for TextResources and remote script plugins

  1. … 6 more files in changeset.
Add integration tests for TextResources and remote script plugins

  1. … 6 more files in changeset.
Merge branch 'master' into deprecate_http_download

Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

  1. … 6 more files in changeset.
Allow http for 127.0.0.1

Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

  1. … 16 more files in changeset.
Introduce HTTPS-supporting BlockingHttpsServer

- Fix WrapperHttpsIntegrationTest

  1. … 3 more files in changeset.
Migrate to Jetty 9

  1. … 20 more files in changeset.
Store prgress

  1. … 5 more files in changeset.
Support HTTP header based authentication for Maven repositories

Now it's possible to use a custom HTTP header to authorize access to

Maven repositories. This enables Gradle to access private GitLab and TFS

repositories used as Maven repositories or any OAuth2 protected Maven

repository.

Resolves #5571.

  1. … 30 more files in changeset.
Rework how `HttpServerFixture` handles connection

Previously, a connector was assigned to the server, then the server was

started, and we entered a loop to check if connection was successful. If

not, then we tried again.

However, the initial `start()` could fail, because we already assigned

a connector which was started. If for some reason the port is unavailable,

or another error occurs, then we never entered the retry loop.

This commit fixes the problem by starting the server first, *then* assign

and start a connector.

Rework how `HttpServerFixture` handles connection

Previously, a connector was assigned to the server, then the server was

started, and we entered a loop to check if connection was successful. If

not, then we tried again.

However, the initial `start()` could fail, because we already assigned

a connector which was started. If for some reason the port is unavailable,

or another error occurs, then we never entered the retry loop.

This commit fixes the problem by starting the server first, *then* assign

and start a connector.

Use port allocator consistently in HttpServerFixture

  1. … 3 more files in changeset.
Fix connector handling mechanism

Revert "Revert "Introduce HTTP timeout (#3041)""

This reverts commit 14711361a0cb6beb3a57766804c109ba6f3f87c0.

  1. … 12 more files in changeset.
Revert "Introduce HTTP timeout (#3041)"

This reverts commit 59153d58c906341cfe3b5bebbedf289e3def1e09.

  1. … 12 more files in changeset.
Introduce HTTP timeout (#3041)

Introduce HTTP connection and socket timeout

Fix https://github.com/gradle/gradle/issues/868

  1. … 12 more files in changeset.
Use PortAllocator in http script tests (#3040)

Fix https://github.com/gradle/gradle-private/issues/948

  1. … 2 more files in changeset.
Fix flaky tests caused by accidental cache hit (#3025)

gradle/gradle-private#948

When two tests happen to be assigned the same port number, the cache

is hit by accident. This result in different control flows and flaky tests.

  1. … 1 more file in changeset.
Fix concurrency bug in `HttpClientHelper`

The HTTP context should not be shared by several requests, or it just breaks when requests are done in parallel.

This explains the failures seen with `NTLM` authentication, but not only: there were more failures with `BASIC`

authentication too (and probably random other failures).

This commit changes the `HttpContext` so that we create a new one per request, in case we don't use authentication,

and if we do, then requests cannot be done in parallel (until we find a proper fix). This removes the special case in

`HttpAuthenticationDependencyResolutionIntegrationTest`.

  1. … 4 more files in changeset.
Add authentication support to HttpServerFixture

This allows to enable authentication on the BuildCache for

integration tests.

+review REVIEW-6479

  1. … 14 more files in changeset.
Add performance test for http build cache

+review REVIEW-6440

    • -0
    • +110
    ./HttpServerFixture.groovy
  1. … 6 more files in changeset.