Give an example of loading xtermjs from a cdn in the docs example
epicfaace opened this issue · 6 comments
This would make it easier for people to get started.
Isn't it just a matter of switching out these local files for CDN ones?
<link rel="stylesheet" href="node_modules/xterm/dist/xterm.css" />
<script src="node_modules/xterm/dist/xterm.js"></script>
I don't think we want to encourage the use of CDNs for this as they may lag behind npm and it adds an extra round trip to the CDN.
CDN usage should be discouraged for security reasons as well, unless you can ensure its data integrity by an secured upload (with auth!) and later fetch (chain of trust). Open CDNs typically will not guarantee any of this. So a clear down vote from my side.
@Tyriar Imho this can be closed as wont fix.
Sorry for necroposting, but just wanted to revisit this issue. CDN's are pretty much the standard for loading libraries now, and jsDelivr is a very popular npm cdn (like unpkg) that's quite fast and supports SRI. So a simple swap out to <script src="https://cdn.jsdelivr.net/npm/xterm@5.0.0/lib/xterm.js" integrity="sha384-/XCg80+L4V8GHwr3ghm7ukvciSG3P/9AA5FnCAPS2SDmmaaxAkhuzh5SW/BuPFdo" crossorigin="anonymous"></script> etc would be more efficient and beginner friendly (as you can just paste and go) than hosting files on your local server. Keep in mind this is just my opinion, but I would recommend considering it. Not to mention it's the official CDN of Bootstrap and other popular libraries.
CDN's are pretty much the standard for loading libraries now
Yes, and it already was for quite some time now.
jsDelivr is a very popular npm cdn (like unpkg)
Being popular does not automatically mean secure. Popularity can be misguided/framed or follows different rules.
that's quite fast and supports SRI
Thats good and actually a reason to use it in your project, if you checked/audited the delivered content secured by that hash. Who does this? Almost none. Is that beginner friendly? Def not.
Not to mention it's the official CDN of Bootstrap and other popular libraries.
Since you still mentioned it - thats soft trust, which does not mean anything, unless coupled with cryptographic testable "hard trust". SRI can provide that, but it still needs you to check the delivered content, as the hash token also comes from the CDN in the first place.
The issue with putting this into xterm.js docs is simple - first it creates the need to maintain and revisit those CDN entries and their SRI integrity for every single release. None of us prolly has the time/will to do that. Therefore you'd have to check the integrity of content to SRI yourself. Without that check, CDN resources have to be seen as untrusted.
Secondly xterm.js is a quite feature complete terminal component for a very delicate/sensitive subject, which makes it a much more likely target for code injections, than a "building-blocks framework". A successful injection in xterm.js delivered over some 3rd party CDN can easily break into thousands of machines later on, simply for the fact that a terminal component will hold connections to many more computers (mostly servers). Thats a big difference to other JS libs, where typically only the browser's machine or a single webapp with its user data might be affected (or to put it dfferently - the needed specific tailoring of an attack is much lower with xterm.js). Note that many cluster orchestration apps use xterm.js as terminal component, thats like exposing a significant amount of cluster machines worldwide to such a threat.
So nope, I dont think your convenience argument is true here, unless ppl also want to skip the needed integrity check. But w'o that, an open CDN can deliver whatever it wants to.
I see your point now.