fix: STOREFRONT_PROOF is a secret #545

volmedo · 2025-11-18T13:21:18Z

These changes require storacha/upload-service#570 to land first.

Handle STOREFRONT_PROOF as a secret rather than an environment variable.

Also, I noticed that some of the functions that were referencing the proof were not actually having it passed when defined in the stack, so I bound the secret to their configs.

Finally, the STOREFRONT_PROOF was renamed to AGGREGATOR_SERVICE_PROOF, as that aligns with what it actually is. I also removed the storefront proof from everywhere, based on the assumption that the storefront service will always be the upload service. Thus, invocations to the storefront service (the filecoin/* family of capabilities) are self-signed by the upload service and require no proofs.

seed-deploy · 2025-11-18T13:33:13Z

View stack outputs

pr545-upload-api-BillingDbStack

Name	Value
customerTableName	pr545-upload-api-customer
egressTrafficTableName	pr545-upload-api-egress-traffic-events
spaceDiffTableName	pr545-upload-api-space-diff
spaceSnapshotTableName	pr545-upload-api-space-snapshot
usageTable	pr545-upload-api-usage

pr545-upload-api-BillingStack

Name	Value
ApiEndpoint	https://8wkpclqq47.execute-api.us-east-2.amazonaws.com
billingCronHandlerURL	https://6ons7v5jjqwegeoscjwmlwc6d40mvfrf.lambda-url.us-east-2.on.aws/
CustomDomain	https://pr545.billing.forge.storacha.network
EgressTrafficQueueURL	https://sqs.us-east-2.amazonaws.com/505595374361/pr545-upload-api-egress-traffic-queue

pr545-upload-api-CarparkStack

Name Value

BucketName pr545-upload-api-carpark-0

Region us-east-2
pr545-upload-api-RoundaboutStack

Name Value

ApiEndpoint https://staging.roundabout.web3.storage/

CustomDomain Using ROUNDABOUT_API_URL - no custom domain
pr545-upload-api-UcanInvocationStack

Name Value

agentIndexBucketName pr545-upload-api-invocation-store-0

agentMessageBucketName pr545-upload-api-workflow-store-0
pr545-upload-api-UploadApiStack

Name Value

ApiEndpoints ["https://jrbuidzv37.execute-api.us-east-2.amazonaws.com"]

CustomDomains ["https://pr545.up.forge.storacha.network"]
pr545-upload-api-BusStack
pr545-upload-api-FilecoinStack
pr545-upload-api-UcanFirehoseStack
pr545-upload-api-UploadDbStack

volmedo · 2025-11-18T13:46:19Z

filecoin/functions/handle-cron-tick.js

  let id = getServiceSigner({
    privateKey
  })
  const storefrontServiceProofs = []


the proof is parsed but then it's not used anywhere. I guess it should go in the context object below?

😩 yeah it's going to require changes in storefrontEvents.handleCronTick to accept the proof. It needs the proof so that effect it creates has the correct CID.

We should also do id = id.withDID(DID.parse(did).did()) regardless.

😩 yeah it's going to require changes in storefrontEvents.handleCronTick to accept the proof. It needs the proof so that effect it creates has the correct CID.

I just understood this comment 😞

volmedo · 2025-11-18T13:47:57Z

filecoin/functions/handle-piece-insert-to-filecoin-submit.js

  let storefrontSigner = getServiceSigner({
    privateKey
  })


is this correct? Shouldn't this have the upload service's DID if we are using a proof?

volmedo · 2025-11-18T13:51:15Z

filecoin/functions/handle-piece-insert-to-filecoin-submit.js

        issuer: storefrontSigner,
        with: storefrontSigner.did(),
        audience: storefrontSigner,


oh, ok, so I guess we need both the aggregator service's DID and the upload service's DID to fix this invocation config

Yeah, the proof should be a proof for the uplaod service to use the aggregator and the aggregator DID needs to be the audience.

hannahhoward

LGTM by me

alanshaw

From a consistency POV I like this, but really the only reason the other proofs are secrets is because of the environment variable size limit which we are close to with the ucan-invocation-router.js lambda. We are not anywhere near that limit for these other lambdas so it is not really necessary.

If we do this, I would rather that we combine it with renaming the variable more appropriately. It should be named after the service it is used with, not the service that is using it (otherwise all proofs would be "storefront"/"upload service"!). This is already confused in the code here.

Unfortunately there is a bunch more work here than just moving an environment variable to secrets.

alanshaw · 2025-11-24T15:43:00Z

filecoin/functions/handle-cron-tick.js

  let id = getServiceSigner({
    privateKey
  })
  const storefrontServiceProofs = []


😩 yeah it's going to require changes in storefrontEvents.handleCronTick to accept the proof. It needs the proof so that effect it creates has the correct CID.

alanshaw · 2025-11-24T15:43:37Z

filecoin/functions/handle-cron-tick.js

  let id = getServiceSigner({
    privateKey
  })
  const storefrontServiceProofs = []


We should also do id = id.withDID(DID.parse(did).did()) regardless.

alanshaw · 2025-11-24T15:46:07Z

filecoin/functions/handle-piece-insert-to-filecoin-submit.js

        issuer: storefrontSigner,
        with: storefrontSigner.did(),
        audience: storefrontSigner,


Yeah, the proof should be a proof for the uplaod service to use the aggregator and the aggregator DID needs to be the audience.

volmedo · 2025-11-27T16:39:55Z

If we do this, I would rather that we combine it with renaming the variable more appropriately. It should be named after the service it is used with, not the service that is using it (otherwise all proofs would be "storefront"/"upload service"!). This is already confused in the code here.

Unfortunately there is a bunch more work here than just moving an environment variable to secrets.

It wasn't clear to me that storefront was actually referring to the upload-service 🤷🏻

I'm working on this.

volmedo · 2025-12-03T12:50:57Z

@alanshaw I renamed STOREFRONT_PROOF to AGGREGATOR_SERVICE_PROOF and wired it where needed. The rest of the work required to pass the aggregator proof down is in storacha/upload-service#570.

There were also some functions getting a storefront proof, which allows using a storefront service that is not the upload service. I removed this possibility for now to simplify the code because we are not using it today. If you think we need that flexibility, let me know and I'll implement it properly.

volmedo self-assigned this Nov 18, 2025

volmedo requested a review from alanshaw as a code owner November 18, 2025 13:21

seed-deploy bot temporarily deployed to pr545 November 18, 2025 13:21 Inactive

seed-deploy bot had a problem deploying to pr545 November 18, 2025 13:21 Failure

volmedo commented Nov 18, 2025

View reviewed changes

hannahhoward approved these changes Nov 19, 2025

View reviewed changes

Base automatically changed from ash/fix/proof-parsing to main November 19, 2025 21:23

alanshaw reviewed Nov 24, 2025

View reviewed changes

volmedo added 2 commits November 28, 2025 14:55

fix: STOREFRONT_PROOF is a secret

e7f623d

storefront proof is now aggregator proof and passed where needed

5b1064e

volmedo force-pushed the vic/fix/storefront-proof-is-a-secret branch from 901f47a to 5b1064e Compare December 3, 2025 12:39

seed-deploy bot deployed to pr545 December 3, 2025 12:39 View deployment

seed-deploy bot had a problem deploying to pr545 December 3, 2025 12:39 Failure

fix: STOREFRONT_PROOF is a secret #545

Are you sure you want to change the base?

fix: STOREFRONT_PROOF is a secret #545

Conversation

volmedo commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seed-deploy bot commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hannahhoward left a comment

Choose a reason for hiding this comment

Uh oh!

alanshaw left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

volmedo commented Nov 27, 2025

Uh oh!

volmedo commented Dec 3, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

volmedo commented Nov 18, 2025 •

edited

Loading