VuePress pulls in nearly a thousand transitive dependencies. In light of recent security incidents[0][1] and the relative ubiquity of poor security practices[2] in the npm ecosystem, that seems like an unacceptably large attack surface.
I don't want to have to worry about somebody injecting malicious code or cryptocurrency miners into my website by compromising a little-watched transitive dependency in my static site generator.
They can't take over your server but they can inject a script tag with a cryptominer for all of your users to run. It's not the end of the world because you're just out a few dollars in electricity but it would be embarrassing.
Your reputation will be out of the window if you ran a crypto miner without notice and even if you get rid of it saying it was "hacked", people will hardly believe it.
If they can inject something like that in the output, they can also do something funky on your dev machine. Which means I shouldn’t be installing any npm package.
I think what he was trying to say was that if you knew for a fact yesterday that your static site didn't have malicious code on it, then you know it for a fact today, assuming you didn't rebuild the site in the interim. You can't say the same for dependencies on, say, a web server, since the web server may have rebooted and did an install or whatever overnight.
Stupid question, does anyone do this on purpose? (i.e. With the consent of the client side). In a way it seems like a good way to make income for content (say a blog post) rather than all the ad profiling nonsense that goes on now.
I noticed that the nazi/terror/nationalistic organisation Nordic Resistance Movement uses https://coinhive.com, since they probably can't use ads. Coinhive apparently takes a 30% cut, and on my 2014 15" MBP I get a hashrate of around 50 / second. Some napkin math:
Thanks! That is strangely fascinating. So I am guessing your average laptop runs at about 20 watts so 20 x 10000 x 5/60 = 16.67kwh
So depending on where you live you might pay 0.3$/kwh so 70 cents for about 5 dollars worth of electricity. So only makes sense if you can keep a lot of people on your page for a very long time...
The OP's comment was specifically with respect to the large number of dependencies, which can increase the "surface area" for this type of attack to happen. And, of course, we're talking about VuePress because this is a thread about VuePress. Similar complains are raised for many other Node libraries, so rest assured that VuePress is not alone in that regard.
I'm using VuePress to auto-generate a static, non-interactive site from a set of Vue components and some input data that's updated daily. For me it serves the purpose of a batteries-included way to render Vue to HTML, without messing with SSR libraries, webpack, or Babel configurations myself. I find Vue's composability a much tidier way of doing things than the file-inclusion-based setups typical of systems designed for static site generation.
That said, I've had to write a Python script to do some pre- and post-processing on the VuePress files. Generating a single README.md whose front matter contains my input JSON; stripping out script tags, as there's currently no way to prevent VuePress from generating them in the first place; minifying the HTML; injecting some extra tags; moving files around. There's a bit of a mismatch here between my use case and VuePress's primary role as a documentation generator.
I'd love to be able to call into VuePress as a library, instead of running it as a separate executable, and, for example, pass it my input data directly instead of writing it out to a temporary file for it to read back in. This is something I plan to toy with implementing once I get some free time again (currently bogged down with preparing to give a talk).
I said it before and I'll say it again: VuePress is impressively easy to get started with. Running `vuepress dev` in an empty directory is all you need to get started.
Also, I really love the decision to make `README.md` files act as the `index.html` files. This has the benefit of making your docs easy to read from your projects Github repo.
Not much at all, all .vue files in the components directory gets registered globally, so if you create a Navbar.vue file, you can use <Navbar /> anywhere in your theme. Easiest templating system I've ever used. If you learn a bit of how passing props work, you're golden!
Do you know if registered globally = pre-loaded or are they only loaded as encountered / needed? Just wondering if you have to be careful how many components you put in that directory. Not for purpose of templates of course, but for the unique Vue components that you can put in page content.
vuepress also generates SEO friendly docs, eg when compared to docsify, but on the flip side docsify has full text search, while the default vuepress theme only searches headers (but since its seo ready most third party search will work ef algolia, google).
All these static site "generators" seem pretty silly. If you're going to make a static site then just make a few template pages by hand in html then copy and edit them to fill with whatever content.
It works even better if your webserver has server side includes (SSI) turned on. Then you can make header/footer/sidebar/etc templates and just insert them with a line in the page templates.
Because one of the things that keeps people engaged in maintaining a website is being able to fiddle with it, and the cost of fiddling with the layout of a truly static site is a lot higher than intuition would suggest.
Because you have to take the odds of making a stupefying, drop-everything mistake on any one page and take it to the nth power. That’s O(c^n). That’s an order of complexity that I haven’t even bothered contemplating in so long that I had to look up the notation.
If that works for you, great! But just because you’re not the target audience doesn’t mean it’s silly.
I just have a simple site, but I know I don’t want to write my content in HTML. I just want to write it in Markdown and be on my way. Having yaml frontmatter for metadata and markdown for the body let’s me keep my content separate from my templates.
On the other end of the spectrum are larger organizations like Borisfx.com building large multimedia static sites. Or hell, look at the Forestry.io website and then tell me a few simple templates made by hand would suffice.
> It works even better if your webserver has server side includes (SSI) turned on.
If you're trolling, well done. If not, then you're not understanding the concept of the "static" in "static site generators". SSI are inherently dynamic. They run each time the page is viewed (yes, you can use a cache, but the page is still loaded dynamically by the cache server).
> Then you can make header/footer/sidebar/etc templates and just insert them with a line in the page templates.
This is precisely what any static site generator will do, since they all feature template engines.
I don't want to have to worry about somebody injecting malicious code or cryptocurrency miners into my website by compromising a little-watched transitive dependency in my static site generator.
[0] https://blog.npmjs.org/post/175824896885/incident-report-npm... [1] https://blog.npmjs.org/post/173526807575/reported-malicious-... [2] https://www.bleepingcomputer.com/news/security/52-percent-of...