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

feat: access agent proofs method would fail to return some session proofs #1047

Merged
merged 27 commits into from
Nov 1, 2023

Conversation

gobengo
Copy link
Contributor

@gobengo gobengo commented Oct 31, 2023

Motivation:

Context

  • Why does this fix it?
    • previously, it was possible for calls to Agent#registerSpace to fail due to invalid proofs, even if the underlying AgentData had the right proof. This was because registerSpace ends up calling invokeAndExecute(Provider.add), which calls invoke to build the invocation, which calls proofs to get the proofs for the invocation. And proofs could fail to include a sessionProof that was appropriate for the invocation audience of the invocation built by Agent#invoke. Now, Agent#proofs returns all the sessionProofs that might be relevant.
  • explanation of underlying cause of that w3cli issue 113 feat: access agent proofs method would fail to return some session proofs #1047 (comment)

@gobengo gobengo changed the title W3cli 113 unauthorized sessionproofs access agent proofs method chooses sessionProofs based on invocationAudience Oct 31, 2023
@gobengo gobengo requested a review from travis October 31, 2023 00:17
@gobengo gobengo changed the title access agent proofs method chooses sessionProofs based on invocationAudience fix: access agent proofs method chooses sessionProofs based on invocationAudience Oct 31, 2023
@gobengo gobengo changed the title fix: access agent proofs method chooses sessionProofs based on invocationAudience feat: access agent proofs method chooses sessionProofs based on invocationAudience Oct 31, 2023
@gobengo gobengo marked this pull request as ready for review October 31, 2023 00:17
Copy link
Member

@alanshaw alanshaw left a comment

Choose a reason for hiding this comment

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

I don't really understand how this fixes the issue.

