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

Browser Sync vulnerability ... (again) #215

Open
snuggs opened this issue Jan 5, 2021 · 6 comments · May be fixed by #216
Open

Browser Sync vulnerability ... (again) #215

snuggs opened this issue Jan 5, 2021 · 6 comments · May be fixed by #216
Assignees

Comments

@snuggs snuggs self-assigned this Jan 5, 2021
@snuggs
Copy link
Member Author

snuggs commented Jan 5, 2021

@brandondees a long term dream would be to have ZERO dependencies. #UseThePlatform.
However...to develop it into that state is taking some dependencies. Luckily the major "vulnerability issues" we have are all devDependencies for the most part. All the appropriate issue trackesrs are up above. I may throw a patch together and submit a PR since this was already taken care of before in BrowserSync/browser-sync#1697 .

/cc @JoshuaBehrens

tenor

@snuggs snuggs linked a pull request Jan 5, 2021 that will close this issue
2 tasks
@brandondees
Copy link
Collaborator

yeah usually dev dependencies are less critical to patch than bits that go into prod, but supply chain attacks and all that are still a factor. I wonder if there's a good pattern for separating the dev kit from the library/package itself, as in separate repos or whatever. That would enable a better signal to noise ratio on tracking changes to snuggsi itself and let the dev tooling be a bit more free to do whatever whenever without bothering downstream users.

@snuggs
Copy link
Member Author

snuggs commented Jan 5, 2021

@brandondees yeah that's the irony of this project.

99% of any of these headaches don't exist in user land if they use:

<script src=//unpkg.com/snuggsi></script>

But people love to install stuff tho. The jQuery folk will get it. That's one thing jQuery got right. Installation process.

Would love a installation like

<script src=//snuggsi.com></script>

The W3C & WHATWG platform spec is updated now to strip the text/html Accept mimetype for <script> and <link rel=stylesheet> (and <img src> for that matter). A regular browser visit appends text/html. But that would take a bit of content negotiation and CDN caching. Maybe a nice to have in the 2022.x.x release ;-)

@brandondees
Copy link
Collaborator

@snuggs Yeah I understand. The big downside of linking to a source like unpkg is A: it could have a security breach and the code changes out from under you, B: their downtime is now your downtime too. There's some interesting blockchain / dweb tech coming along that may eventually make those problems a thing of the past, but till then, if we want content integrity, security, and reliability, we have to self-host our frontend.

I'm not arguing that it shouldn't be made available in that form, just that it's totally reasonable/normal for production apps to require their own full copy. The built library doesn't need to ship from NPM with all the dev tools, however. It could be just the one combined source file on npm, and the development setup for it could be installed separately/optionally.

@snuggs
Copy link
Member Author

snuggs commented Jan 5, 2021

@brandondees makes total sense. Hence this type of rigamarole. I knew from day 1 that unpkg not a final solution. But since didn't actually own snuggsi.com at the time had to put is somewhere easily accessible. But figured if good enough for React. Also FWIW jQuery still recommends installation from CDN (while giving instructions for internally).

Regarding code change...is this what the integrity attribute is for on <script>? I knew it's there but never had a use case for it. >>> https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

@brandondees
Copy link
Collaborator

yep, subresource integrity means the browser will check to make sure the content received matches what the parent page expected before trusting it. best practice, but it also requires that the content from a given asset url never changes unexpectedly (you'd have to have version-specific cdn url to link to before you could safely add the attribute)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants