Add matrix testing for VSS authorizer variants

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!

[enigbe]

What this PR does

With the addition of a public key-based authenticator and the option to verify JWT tokens on vss-server, the default vss-server build now requires authentication, so our integration tests need to either provide valid headers or explicitly build for the no-opauthenticator. This is why the VSS CI has been failing lately.

To address this, we run VSS integration tests against multiple server authorizer configurations (noop, sig, jwt). Each matrix job builds vss-server with the appropriate flags and passes the corresponding cfg flag and features to the test runner.

The summary of changes introduced include:

• Passing authorizer-specific cfg flags and features for test differentiation
• The addition of test_utils feature with JWT- and signature-based header generation
• The addition of RSA keypair fixtures for JWT signing and verification
• The update of VSS-related tests to use auth-aware headers

[ldk-reviews-bot]

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tnull]

Hmm, we're about to upstream VssStore to lightning-persister, and we're just waiting for #755 before doing that. So I'd rather not add more complexity here that we then have to migrate. Could make sense to add it to lightning-persister afterwards, although I have to say I'm not fully sold.

[enigbe]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

[tnull]

Figured I'd fix the failing test after noticing failure on commits in mine and other PRs. I'll just close this given that with #755 landing, we'd have no need for this.

Yeah, thank you for that!