packages/access-client/src/agent-data.js Outdated Show resolved Hide resolved
packages/access-client/src/agent-data.js Outdated Show resolved Hide resolved
packages/access-client/src/agent-data.js Outdated Show resolved Hide resolved
packages/access-client/src/agent.js Outdated Show resolved Hide resolved
* @returns {Record<string, Ucanto.Delegation>}
*/
export function getSessionProofs(data) {
export function getSessionProofs(data, issuer) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Part of what was causing the bug is that this function ends up building a map of CIDs to proofs. The CID it uses is the nb.proof from a ucan/attest. The agent might actually have multiple ucan/attest ucans with the same nb.proof CID, but with different issuers. Previously only one of these delegations would end up in the returned map from this function, and the caller had no way of getting a session proof appropriate for the audience of their request.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is fairly low level API so I suggest a breaking change that will change return type to

Record<Ucanto.DID, Record<string, ...Ucanto.Delegation>>

That way things will work correctly even if you do not pass the issuer. Furthermore I do have use case where I query proofs and I do not know the issuer of attestations so getting all the proofs would be desired there.

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 did something like that here a9aedf6

@travis travis requested a review from Gozala October 31, 2023 17:07
Copy link
Contributor

@travis travis left a comment

Choose a reason for hiding this comment

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

One bit of cleanup, but I do think the proofs method signature needs some thought - happy to chat in higher bandwidth whenever's convenient for you!

packages/access-client/src/agent.js Outdated Show resolved Hide resolved
packages/access-client/src/agent.js Outdated Show resolved Hide resolved
@gobengo gobengo changed the title feat: access agent proofs method chooses sessionProofs based on invocationAudience feat: access agent proofs method chooses sessionProofs based on options.sessionProofIssuer Oct 31, 2023
@gobengo gobengo requested a review from travis October 31, 2023 21:28
@gobengo
Copy link
Contributor Author

gobengo commented Oct 31, 2023

I met with @Gozala about this and he agreed it makes sense. In the medium term we both don't love the Agent#proofs method API as is, and think maybe Agent#invoke should use something else to find the proofs for an invocation, but adding this option is a good stopgap to fix the bug in a backward-compatible way.

…service id. to avoid attestations from separate issuers having identical CID
Copy link
Contributor

@travis travis left a comment

Choose a reason for hiding this comment

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

looks good, thanks!

@gobengo gobengo force-pushed the w3cli-113-unauthorized-sessionproofs branch from 7163363 to a9aedf6 Compare October 31, 2023 23:00
@gobengo gobengo changed the title feat: access agent proofs method chooses sessionProofs based on options.sessionProofIssuer feat: access agent proofs method would fail to return some session proofs Oct 31, 2023
Copy link
Contributor

@Gozala Gozala left a comment

Choose a reason for hiding this comment

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

Approved with some suggestions

packages/upload-api/src/access/confirm.js Outdated Show resolved Hide resolved
*/
export function getSessionProofs(data) {
/** @type {Record<string, Ucanto.Delegation>} */
/** @type {Record<string, [Ucanto.Delegation, ...Ucanto.Delegation[]]>} */
Copy link
Contributor

Choose a reason for hiding this comment

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

This is ok but I would prefer Record<Ucanto.DID, Record<string, ...Ucanto.Delegation>> per #1047 (comment) because it makes it a lot easier to pick the ones you care and throw away others as opposed to having to go and group them in another loop.

Not a big deal, but unless there is compelling reason to prefer this I would suggest reverse.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Gozala roger. I will change to that.

I assume the keys of the inner record (typed as string) would be session proof issuer? and keys of outer record would be the attested to proof cid?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

did it 914405d

@gobengo gobengo force-pushed the w3cli-113-unauthorized-sessionproofs branch from f062abb to 914405d Compare November 1, 2023 16:49
…ilter session proofs to once issuer. Agent invoke method uses it. This is required for the registerSpace request to work against staging rn
@gobengo
Copy link
Contributor Author

gobengo commented Nov 1, 2023

I was about to merge this, then did one last bit of testing in my local setup to make sure all this would still fix the situation for #113, but noticed that when I tried, I got a new 500 error from the backend. Two days ago I had tested and it worked. I think the regression happened because yesterday I took out the Agent#proofs option.sessionProofIssuer filter. This led to a simpler API, but at the cost of sometimes sending more sessionProofs than are needed in the invocation. I figured it would be harmless. But actually it was not harmless. Sending all those session proofs incl from unknown (to that service) issuers resulted in the upload-api lambda timing out for 10 seconds. I looked and was unable to find logs/sentry info that would hint at why, but my guess is that it was in the proof checking.

So I re-introduced options.sessionProofIssuer to Agent#proofs and re-added using it when Agent#invoke calls Agent#proofs to get proofs for the invocation. Once I made this change so ensure that Agent#invoke invocation doesn't include proof for sessions issued by issuers other than the invocation audience, then things work again.
I did that in this commit a1cee5e

@gobengo gobengo merged commit d23a1c9 into main Nov 1, 2023
5 checks passed
@gobengo gobengo deleted the w3cli-113-unauthorized-sessionproofs branch November 1, 2023 20:08
gobengo pushed a commit that referenced this pull request Nov 1, 2023
🤖 I have created a release *beep* *boop*
---


##
[16.4.0](access-v16.3.0...access-v16.4.0)
(2023-11-01)


### Features

* access agent proofs method would fail to return some session proofs
([#1047](#1047))
([d23a1c9](d23a1c9))


### Bug Fixes

* use the issuer as the resource in revocation
([#992](#992))
([7346d1f](7346d1f))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
gobengo added a commit to storacha/w3cli that referenced this pull request Nov 1, 2023
gobengo added a commit to storacha/w3cli that referenced this pull request Nov 1, 2023
…roof selection with `w3 register space` (#114)

Motivation:
* make use of storacha/w3up#1047 and expect
it to fix #113
Gozala pushed a commit that referenced this pull request Nov 3, 2023
🤖 I have created a release *beep* *boop*
---


##
[7.1.0](upload-api-v7.0.0...upload-api-v7.1.0)
(2023-11-03)


### Features

* access agent proofs method would fail to return some session proofs
([#1047](#1047))
([d23a1c9](d23a1c9))
* expose test context of upload-api
([#1069](#1069))
([f0757d1](f0757d1))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
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.

4 participants