See https://settings.stage.mozaws.net/v1/buckets/security-state/collections/intermediates/records

The attachment location attribute contains a path for stage data:
E.g: "security-state-staging/intermediates/0bb638b8-6e5d-40ba-b504-de097b77f0ab.pem"

Either these attributes should be modified to reflect production settings prior to collection signing, or any bucket specific details should be omitted from the data and instead moved to application configuration.

Note that specifically attachments, once approved/signed, are never copied/moved to the new non-staging namespace.

For example, taking element 0 of https://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/intermediates/records:

The existence of https://firefox-settings-attachments.cdn.mozilla.net/security-state-staging/intermediates/65650a0f-7c22-4c10-9744-2d67e301f5f4.pem implies the existence of a non-staging version https://firefox-settings-attachments.cdn.mozilla.net/security-state/intermediates/65650a0f-7c22-4c10-9744-2d67e301f5f4.pem, there is not such a file.

Indeed, the attachment location contains the name of the bucket where attachments were uploaded. We don't copy them.

But the file locations are randomized on upload and attachments are never deleted. That means that once published the attachment will always remain available even if the related source record is deleted.

So apart from the URL containing the word «staging», there's no real consequence. Is that an issue?

(In reply to Mathieu Leplatre [:leplatrem] from comment #2)

So apart from the URL containing the word «staging», there's no real consequence. Is that an issue?

I don't think so (other than cosmetics).

With those semantics, I agree is OK. Thanks!