Appinages are fine. Needing to apply changes as patchsets rather than just building normally sucks. Especially in deb and rpm distros.

Fortunately, it looks like that was done already with Swanstation, which also has many more contributors.

Yes. The license doesn’t technically appear to forbid forking, just sharing the fork.

I have some issues with flatpak, myself, but that mainly stems from having trouble finding documentation to clear up how to properly use extensions and non-standard dependencies that are easy to do with OCI images.

Ex. I had a really hard time trying to get Vega Strike built as a flatpak.

Yeah… That’s pretty terrible. I was meaning packaging patchsets for other distros. Hopefully the GPL-preserving fork is better.

Yeah… But then it sucks for anyone not running Arch (btw) or derivative distros. I really don’t have a dog in this merge conflict but really would feel bad for any packager maintainers.

Would have to go back to before the license change in September 2024. The current license basically forbids forks, from my reading.

Yeah. That’s a pretty shitty license to move to for endusers and others. Disallowing derivatives, etc. is within their rights but, really a dick move but, considering this commit message, not surprising.

As I mentioned in other comments, I am a noob when it comes to web-sec; please forgive what may be dumb questions.

There’s nothing to forgive. Asking questions and being curious is how you learn this stuff.

Is it really just permission rights “over-exposure” issue?

From what I’ve read, it’s more fundamental than that. It’s a basic architecture issue. The datastore was publicly accessible, which it should never be. If they had it setup according to best practices, with an API to proxy access and auth, the datastore’s permissions would be of minimal consequence, unless their network was compromised (still best practice to secure it and approach with a zero-trust mindset).

Or does one need to also encrypt and then decrypt the data itself that must be sent to a database?

Generally, cloud datastores handle encryption/decryption transparently, as long as the account accessing data has authorization to use the key. They probably also didn’t have encryption setup.

Also, if you have time, recommend any links to web/cloud/SaaS security best practices “for dummies”?

Here are some more resources:

• https://cheatsheetseries.owasp.org/cheatsheets/Secure_Cloud_Architecture_Cheat_Sheet.html
• https://www.oreilly.com/library/view/security-architecture-for/9781098157760/
• https://www.oreilly.com/library/view/cloud-computing-security/9780429619649/
• Check Humble Bundle

I’d argue that it should not even be done in Dev. Dev, staging/testing, and prod environments should all be as close to one another as possible, especially for infra like datastores.

I agree. Some sort of solution is necessary but this probably isn’t it.

On one hand, yes. On the other, women have, based upon crime statistics, legitimate reasons to avoid putting themselves in a situation where they may be assaulted or murdered for reporting problematic and/or worrisome behavior.

Yup. It sounds like they were following security worst practices.

Yeah. You also landed on a correct thought process for security. Cloud providers will let you make datastores public but that’s like handing over a revolver with an unknown number of live chambers and saying “Have fun playing Russian roulette! I hope you win.” Making any datastore public facing, without an API abstraction to control authN and authZ is not just a bad practice, it’s a stupid practice.

You’ve got the right ideas. Noone should ever be storing any password in plaintext. It should always be hashed and only the hash stored. That’s like WEBDEV99 (remedial course, not even 101).

Really. Despite your stated “noobishness”, you basically landed in the territory of best practices right of the bat.

If you’re looking for a good source of best practices, the CIS benchmarks are great. https://www.cisecurity.org/

My suspicion would be that belt printers were not in the scope when writing it. Probably a good idea to open an issue in GitHub so that they can fix it.

Who’s dying on what hill now?

That would be wonderful. The current way that the world has been “working” for a good while now makes me think it unlikely, unfortunately. The vast majority of technological innovation in the last half-century has been used to extract wealth and replace options available to the non-ultra-wealthy with inferior substitutes that are cheaper to make, often for the same effective cost.

Life long windows user. I switched to Arch

Fuck. That’s like going straight from English breakfast tea to hash oil.

I’ve been using Linux almost exclusively both in my personal and professional life for a decade and a half. I only installed Arch a month or two ago.

I’m more into (neo)vim but that is beautiful.