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

Docs/examples #151

Merged
merged 25 commits into from
Nov 6, 2024
Merged

Docs/examples #151

merged 25 commits into from
Nov 6, 2024

Conversation

JesusMcCloud
Copy link
Collaborator

goes directly back to main, so we can re-publish docs

@JesusMcCloud JesusMcCloud force-pushed the docs/examples branch 2 times, most recently from 5322693 to d1fb7c4 Compare October 4, 2024 09:42
@iaik-jheher
Copy link
Collaborator

without having reviewed the changes, i would strongly prefer if all PRs were targeted at development; if we merge directly into main, we need to rebase the commits from development onto main when the next release happens

@JesusMcCloud JesusMcCloud changed the base branch from main to development October 4, 2024 15:22
@JesusMcCloud
Copy link
Collaborator Author

Sorry! forgot to change the taget branch on GitHub. this does indeed target development!

@JesusMcCloud
Copy link
Collaborator Author

ok the test sometimes producing legal ASN.1 structures where they should be random also needs to be addressed, but this is also a separate issue

@iaik-jheher
Copy link
Collaborator

ok the test sometimes producing legal ASN.1 structures where they should be random also needs to be addressed, but this is also a separate issue

is this something that is introduced by this commit? i would prefer not to have randomly-failing tests in development, it builds a tolerance for red Xs

@JesusMcCloud
Copy link
Collaborator Author

ok the test sometimes producing legal ASN.1 structures where they should be random also needs to be addressed, but this is also a separate issue

is this something that is introduced by this commit? i would prefer not to have randomly-failing tests in development, it builds a tolerance for red Xs

nope, was always like that

Now, everything is ready to be signed:

```kotlin
val signature = signer.sign(plainSignatureInput.encodeToByteArray()).signature //TODO: handle error
Copy link
Collaborator

Choose a reason for hiding this comment

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

should prepareJwsSignatureInput return ByteArray? I don't see a use case for it returning String

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well, we're talking JSON here, so everything's a string. therefore, you need this string to construct the JwsSigned.

Copy link
Collaborator

Choose a reason for hiding this comment

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

yes, but a "signature input" is bytes; the fact that those bytes contain a json representation is an implementation detail; imo prepare...SignatureInput should return ByteArray instead of the caller having to explicitly do string -> bytes

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this is literally the string that is in the JWT. @nodh your take?

@JesusMcCloud JesusMcCloud merged commit 30ceb8b into development Nov 6, 2024
7 checks passed
JesusMcCloud added a commit that referenced this pull request Nov 7, 2024
* `JwsSignes.plainsignatureInput` is now a raw ByteArray
  * `JwsSigned.prepareSignatureInput` now returns a raw ByteArray
* Introduce `prepareDigestInput()` to `IosHomebrewAttestation`
* Remove Legacy iOS Attestation
@JesusMcCloud JesusMcCloud deleted the docs/examples branch November 14, 2024 16:20
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