cdesai

Google is usually pretty quick to upload source code to AOSP after release on Pixel.

Android 16 has been highly unusual though, with the only source code release done 3 months ago in June, when it was initially released.

https://android.googlesource.com/platform/frameworks/base/+r... - only two "16.0.0" hits here, both from June 10.

I remember fondly reading that (and about his work in general), which is why when I saw the video thumbnail I immediately had a feeling "wait no it can't be".

Thanks for the link!

How can they do that with HTTPS though?

HTTP sure they can happily MITM and redirect, but with HTTPS you need a valid cert.

The 24h timeline sounds very tight. I wonder how much they'll be able to stick to it.

Full title: ‘Everything LTS’ – Canonical will build distroless Docker images to customer spec that include upstream components not packaged in Ubuntu, and fix critical CVEs within 24 hours, supported on RHEL, Ubuntu, VMware or public cloud K8s for 12+ years.

It's a fork of the chromium update engine.

https://android.googlesource.com/platform/system/update_engi...

Many Android specific changes though.

Geez, it's one message, there was more after it, when no mods were around. I can't speak on behalf of Nick of course.

I woke up, saw it, and banned those people. We don't allow people to do this for any project, ever. What else can even be done, there's thousands of people on the channel, and moderation is hard and time consuming.

People on the internet say things, you can't keep attributing it to us always.

Somebody joins our channel, your channel, posts on twitter, etc - how are we responsible for what they say anywhere else, we don't control their speech.

Learn how the internet works - this has been the crux of the problem all along, you attributing things to us, and then using that as justification of your behaviour doing exactly what you're accusing us of doing. All those threats :(

HN is not the place for this conversation either.

> If we're speaking of FAKE_SIGNATURE.... No it doesn't? If implemented properly

We've always heavily restricted as well.

https://calyxos.org/docs/tech/microg-details/

> Really, please tell me in which threat model does using microg hinders security, maybe we can find a fix. So far, I've never heard any.

I keep asking the same to anyone bringing this up. We'd be happy to even submit patches to microG for any issues found and reported.

Unfortunately that is currently not supported since Android Auto is a proprietary app and needs system / OS level privileges to actually work.

Sigh, always.

The users have been banned, it's just that no mods were around at that time.

We strictly don't allow any GrapheneOS talk at all on our channels due to this drama. I don't know what else to do.

See: https://view.matrix.org/room/!aPqEsAdWuysydZNCic:matrix.org/...

Not the thing one wants to wake up to, but what can you do.

Disclosure: CalyxOS lead developer.

That makes sense, the apps are downloaded from mirrors and it automatically falls back to another if one isn't reachable

Status page: https://fdroid.checklyhq.com/

Cloudflare mirror(s) are sort of up

* https://pages.fdroidgoes.live/ should be responsive

* https://cloudflare.f-droid.org/ shows a wayback machine snapshot if it doesn't load.

More details about mirror setup: https://gitlab.com/fdroid/admin/-/issues/229

Disclaimer: I'm an F-Droid contributor

Some compression stats from my local setup. I work with a lot of source code (Android / AOSP), and big output directories (hundreds of gigabytes)

ZFS compressratio: source: 1.40x (Separate pool) output: 1.68x-2.49x (Multiple datasets to make management easier)

The output compression allowed me to use a 1TB drive as a 2TB drive effectively, allowing me to store a lot more output and not have to wipe away build output from x to build y.

That alone makes zfs worth it for me (and I know many other Android devs who use it in a similar fashion)

I'm really tired of this.

> GrapheneOS does not include any form of Play services and has no support for the OS using it. If a user installs Play services, the OS detects it and intercepts the attempts it makes to use privileged APIs and instead returns placeholder data.

Isn't that shipping an integration for a proprietary service?

How can you claim that we're the ones shipping proprietary service integrations when we ship an open source implementation, and you're the ones shipping an integration for the proprietary implementation.

I'm done here, there's no point arguing with you, you don't see reason.

