It looks like all the old files are still hosted on the server. You can just replace the version number in the download links with one of the tags from https://git.zx2c4.com/wireguard-windows.

This article isn't about the installation of regular apps. The "sideloading" it's referring to is the option to use the "adb sideload <OTA file>" command when booted into recovery mode to install OS updates. The functionality being removed is being able to install a proper OEM-signed OS update from a local file.

It's probably worth pointing out that the online process is one time and it installs a token that permanently lets the setting be toggled offline afterwards. This persists across factory resets and flashing any OS.

I wrote more details about it works under the hood here: https://news.ycombinator.com/item?id=35856171

Epic level comment! Very interesting to read about in this technical detail, thanks for taking the time to write it up.

NFC payments via Google Wallet running on my Pixel Watch 3 connected to a phone running GrapheneOS works just fine. I use this regularly. (It doesn't require Google Wallet to be installed on the phone.)

At least one of my cards required Google Play Services to have the location permission when initially adding the card though.

I wrote https://github.com/chenxiaolong/MSD for exactly that. It's a small wrapper around the Linux kernel's mass storage emulation support (CONFIG_USB_CONFIGFS_MASS_STORAGE). It can emulate a read-only optical drive, a readable disk, or a writable disk.

It is compatible with both older devices that configure USB via init scripts and newer devices that use Android's USB gadget HAL, but it does require Android 11+.

Looks cool, bookmarking for when I finally have a rooted phone again

For me, I begrudgingly use GitHub for my personal projects because GitHub Actions is free. If I move elsewhere, I'll have to stop providing precompiled binaries for OS's that I can't cross-compile for from Linux (eg. macOS).

I would not provide precompiled binaries for other systems if I could not even test it properly (nor know all of the details for programming for those other systems), whether or not it uses GitHub Actions.

If you do use GitHub Actions for compiling, then it might be better for the actual implementation of compiling to be in a separate file (which can also be used outside of GitHub) and the GitHub Actions file will only specify the conditions to trigger that separate file.

(I do use GitHub Actions, but only to automatically assign issues to myself (which is not something that is necessary in order to work the software that is being made by your repository). If it is moved to (or copied or mirrored to) something else that cannot use GitHub Actions files, it might have another way to auto-assign issues or make it unnecessary to do s.)

Yeah, my GitHub Actions workflows don't do much more than `cargo build --release && cargo test --release`. I don't use any of the fancy features that would lock me in.

It's really just running the tests on Mac that I rely on it for. For Windows and Android, I can (and regularly do) use wine and qemu-user-static to run the tests on Linux. My project (a computationally heavy CLI tool) is simple though. It doesn't need much from the OS besides memory allocation, thread spawning, and opening a user-specified file.

SourceHut builds are not free, but cheap if you’re an “amateur hacker” ($2/month).

If this is enforced via Play Protect, then the whole mechanism can likely be disabled with:

    adb shell settings put global package_verifier_user_consent -1

This does not require root access and prevents Android from invoking Play Protect in the first place. (This is what AOSP's own test suite does, along with other test suites in eg. Unreal Engine, etc.)

I personally won't be doing this verification for my open-source apps. I have no interest in any kind of business relationship with anyone just to publish an .apk. If that limits those who can install it to people who disable Play Protect globally, then oh well.

How long until Google decides to lock it down because "scammers" can "abuse" it?

Would be a real shame if this also nuked your safetynet trust score if they realize too many people are using this escape hatch...

I really hope this ends up being possible! Play Protect seems to jump up every so often and try to scare me into turning it on. Very annoying. I've wanted to disable Play Protect permanently, but never did the query to learn how, so thank you.

What does this break?

There shouldn't be any side effects other than rendering Play Protect inert. No other AOSP component relies on this setting.

There could of course be side effects in the future when this restriction is rolled out, as in your device's Play Integrity status could be affected and your banking app/phone wallet might not let you perform app-based payments from that device.

Some bank apps and payment processor already check if you have developer mode on and refuses to run.

Oh so that's why my bank app said it thought my old device was rooted when it wasn't...

I kinda feel like they'll make sure any workaround for this will ensure you can't use banking apps, Google Pay, etc.

I really hope this is done via Play Protect. You can also disable it temporarily in Google Play and install whatever you want.

Ironic that Google's supposed concern for avoiding malware will cause people to turn off their malware scanner.

There's also the related "Verify apps over USB" setting which is even exposed in the developer mode settings GUI.

I'm curious how the check is implemented in Google Play Services. If it's based on the package manager's initiatingPackageName field, it should be trivial to bypass on rooted devices (or unrooted custom ROMs).

This should work with any arbitrary filename:

    latest=$(printf '%s\0' <glob> | sort -zrV | head -zn1)

or with long args:

    latest=$(printf '%s\0' <glob> | sort --zero-terminated --reverse --version-sort | head --zero-terminated --lines 1

What unix is this on? Neither the mac nor gnu manpages have a -z or --zero-terminated option for head.

Debian's head (from GNU coreutils) does: https://manpages.debian.org/bookworm/coreutils/head.1.en.htm...

Yay! Glad to see zero termination flags in more places.

EDIT: The linux manpages I read were from die.net, which it looks like were from 2010, guess I'll have to avoid them in the future. I checked FreeBSD, OpenBSD, and Mac man page to make sure, and unfortunately none of them support the -z flag yet.

I'd recommend giving openconnect a try. It was originally meant for Cisco VPNs, but has also supported GlobalProtect for a while now. It integrates with the NetworkManager GUI if you use that.

It worked flawlessly with the GlobalProtect VPN we had to use at my last job. A few folks ended up switching to using openconnect on Mac too. The official client seems to be quite bad on both platforms.