I'm with you, once an RCE is known, it's usually just a matter of time before it gets script-kiddied and easy to run. Don't put yourself through the pain, just upgrade nginx.

I just finished upgrading a weird embedded box that required compiling a static nginx binary and moving it over. It's more annoying than apt update;apt upgrade or whatever your OS distribution needs, but it's still not that hard.

I love that under disclosures "Plugin might make requests to 1 external domain", if you click on it, it shows the domain: "github.com". great work!

Example from https://community.obsidian.md/plugins/zotlit

Which is brilliant...... Especially if we remember how easy is to host a (malicious) script on github :)

But yes, great work indeed. It finally makes me want to move over to Obsidian.

Yes, for sure. More context is a bonus. like clicking a link takes you to the code that calls out to github.com. Or for some sites like github, instead of just showing the domain, it shows the repo in question or it's a gist or something it says whoa nelly! and marks it questionable, etc.

But already they have a great start here.

I'd say that may be as harmful as it is helpful. Amateur users may have heard of Github and would therefore trust that domain, but you can upload malware to Github just as easily as anything else.

Yes, a bonus would be more context, but already this can show stuff you know you don't want. If you see doubleclick.net for instance you know it will be ad-ridden disasters, or whatever.

With just the domain, you can search the code repo and see exactly where it's calling github.com to see what exactly it's trying to reach on github. So it gives you an easy place to track down what's going on. An extra bonus would be clicking on github.com and it would link to the line in the file that makes the github.com call.

Clearly they aren't done covering all the bases, but I think this is a great start! Way more than I expected to be honest.

Ads / telemetry are disallowed completely, as per our developer policies. So plugins that have those domains in the code will not be available from the site / app.

<3

Clearly you disagree with the debian stable perspective. That's fine, it's not for everyone. You can just run debian unstable or debian testing, depending on where exactly you draw the line.

If you want the rolling release like distro, just run debian unstable. That's what you get. It's on par with all the other constantly updated distros out there. Or just run one of those.

Also, Debian stable has a lifetime a lot longer than 2 years, see https://www.debian.org/releases/. Some of us need distros like stable, because we are in giant orgs that are overworked and have long release cycles. Our users want stuff to "just work" and stable promises if X worked at release, it will keep working until we stop support. You don't add new features to a stable release.

From a personal perspective: Debian Stable is for your grandparents or young children. You install Stable, turn on auto-update and every 5-ish years you spend a day upgrading them to the next stable release. Then you spend a week or two helping them through all the new changes and then you have minimal support calls from them for 5-ish years. If you handed them a rolling release or Debian unstable, you'd have constant support calls.

...or just leave grandparents on the previous version of Stable until they get a new computer. Honestly not a huge fan of upgrading software at all, if I'm the one supporting the machines.

Just depends on if that's something grandparents/kids can/want to afford.

Personally, If the hardware is working great, seems like a waste of money replacing it, just to upgrade software. Especially with Debian oldstable -> Debian stable where it's usually quite easy and painless.

You forgot to use https://www.random.org/ as your source of randomness :)

I just use send(formerly FF send) and share a URL via chat or whatever: https://github.com/timvisee/send

With a CLI tool as well: https://github.com/timvisee/ffsend

Also https://wormhole.app/, but feross is busy witch Socket and the myriad of NPM supply chain attacks nowadays

Thanks for the mention!

See the documentation: https://www.postgresql.org/docs/current/backup.html

all of these various 3rd party backup tools use these things. Mostly it's QOL stuff that you get from a 3rd party tool. We use barman, very happily: https://pgbarman.org/

Hopefully barman has some longevity being under EDB assuming some hyperscaler doesn't gobble them up

Barman has been around since 2011, released under the GPL. If it does get ruined by someone, I'll replace it in my stack or fork it for maintenance myself. I'm not very worried though.

EDB has been in private equity(PE) hands since 2019 with out managing to ruin it so far. The ownership in PE hands seems to be pretty stable, so it doesn't look like the typical pump/dump mess you often see from crappy PE money.

I dunno how they compare, but we have been using barman for a long time very happily. We test our backups every night, by restoring from barman into a _nightly DB. which we then give out to users as a training/testing spot, so that we know when it breaks. It hasn't broken in many years now. <3

> It provides everything you need or want or don't know you want except a decent text editor.

That's what evil is for :P

I think you had to have installed the CLI during that time-frame, then ran the brand new installed CLI to be vulnerable.

Assuming you had it already installed, you would be safe.

I checked a machine this morning and it had updated itself at Apr 23 1715G

I've purged the snap. Really should purge snapd completely.