> Not actually true. Do you claim that stuff like firmware cannot be shipped too?

There is precedent here, https://phandroid.com/2009/09/25/cyanogen-gets-cd-from-googl...

It's the sole reason why there exists the concept of flashing gapps are installing other custom ROMs, and that cannot be supported without verified boot.

The other way is what you're doing, which is impressive, not questioning the code / implementation, just the way you're trying to present it here.

> CalyxOS has a leaky firewall which apps can bypass and a leaky VPN tethering implementation.

We're working on fixing the one bypass. I don't know what you mean by leaky VPN tethering implementation.

We have a patch (from LineageOS) that allows tethered devices to connect over the VPN. By default in AOSP a tethered device ignores the VPN.

Wouldn't this be the opposite of leaky? It prevents leaks, especially when you have always-on VPN enabled.

> GrapheneOS has a Network toggle without those leaks and prefers the approach of fine-grained VPNs rather than using the same tunnel for everything.

We evaluated the network toggle and found it to cause crashes in apps when the permission got taken away from them unexpectedly, which is why we've gone with the solely network-level implementation.

We also do not have anything that'd make you think 'use the same tunnel for everything'. Multiple users work just fine, and in fact we now have a built-in work profile feature which lets you run another VPN in that (since that's how Android works) out of the box.

> CalyxOS includes a lot more proprietary services (Google, WhatsApp, etc.)

We do not include any proprietary services. We have microG which is open source, and the WhatsApp integration is done in open source code in the Dialer, it does not rely on anything proprietary.

In fact, you're the one who's brought up your play services approach which involves running the proprietary binary. Don't you see the irony?

I specifically avoided commenting on the comparison threads solely to not have to see this. You will not find me doing that anywhere, anytime (unless perhaps when we were on good terms)

I've done that all this time, the only time I comment on something is when somebody asks us to integrate it into CalyxOS, and that's only within our context.

You're the one here who're responding in a hostile manner, and doing exactly what you're accusing us of. Please stop.

> Does Calyx really include WhatsApp out of the box? That would indeed be a very negative point for me. As I mentioned I haven't used either.

We do not, we would never ship a proprietary app like that.

What we have is a small patch to the open source Dialer / Phone application that lets you make WhatsApp calls directly.

It only shows WhatsApp as an option if you have it installed already, if you don't you won't see it, we don't want to promote using proprietary services.

This was done after a lot of back and forth with our UX team.

> They present it as a firewall app with a fancy name, but it's just a UI for the AOSP firewall and it doesn't really work as they present it.

There is no AOSP Firewall, this is all based on code which originated in LineageOS, and we've been maintaining and extending it since about a year now. We make changes, send patches back upstream (LineageOS), and are talks in that developer.

The bypass is serious, we're looking into it and will have a working patch available shortly. It will work.

We do not muck around with the INTERNET permission and change the android permission model since that has known to crash apps, we did evaluate it before putting effort into this.

The beauty of doing this network side is that apps are unaware and keep working, unlike some apps which crash when you take away their INTERNET permission - that is why we didn't go with that approach.

What use is a toggle if it crashes the app and makes it unsable.

> The fastboot.js library powering it is a project we funded.

Thank you for funding that!

> Google's Play client libraries are still used on CalyxOS by the apps using Play services.

They'd also be used on GrapheneOS, and anywhere else basically.

> WhatsApp is clearly a proprietary service too, and CalyxOS is integrating that into the Dialer app.

The integration is entirely done into the open source Dialer app and generic enough that it could be extended to any apps that have phone numbers. Signal and WhatsApp are simply the most popular amongst those.

I did not want to get into this, but you're simply spread falsehoods.

> GrapheneOS doesn't ship integration of proprietary services like CalyxOS, whether that's WhatsApp or Google services.

We do not ship anything proprietary. We ship microG, which is "A free-as-in-freedom re-implementation of Google’s proprietary Android user space apps and libraries." - see https://microg.org/

