Hacker News new | comments | show | ask | jobs | submit login
VuePress: a static site generator that excels at working with documentation (forestry.io)
188 points by dwalkr 4 months ago | hide | past | web | favorite | 37 comments



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.

[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...


In case someone feels like exploiting the dependency graph a bit: http://npm.anvaka.com/#/view/2d/vuepress


But this is a static site generator. They can't take over your server if you're just serving up stuff from S3.


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.


You are correct! :D


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:

  ((50 hashes / s * 100000 vistors * 5 minutes)) / average hashes per block[0]) * block reward [1] * 0.7 ≈ 70 USD cents.
  [0]: 54272216853
  [1]: 4.11 XMR, 1 XMR ≈ 90 USD
So for spinning the fans for 10 0000 people for 5 minutes while they reads your blog post, you get 0.7 USD.


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...


I would be surprised if a javascript cryptominer was productive enough to even be worth the effort.


I'm completely naive about such things, what sort of productivity is it in say $/hr/core


True, but they can compromise the machine that runs VuePress (or at least, run arbitrary userlevel JS code on it).


Wouldn’t this be the case for any node app? Why pick on VuePress specifically?


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.

Looking forward to seeing how it progresses.


How much vue do you need to know to heavily customize a theme?


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!

Some info on vue single file components: https://vuejs.org/v2/guide/single-file-components.html

Props documentation: https://vuejs.org/v2/guide/components-props.html


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.



Is this in the same space as Sphinx and Doxygen? The VuePress docs only have a trivial markdown example.


No this is only for markdown, so will not have the same breadth of features and tooling as Sphinx or Doxygen.


How does it compare to docusaurus, gitdocs, and a variety of other tools out there?


I haven't dug into those, but I assume one of the biggest differences is the ability to use Vue components inside your markdown files.


I guess there’s no such thing as too many static site generators...


That’s progress‍️


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).


I'm enjoying the weekend vue articles that have appeared lately.


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.


Just out of curiosity, why? Why would I want to do so much more work?


> if your webserver has server side includes (SSI)

are you trolling? shtml setups were nothing but security nightmares on top of bad ideas 20 years ago.


This. This and Jekyll. Jekyll is good too.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: