Conversation

I'll be releasing updated documentation on building proper production releases of Chromium and the Android Open Source Project with all the security features intact. As part of twitter.com/DanielMicay/st, there will be a manifest for testing AOSP with the new hardened allocator.

Quote Tweet

I'm working on properly integrating github.com/AndroidHardeni into Bionic. However, I won't be able to expand my hardening work on the Android Open Source Project into a broader set of projects again without having proper funding for the development work, hardware and server costs.

Show this thread

1

4

12

It won't have any other privacy and security improvements until further work is funded. I won't be fixing all of the upstream bugs uncovered by the hardened allocator myself so it will probably have a lot of issues for the time being. It will have a bare minimum set of changes.

1

1

The manifest for this will be at github.com/AndroidHardeni. I haven't pushed the hardened malloc integration yet, but I started pushing the minimal set of changes for proper AOSP builds. For example, fixing ro.product.model is needed for the Auditor app to work among other things.

GitHub - GrapheneOS/platform_manifest: Repo manifest for the GrapheneOS mobile privacy and security...

Repo manifest for the GrapheneOS mobile privacy and security hardening project. - GitHub - GrapheneOS/platform_manifest: Repo manifest for the GrapheneOS mobile privacy and security hardening project.

1

1

2

If there was funding for making production hardened AOSP builds, progress could be made on chipping away at upstream bugs uncovered by the hardened malloc implementation. There could also be official releases with automatic updates and proper CTS + VTS testing for each release.

1

2

I won't be expanding it into a broader project without the appropriate funding / resources though. The scope is limited to integrating the hardened malloc implementation into AOSP and setting up proper builds of that. It won't be very usable/useful without fixing uncovered bugs.

1

2

Simply doing all the debugging and release engineering necessary for production releases is a huge amount of work without even adding more privacy/security features and needs funding. It's too much work for one person unless it's their entire job, and I won't do it alone again.

2

3

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

I am working on an reproducible build/sign/release system for Pixel 3 devices: github.com/hashbang/os I plan on incorperating your work incrementally. Feel free to reach out if you want to collaborate at all, else just keep open sourcing stuff and I'll keep doing my thing :)

GitHub - hashbang/os: Open source security/privacy focused AOSP rom

Open source security/privacy focused AOSP rom. Contribute to hashbang/os development by creating an account on GitHub.

1

1

Replying to

Using those driver packages won't provide fully functional builds and will break verified boot and some other security features. Most of the components in the vendor image are open source too, so if you want to build what you can from source you need to assemble it yourself.

2

Replying to

and

They merged everything needed for reproducible builds upstream for Linux, Chromium and AOSP so it's straightforward. Making production builds of AOSP with all the security features intact is more involved but the work has been done for Pixels and other devices don't support it.

1

Replying to

and

Funding and collaboration is needed for implementing and maintaining substantial privacy and security improvements for AOSP. Release engineering is difficult because of the time investment required for testing and then debugging the issues that are uncovered by the features.

9:50 PM · Nov 24, 2018Twitter Web Client

Replying to

and

I have the documentation and scripting from before including HSM integration for signing, so setting up reproducible release builds for Pie with verified boot and over-the-air updates only took a few minutes of work. There wasn't anything requiring changes to the build approach.

1

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

if you have any docs to make my life easier by all means share :) Also I am 'lrvick' on freenode and irc.hashbang.sh.

Lance R. Vick ( @lrvick@mastodon.social )

Replying to

I have enough funding for build servers and image hosting. Also have a few willing testers. As long as the scope is -only- pixel/p devices right now this is looking fairly maintainable. Adding in all your patches ofc will take more test devices and a test channel but feasible.

1

Replying to

You aren't running the CTS and investigating all the issues it uncovers though. Building AOSP with reproducible builds is easy. It already exists and builds fine as is. Testing each release is time consuming and there are issues to investigate before even implementing features.

2

Show replies