Skypack and (lack of) subresource integrity

[aral]

I wrote a short blog post at the end of last year titled Skypack: Backdoor as a Service? in which I voice my concerns about the lack of subresource integrity (SRI) in Skypack.

(The title stems not from my belief that Skypack is being built as a backdoor but that it can be used as a backdoor.)

Now, given that (a) I love Snowpack and (b) Skypack is how the folks who make Snowpack are planning to put food on the table and continue developing Snowpack (as well as the excellent esinstall, etc.), I’d really like to see them succeed. (It also helps to see that they don’t seem to be funded by venture capital and that, hopefully, Snowpack won’t be Google Snowpack in a few years’ time.)

That said, without SRI, you cannot be sure what code you’re actually serving the people who use your apps. The more successful Skypack becomes, the more of a target it will be for those who might want you to “just add these few lines to code to these specific requests and if you refuse or tell anyone about this secret order, there’s a prison sentence with your name written on it.”

So I feel it’s probably best to debate this sooner rather than later as well as explore options for how SRI can be implemented in Skypack.

Thoughts?

[ericcholis]

In some cases this also might also cause a PCI Compliance Script Src Integrity Check to fail.

[ghost]

Any updates on this? I was only using Snowpack in one project that I just moved to rollup as a result of this.