We ship an integration with WhatsApp in the Dialer, which is entirely open source code. It is based on the existing contacts mechanism (anyone who has WhatsApp or Signal on any Android will see entries for those in the Contacts app - that is what we expose to the Dialer to make it easy to use those to make end-to-end encrypted calls.

In fact, WhatsApp is not listed by default, it only shows up if you have it installed. We believe that end-to-end encrypted calls are important, and while this would leak some metadata, if one has it installed already presumably they're fine with that. The network effect is strong!

In fact, you're the one who's promoting your approach of being able to run the proprietary Play Services - and yet you say you don't ship integration of proprietary services. Which is it? You can't ship Play Services legally anyway.

> or example, they give special unattended installation privileges to Aurora Store and F-Droid.

Aurora Store does not get unattended installation permission, it never has. It can only update installed apps, which is what Google is allowing in Android 12.

F-Droid Privileged Extension is extended, and both that and F-Droid have received security audits in the past which haven't found issues - and the Privileged Extension itself hasn't changed much since then. We're very careful about making any changes there.

It is one thing to give constructive criticism to projects, it's another to attack them directly based on falsehoods.

> Making it system-only still isn't ideal. It then requires a full OS update to push updates to microg/playservices

It does not, you can update system-apps out of band just fine.

Google does it with Play Services (and many other apps), and we have our microG builds in our F-Droid repos for out of band updates.

In fact, that is one of the big selling point of Play Services - the fact that it gets updated outside of OS updates, which means that you have a recent / the latest version on all devices regardless of their update record.

And therefore anything implemented in Play Services can be used even on older Android versions.

That's likely the size of the entire checked out tree, which would include all of the files.

I just ran the command here and my AOSP 11.0 checkout is 54GB, minus any git history, since I clone from a local mirror and use '--reference' to avoid having to copy objects.

A lot of the size here is from the various prebuilts, AOSP build is quite self-contained (jdk, clang, etc) and barely uses anything from the host.

On CalyxOS only microG can signature spoof, no other app can.

I edited the comment to fix it, thank you!

I've said this in another comment, but I'll duplicate here:

The microG creator goes into more detail about signature spoofing at https://github.com/microg/GmsCore/issues/1467#issuecomment-8... The concerns usually raised against that are due to the "default" patch included in their repository, which has a specific purpose.

We don't use that, https://calyxos.org/about/tech/microg/ are the precautions we take to try and prevent "weakening overall package security"

In addition, microG is optional and can be disabled on first install, see https://calyxos.org/features/microg/#1-microg-disabled

I'd argue that it's more akin to Ubuntu relying on Debian for updates, or Microsoft's Edge / Brave Browser / one of the many other forks relying on Google for Chromium / Blink updates.

The one distinction is in addition to the open source code comparison here, we also use some proprietary bits from their updates, which are needed to get the phone booting and basic hardware working.

On CalyxOS you do get an option to disable microG when setting it up for the first time, see https://calyxos.org/features/microg/#1-microg-disabled

microG being disabled but present is still enough for some apps to work, which makes sense given that you can disable Google Play Services on the stock OS.

Telling even the newer devices about your pubkey doesn't get the scare screen away. You see a Yellow Verified Boot warning meaning the OS is signed and verifies but with a custom set of keys.

When you lock the bootloader you block other keys, since fastboot is pretty much disabled when you do that, and the only way to install something would be via OTA updates which would have to be signed with your custom keys.

I guess maybe if you're able to get a root exploit and replace the boot image? Not exactly sure what would happen then, need to try.

You can easily go back to stock Android, http://calyxos.org/get/back-to-stock

You definitely could, we used to support it in a previous iteration.

This was also possible on the Nexus devices, although the oldest I've tried it is the Nexus 6P.

It just worked slightly differently on those, nowadays you enroll the public key by flashing it to the device, on those (Pixel 1, Nexus) you used to have the public key embedded in the kernel.