Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

force using signature v1 in more cases #246

Merged
merged 2 commits into from
Nov 21, 2024
Merged

force using signature v1 in more cases #246

merged 2 commits into from
Nov 21, 2024

Conversation

divarvel
Copy link
Collaborator

@divarvel divarvel commented Nov 20, 2024

We want to progressively roll out signature v1, without breaking existing implementations. This means we can force signature v1 everywhere a recent library version would still be required:

  • all v3.3+ datalog blocks
  • all blocks signed with something other than ed25519
  • all tokens already containing a block using signature v1

In addition to that, third-party blocks always require signature v1, which is the only breaking change we allow

Enabling these changes on samples made me realize the integer wraparound sample used datalog v3.3 features (lenient not equals), so I updated it to make it use the strict version.

@@ -388,10 +424,15 @@ impl SerializedBiscuit {
) -> Result<Self, error::Token> {
let keypair = self.proof.keypair()?;

// The version block is not directly available, so we don’t take it into account here
// `append_serialized` is only used for third-party blocks anyway, so maybe we should make `external_signature` mandatory and not bother
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Geal what do you think about modifying append_serialized to require an external key?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the external key is available in ExternalSignature

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m talking about making the argument mandatory (it’s an option for now), but the function is never called with None in the library itself, and i’m not sure why it is exposed publicly

@divarvel divarvel requested a review from Geal November 20, 2024 13:42
Copy link

codspeed-hq bot commented Nov 20, 2024

CodSpeed Performance Report

Merging #246 will not alter performance

Comparing force-sig-v1 (bf80230) with v5 (d956655)

Summary

✅ 12 untouched benchmarks

Copy link

codecov bot commented Nov 20, 2024

Codecov Report

Attention: Patch coverage is 85.00000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 65.16%. Comparing base (d956655) to head (bf80230).
Report is 3 commits behind head on v5.

Files with missing lines Patch % Lines
biscuit-auth/src/format/mod.rs 85.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##               v5     #246      +/-   ##
==========================================
+ Coverage   65.14%   65.16%   +0.01%     
==========================================
  Files          27       27              
  Lines        6972     6981       +9     
==========================================
+ Hits         4542     4549       +7     
- Misses       2430     2432       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


🚨 Try these New Features:

Comment on lines 297 to 304
let authority_signature_version = if authority.version >= DATALOG_3_3 {
DATALOG_3_3_SIGNATURE_VERSION
} else {
match (root_keypair, next_keypair) {
(KeyPair::Ed25519(_), KeyPair::Ed25519(_)) => 0,
_ => NON_ED25519_SIGNATURE_VERSION,
}
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the version decision should be moved to another function that can be reused for each block

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the decision is a bit different based on each case (creating a biscuit does not have previous crypto::Block available, append_serialized does not have a Block available either), so the common function will be a bit less readable

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have done it in a separate commit. the function itself is a bit harder to read and we’re forced to use explicit iterators, but it’s indeed better to have the logic in a single place. as a bonus i was able to write tests instead of just relying on samples

@@ -388,10 +424,15 @@ impl SerializedBiscuit {
) -> Result<Self, error::Token> {
let keypair = self.proof.keypair()?;

// The version block is not directly available, so we don’t take it into account here
// `append_serialized` is only used for third-party blocks anyway, so maybe we should make `external_signature` mandatory and not bother
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the external key is available in ExternalSignature

We want to progressively roll out signature v1, without breaking existing implementations. This means we can force signature v1 everywhere a recent library version would still be required:

- all v3.3+ datalog blocks
- all blocks signed with something other than ed25519
- all tokens already containing a block using signature v1

In addition to that, third-party blocks always require signature v1, which is the only breaking change we allow
This makes this sample usable with older implementations
@divarvel divarvel merged commit fe3e74d into v5 Nov 21, 2024
7 checks passed
@divarvel divarvel deleted the force-sig-v1 branch November 21, 2024 14:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants