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

fix pubkey interning test #104

Merged
merged 16 commits into from
Jun 23, 2024
Merged

fix pubkey interning test #104

merged 16 commits into from
Jun 23, 2024

Conversation

Geal
Copy link
Contributor

@Geal Geal commented Jun 16, 2024

No description provided.

Copy link
Collaborator

@divarvel divarvel left a comment

Choose a reason for hiding this comment

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

Overall LGTM. Most of the comments are actually questions to make sure I did not miss anything.

The PR is selling itself short, as it's not just the test that required fixing, it seems :-)

There's a minor refactoring suggestion for algorithm serialization.

Apart from that and it's not related to the PR itself, but I think the spec conformance suite should come with 3rd party request / contents samples that should be parsed / used by implementations with the resulting token checked against an expected result (not byte-for-byte, but at least contents)

@@ -180,7 +180,7 @@ public String print_scope(final Scope scope) {
return pk.get().toString();
}
}
return "?";
return "<"+ scope.publicKey+"?>";
Copy link
Collaborator

Choose a reason for hiding this comment

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

shouldn't this throw instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

probably, but then it would trigger changs all over the API. I'll attempt that in a follow up PR

@@ -88,10 +86,14 @@ public static Biscuit make(final SecureRandom rng, final KeyPair root, final Int
* @param authority authority block
* @return Biscuit
*/
static private Biscuit make(final SecureRandom rng, final KeyPair root, final Option<Integer> root_key_id, final Block authority) throws Error.FormatError {
static Biscuit make(final SecureRandom rng, final KeyPair root, final Option<Integer> root_key_id, final Block authority) throws Error.FormatError {
Copy link
Collaborator

Choose a reason for hiding this comment

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

why was this private / how was it supposed to be called previously?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this one was used from other overloaded make static methods, I forgot to move it back to private. In the next major version, all the make static methods will be private, I'll remove them from the API

ArrayList<Block> blocks = new ArrayList<>();

KeyPair next = new KeyPair(rng);
KeyPair next = KeyPair.generate(root.public_key().algorithm, rng);
Copy link
Collaborator

Choose a reason for hiding this comment

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

so by default, it will use the same algorithm as the root key for attenuation. That's interesting, i think this should be discussed in the ECDSA PR (and in the spec at some point)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes, that's something that should be discussed

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm moving it back to hardcoded Ed25519 for now

@@ -48,7 +48,7 @@ public Block(SymbolTable base_symbols) {
this.scopes = new ArrayList<>();
this.publicKeys = new ArrayList<>();
this.externalKey = Option.none();
this.version = SerializedBiscuit.MAX_SCHEMA_VERSION;
this.version = SerializedBiscuit.MIN_SCHEMA_VERSION;
Copy link
Collaborator

Choose a reason for hiding this comment

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

is this used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no, it is not used, the block version is derived when serializing. I'm removing the field.

@@ -18,15 +18,13 @@
import java.util.*;

public class Block {
long index;
Copy link
Collaborator

Choose a reason for hiding this comment

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

do you know why it was there in the first place?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

because the builder API had methods that create "the block at index i" instead of creating a generic block builder that can then be appended. There's so much in this API we have to fix

sgr.initVerify(externalKey.key);

sgr.update(blockResponse.payload);
ByteBuffer algo_buf = ByteBuffer.allocate(4).order(ByteOrder.LITTLE_ENDIAN);
Copy link
Collaborator

Choose a reason for hiding this comment

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

this serialization logic might be better encapsulated in a method rather than inlined here (and i assume in other places)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

something to look at after the ECDSA PR has merged, I think, otherwise we'll get lots of conflicts

Choose a reason for hiding this comment

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

I tried abstract this into a function for my remote_signer branch however these new third party tests are the only ones which are failing when trying to rebase my branch. Still digging into it, not sure whether subtle nuance or not.

Choose a reason for hiding this comment

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

Think I see my issue, around the externalSignature which appears to be specific to third party.

}

long pkIndex = symbols.insert(externalKey);
// if (copiedBiscuit.publicKeyToBlockId.
Copy link
Collaborator

Choose a reason for hiding this comment

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

this can be removed i assume

@Geal Geal merged commit 942fbb9 into master Jun 23, 2024
1 check passed
itstheceo referenced this pull request in phocassoftware/biscuit-java Jun 25, 2024
This implements 3rd party block generation and appending to existing tokens. It also fixes existing issues with public key interning which made deserialization of tokens with 3rd party blocks incorrect in some cases.

Co-authored-by: Geoffroy Couprie <[email protected]>
itstheceo referenced this pull request in phocassoftware/biscuit-java Jun 25, 2024
Implement 3rd party block creation (#104)
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.

3 participants