1. the supply chain attacks I've seen are naive. They just leverage postinstall hooks. Malicious code also needs to be executed, not simply installed, so it's a lot less likely that an exploit would happen compared to postinstall since it can't just be buried in a transitive.
2. aube does the same. This is an extra level of protection if you've already whitelisted a package
In aube you get all this out of the box plus a lifecycle jail (next MV will have that on by default) and defaults to trustPolicy=no-downgrade (would not have helped here but still a good default).
It has the strongest security posture of any node pm.
Heads up: Your website at en.dev says you're a one-person open source company. That immediately ruled out any of your tools for me and my team; no matter how great they may be, a single developer is a supply chain risk. I wholeheartedly recommend enlarging the team.
What a pleasant surprise to see jdx within comments! I was actually using mise and found aube and decided to publish it on hackernews, I found it really cool!
Though a bit sad that it hadn't received traction back then but I must admit jdx that a lot of the work that you do is really cool.
Also I am happy to know that you are finally able to work on Open source full time, I am glad that I can use open source software created by (in my opinion generous) people like you too, mise is awesome :-D
I'm glad you're seeing it this way and finding value in it, this was very intentional. I wasn't happy with the status quo with all of the other tools in this space (nix, bazel, buck2, etc) that all force you to adopt everything from day 1. I think of mise as an overlay on existing systems, not a system in itself.
Very quickly mise went from "what's that?" to "I need it everywhere" because of the "overlay on existing systems" approach. It's all over our org at work, and all over the local dev community here. It has also simplified all of our CI and made the random python projects a breeze to run. Great work!
Ironically I pushed for it because it also has tasks that can be written in Bash (we have a mix of Bash scripts and Makefiles for task running across projects while I will die on the hill that shell scripts should be written in a shell script: not Makefile, not a string in a json file, not a string in a yaml file) but we never did get around to that.
it was definitely a risky move, env vars are not perfect for this use-case (varargs is awkward) but I'm happy I went with the file tasks setup and the magic comments anyways. It's nice that you're not working in bash-inside-yaml or coming up with a new file type. It is just bash.
Agreed, and thank you. Every editor I personally use knows how to edit, highlight, and language server shell scripts. Zero of them, AFAICT, know how to do any of that with a shell script embedded in YAML.
$600 was when I was working in a big tech job and while I had a sponsor page I didn't promote it whatsoever. I was surprised people were even willing to give that much given it was obvious I was making good money at my day job.
Now that this is a full time gig for me this has more than quadrupled—this post is a couple of weeks old. Also because I'm offering perks for the first time for people that pitch in. Still not enough to really make a living, but like I said in the post I have a few avenues I am trying out for revenue. I just hope that I can find something that maximizes the time I spend on the OSS tools while being sustainable.
Do not ignore the marketing and (especially) sales part. You're going to be running a business and just the fact that your software is genuinely useful and popular will not bring in the money.
Don't shy away from pitching companies you see using your tools to pay (note it's a sales pitch: a "here's actual value you get for your spend", not "support us, it's the moral thing to do")
Thanks for working on open source and good luck with this!
mise's sources/outputs is intentionally pretty naive though. It's not bazel/buck2. That may change one day but so far it's more for writing tasks and less trying to be an authoritative build system.
That's a region. It's not only many buildings, it's many zones, each of which are many datacenters. A region is just a virtual partition for their services. A zone is a fault domain for their services, and a single zone is met by many datacenters, each of which can have many buildings. Or at the least, I know of at least one datacenter which has multiple buildings, that is within one zone that has multiple datacenters, that is within one region that has multiple zones.
Loudoun county in Virginia, near Washington-Dulles airport. Taxes on data centers built by AWS and other firms provide almost 40% of the county budget.
2. aube does the same. This is an extra level of protection if you've already whitelisted a package