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.

Visual voicemail is when the dialer app on your phone can show the list of voicemails similar to how you would see your email inbox. You can directly play the voicemail messages and depending on the device/carrier, there might also be a text transcription of the audio.

Many carriers implement this via "silent SMS" + IMAP (the same IMAP as for emails). The device will send an activation or status message to the carrier's visual voicemail number and the carrier will respond with an SMS containing the IMAP credentials.

The version of this I'm familiar with is T-Mobile's old CVVM protocol. During initial setup, the device will send a text message containing "Activate:dt=6" to the number 122 and T-Mobile will reply with (in decoded form):

    pw_len=4-9
    vs_len=10
    u=<IMAP username>
    pw=IMAP password>
    rc=0
    st=R
    ipt=148
    srv=e7.vvm.mstore.msg.t-mobile.com
    lang=1|2|3|4
    g_len=180

If visual voicemail is already enabled, then sending the "Status:dt=6" SMS to 122 will also result in the same reply. Putting the credentials in an IMAP client will work and it doesn't have to go over the phone's cellular connection. You can even use curl:

    curl -v imaps://<USERNAME>:<PASSWORD>@e7.vvm.mstore.msg.t-mobile.com/

T-Mobile has deprecated this protocol though. New activation messages will fail with a blocked status:

    rc=0
    st=B
    srv=vvm.mstore.msg.t-mobile.com

T-Mobile replaced this CVVM protocol with two HTTP based protocols: "mstore" (used by OEMs like in the dialer app on Google Pixels and OnePlus devices) and "cpaas" (used by T-Mobile's first party visual voicemail app). I've been working on an open source client for mstore for use with open source Android OS's, like GrapheneOS.

In case anyone is interested, the vvmd wiki (visual voicemail implementation for Linux phones) has information on how several carriers implement VVM: https://gitlab.com/kop316/vvmplayer/-/wikis/Visual-Voicemail.... AT&T's is especially nasty.

One area where the distinction between PIDs and TGIDs matters a whole lot is for using ptrace on processes that call execve() (eg. for something like `strace -f`). In can be pretty tough to ensure that tracer's internal state matches reality: https://man.archlinux.org/man/ptrace.2#execve(2)_under_ptrac...

Any chance you happen to know the latest code to get into the hidden menu on the EV6? Used to be 19190307, though it was changed in the 231215 infotainment firmware update.

I don't, sorry. I've held off on installing updates for exactly this reason. They seem to vary based on current year as well as firmware version - you might try rolling your system clock back to 2023 before trying again.

No worries! Thanks for the hint about the date -- I didn't know that was a function in the equation. Changing the date back to 2023 actually allowed the 19190301 code (had a typo in my original post) to work, though it seems they've removed the telematics switch unfortunately. Some day, I'll have to figure out how to disconnect the antenna.

That's disappointing - thanks for the info. I guess I'll continue to avoid infotainment updates. I can confirm that the telematics toggle is present (and functional) in the variant coding submenu on version 221025. I wonder what dealers are doing in Massachusetts now.

I think the antenna connectors are accessible if you remove the lower center console trim, then reach up behind the screen. But I haven't tried this, since the software toggle works for me.

It looks like it is packaged in the official Fedora repos: https://packages.fedoraproject.org/pkgs/foot/foot/

> but explicitly tells users not to do that

They set the vbmeta header flags field to 0x3, which effectively turns off all of AVB (Android Verified Boot). I'm guessing they do this because they want to allow the system partition to be writable (eg. for folks who flash additional things on top of LineageOS).

With unmodified LineageOS, if you configured the bootloader to use LineageOS' public key and relocked it, there would be no security benefit. To enable AVB's signature checks, the flags field needs to be set to 0, which requires re-signing LineageOS with your own key.