Share this page!

DanielMicay Profile picture
Twitter logo
4 Nov, 5 tweets, 2 min read
We need help building a more complete historical archive of the GrapheneOS code. Please get in touch with me if you have clones of the Git repositories from 2015 or earlier. The repositories on GitHub were the ones created for the CopperheadOS Beta but don't have older tags, etc.
There was an earlier generation of repositories for the CopperheadOS Alpha and earlier when the project was based on CyanogenMod, including before it was branded as CopperheadOS. It would be ideal to obtain an archive of this code. Obtaining this would make a big difference.
The network graphs like github.com/GrapheneOS/pla… and github.com/GrapheneOS/pla… show some of the forks of the project from the CopperheadOS Beta era. There were also forks in the earlier Alpha era and earlier. Ideally, we can get a full archive of it, not just specific repositories.
We have complete tags for NBD90Z.2016.10.05.01.09.35 and later. This was before the time period when the source code was placed under non-commercial usage licensing in a misguided attempt to prop up the former sponsor. Need a much more complete archive of 2014/2015 tags/branches.
I didn't realize this would ever be important so I didn't keep local archives of everything. gharchive.org can be used to look back at a lot of the commit metadata which is helpful but it's not as good as a proper archive of all of the repositories with the code, etc.

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with DanielMicay

DanielMicay Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @DanielMicay

DanielMicay Profile picture
5 Nov
github.com/GrapheneOS/har… was initially released in August 2018. I developed it to replace the port of OpenBSD malloc to Linux and Android that I made in 2014.

Copperhead was founded in late 2015 and split from my open source Android hardening project in June 2018.
My open source Android hardening project had already been renamed to the Android Hardening project when hardened_malloc was developed and released.

The hardened_malloc license requires attribution. License and copyright header needs to be included by anything using the code.
Copperhead is misrepresenting my allocator hardening work throughout the years as their own. They're fraudulently misrepresenting my open source work throughout the years as their own and by not complying with the licensing. This is a particularly egregious case of it though.
Read 21 tweets
DanielMicay Profile picture
1 Oct
@mamushi_io @intimitatem @Fonta1n3 @GrapheneOS You're just selling a proprietary project forked from our code in violation of the licenses. You're supporting a company that's anti-open-source and is waging a nasty war against the open source project they depend on. It's hard to take a proprietary ripoff seriously.
@mamushi_io @intimitatem @Fonta1n3 @GrapheneOS CopperheadOS is a fork of our legacy codebase in violation of the licenses with DRM and tracking added to the Updater app. It is primarily just AOSP with a custom boot animation and wallpaper, since they have not meaningfully maintained or developed real privacy/security work.
@mamushi_io @intimitatem @Fonta1n3 @GrapheneOS You're selling people a very expensive product that's making them less private and secure. The original open source project is available for free with far more privacy and security, and without tracking. People are far better off with iPhones than yet another 'secure' phone scam.
Read 5 tweets
DanielMicay Profile picture
21 Sep
The public Android security bulletins are not nearly as useful as they used to be since so much information was stripped out of them. Need to figure out even basic details entirely from the commit message and changes to the code. Internal bulletins still have more information.
This makes it difficult to figure out when a bug was fixed with only the details of the bug including the impacted subsystem but not a CVE ID. threatpost.com/bluetooth-spoo… says the issue is unpatched on Android but that seems based on the researchers testing a device without updates.
It's highly likely that android.googlesource.com/platform/syste… is the fix for this issue since it's a fix for a security bug in pairing tied to authentication of a device that was previously paired. I'm not entirely sure it's the same bug since there aren't enough details available for the fix.
Read 9 tweets
DanielMicay Profile picture
16 Sep


Android 11 disables usage of stable "privacy" addresses for networks where MAC randomization is being used. We'll no longer need to disable this feature. The other issues we've discovered and put initial work into addressing are still problems though.


Silly bot.

Disabling IPv6 would certainly be an easy way to address multiple issues in the Linux kernel implementation providing a way to track users across networks. Linux kernel's take on "privacy" addresses regresses privacy in some very serious ways.
Linux reuses "privacy" addresses across networks. This leaks that it's the same device connecting from a different network. It does this even when randomizing the MAC address. It also uses a very long lifetime for these addresses by default. It's a pretty bad implementation.
Read 5 tweets
DanielMicay Profile picture
12 Sep


Unfortunately, some users upgrading from this cancelled beta release may encounter a broken upgrade path to the next beta release where the device forces you to do a factory reset. This is caused by downgrading the kernel, but we're unsure exactly why.
Our suspicion is that the backport of f2fs made changes to the on-disk format that are not backwards compatible with the previous version. It's seemingly only an issue on a subset of users on the Pixel 3a and Pixel 3a XL. This does not impact people that aren't beta testing.
We always test the future upgrade path before pushing out a release to the beta channel. However, in this case the upgrade path is being broken by reverting a large set of changes that proved to be too problematic for us to ship rather than waiting for Android 11 as a whole.
Read 7 tweets
DanielMicay Profile picture
11 Sep
When you decode media with hardware decoding, you're depending on the security of the media decoding firmware / hardware and again IOMMU isolation to provide any kind of sandbox. You depend on the security of the CPU. When you go browse the web, running untrusted JavaScript code,
you are assuming that the CPU is actually capable of safely running that code without it gaining control over everything else. You're relying on the firmware / microcode / hardware security. A best case scenario is they designed it to update as much as possible after the fact.
Otherwise, a hardware vulnerability is found, and they are often found, and you're just screwed. We live in an time where serious game over bugs exploitable by JavaScript code are being published and fixed via microcode / firmware updates for CPUs and GPUs on a regular basis.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

Like this author's thread?

Get email notifications when new thread is out from this Author!

Check out other threads from this Author!

Read all threads by @DanielMicay