3 ms·

Well, if Stripe wants you to stop accepting payments, you will. They already can take the resource offline, I don't see how this is a new/additional problem. I

Well, if Stripe wants you to stop accepting payments, you will. They already can take the resource offline, I don't see how this is a new/additional problem. If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag.

LukeShu 10y ago
You, as the web developer, want to start using subresource-integrity. Stripe, as a depended-upon 3rd party, has not yet bought in to subresource-integrity hype-train. Stripe rolls out a fix for a security issue or other bug in their JS. This breaks your subresource-integrity check. The didn't want you to stop accepting payments, they wanted to fix a vuln. That hampers the usefulness of using subresource-integrity on 3rd-party resources today (which is what yeldarb suggested). Perhaps in the future the 3rd party would provide a script that emits the URL/SRI, but that isn't today.
- jffry 10y ago
  the 3rd party would provide a script that emits the URL/SRI And we're back to square one - we can't trust _that_ script to not get pwned
  - cryptarch 10y ago
    Not really, isn't packaging and securely distributing PHP/Node.js libraries a solved problem?
    - johncolanduoni 10y ago
      If you're not updating the PHP/Node.js library, and you're not updating any data you give it, where does it get the information it needs to update the URL/SRI tag? And if you are doing any of those things when Stripe pushes an update, how is it any different that having to update the URL/SRI tag?
- cryptarch 10y ago
  Ok, so how about caching the Stripe script and serving it yourself, then polling for new versions and then updating the cache and the SRI? You might break payment for $polling_interval if the script is incompatible with Stripe's server, so perhaps you could have retry logic there, to bridge $polling_interval more smoothly. You could also manually review the new Stripe code this way, by polling only by hand or by not automatically updating the cache and SRI.
mmarx 10y ago
> If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag. Then how do you verify the integrity the integrity for the tag?

LukeShu 10y ago

You, as the web developer, want to start using subresource-integrity. Stripe, as a depended-upon 3rd party, has not yet bought in to subresource-integrity hype-train. Stripe rolls out a fix for a security issue or other bug in their JS. This breaks your subresource-integrity check. The didn't want you to stop accepting payments, they wanted to fix a vuln. That hampers the usefulness of using subresource-integrity on 3rd-party resources today (which is what yeldarb suggested). Perhaps in the future the 3rd party would provide a script that emits the URL/SRI, but that isn't today.

jffry 10y ago
the 3rd party would provide a script that emits the URL/SRI And we're back to square one - we can't trust _that_ script to not get pwned
- cryptarch 10y ago
  Not really, isn't packaging and securely distributing PHP/Node.js libraries a solved problem?
  - johncolanduoni 10y ago
    If you're not updating the PHP/Node.js library, and you're not updating any data you give it, where does it get the information it needs to update the URL/SRI tag? And if you are doing any of those things when Stripe pushes an update, how is it any different that having to update the URL/SRI tag?
cryptarch 10y ago
Ok, so how about caching the Stripe script and serving it yourself, then polling for new versions and then updating the cache and the SRI? You might break payment for $polling_interval if the script is incompatible with Stripe's server, so perhaps you could have retry logic there, to bridge $polling_interval more smoothly. You could also manually review the new Stripe code this way, by polling only by hand or by not automatically updating the cache and SRI.

mmarx 10y ago

> If they want you to stay up-to-date, they'll provide a piece of PHP/Node that emits the latest URL/SRI tag. Then how do you verify the integrity the integrity for the tag?