Muhammad

@CKvikant @GrapheneOS Not really, the same dev can host their own signing service for the same security, but with verifiability too

It's kind of funny how @GrapheneOS wants to let everybody know about the "dangers" of "closed source operating systems" yet they themselves ship precompiled, presigned applications that are included in their OS and are NOT reproducible, the most you can do is compile them out of tree and include them manually. And even then, this is still a MAJOR security risk as their precompiled apps have permissions that you really don't want apps to be granted implicitly. I've attached a photo of all the permissions available to the Messaging app, which is included in GrapheneOS at build-time as a prebuilt application. I should mention this, the aforementioned Messaging application has no form of reproducible builds, meaning the only way to update these apps is for some developer to manually build this application on their build PC, sign it and then push it to a git repo. Imagine the security implications of that. (You can unzip the app yourself to check the manifest too.) github.com/GrapheneOS/pla… This is the module included into GrapheneOS. Meanwhile the actual messaging app is at github.com/GrapheneOS/Mes…. For reasons beyond me, GrapheneOS devs thought it fit to remove the Android blueprints from it, therefore making this app unbuildable inside the Android source itself. #L378" target="_blank" rel="nofollow noopener">github.com/GrapheneOS/pla… The inclusion of said prebuilt Messaging app. It's not just this app either. The included App Store, the Camera app, hell, even the Auditor. All of these apps are presigned and precompiled, and granted implicit permissions to do whatever. Why not compile them in-tree? WHY go out of your way to make them unbuildable by removing the blueprints? It's not about adding one yourself and doing it yourself, that's completely besides the point. The point is, why is some OS claiming to be security focused, yet has the ability to infect devices with a theoretical malware spread with these prebuilt apps? Why are these apps not built in-tree in the first place!? There is literally no excuse, every other app is compiled in-tree except these GrapheneOS inclusions. How does it feel to trust a random person with an app that can theoretically upload all your data to a remote server without your knowledge? Further more, besides doing such things, GrapheneOS devs have the _nerve_ to go forth and cement their beliefs on others? When they themselves don't commit to their standards? If this isn't an absolute form of hypocrisy, I really don't know what is. Maybe this post will instill some form of awareness in die-hard GOS fans. Maybe I'll get to deal with insane backlash. Who knows. At least I'm putting it out there. Maybe one day we'll get to know that this entire project was a honeypot.

@c1ph3rn0m4d @GrapheneOS I didn't, but you sure seem to, given you're participating in a post :D

@TheVancedGamer @GrapheneOS Oh you thought this is a debate? Cute!

@c1ph3rn0m4d @GrapheneOS Vanilla Android doesn't shove untraceable artifacts into a build, instead it uses a proper CI system at ci.android.com to do that. Maybe check your evidence before making such claims. :)

This so-called "threat" reeks of straight-up misinformation or a blatant hit piece, probably because you're shilling some half-baked, less-secure knockoff. (Yeah, rhetorical question, we all know why.) GrapheneOS actually follows real first-principles security: 100% open source, verifiable reproducible builds, smart modular design that doesn't pretend to be perfect while hiding garbage. I've watched real user reports flood forums for years (n=1 stories from people who actually use it daily), not a single compromise traced to these apps. Meanwhile, it's constantly praised for shutting down the exact same exploits that routinely pwn stock Android users. Your "hypocrisy" jab is pathetic and doesn't stick at all. GrapheneOS delivers on reproducibility in ways that actually matter, while you conveniently ignore how vanilla Android shoves far sketchier, unauditable prebuilts down everyone's throat without anyone raising an eyebrow. Nice try, though.

@CTI_Updates @GrapheneOS lmao how is this a burner account

@TheVancedGamer @GrapheneOS you are so wrong and retarded and a coward you had to post this from a burner acct lmao typical Muhammad things

@__extern_inline @GrapheneOS It doesn't really take a genius to realize that a bad actor within GOS could also sign said app and push it to the git repo. Of course it would eventually get caught because of reproducible builds, but it would spread regardless.

@TheVancedGamer @GrapheneOS I guess they could publish `repo manifest -r` output somewhere for those that want to reproduce exact kernel build, but I don't really see the point of "hashed artifacts" when they are already in the git repo and force push is required it to alter them.

Honestly this should be concerning for @Moto @Moto_Support, a project can't battle a simple criticism. If a project won't implement a simple verification method for apps, and instead offloads it all to the user, how can you expect them to act under good faith all the time? This same project that advertises itself as one of the most secure operating systems, won't implement a verification step like every other project does. Upon further criticism, they said that "it's standard for Android to push prebuilt apps in a git repo and include them". But is it really standard when it's one person uploading the apps manually into a repo, with no real trace of origin? Sure, the apps might be reproducible now, but will it remain the case? How can you know that the app was built without tampering? Every other project implements some form of publicly available verification. Even Google has ci.android.com, yet apparently that doesn't comply with their non-existent standards. This same project was previously criticizing /e/ OS for using prebuilt apps, but it's fine when it's themselves? A really huge case of superiority complex. If they won't agree to publishing origins of their built apps, who knows what else they're hiding.

@__extern_inline @GrapheneOS CI logs might not, but SHA256/512 hashes will. How are you gonna disprove hashed source trees and hashed artifacts?

@TheVancedGamer @GrapheneOS sure, but CI logs don't prove shit, they could be lying there for all you know.

@__extern_inline @GrapheneOS So was I, there isn't any Android "standard" that mandates pushing prebuilts into a git repo without any traceable source. In fact it's quite the opposite when even Google has a fully end-to-end CI with artifacts being delivered.

@TheVancedGamer @GrapheneOS yes, I know Google has CI/CD for everything, but I was talking about GrapheneOS.

Someone mentioned on the post that Google also has prebuilts and kernels built and packaged into the OS out of tree. Which is kind of hilarious as ci.android.com exists, which does exactly what I've been complaining about. You can trace the origins of all artifacts used in an AOSP build, you can verify that they're untampered and you can also see what code was used to compile it. Meanwhile Graphene keeps countering with "others can verify it for themselves". Which sounds really fishy. e.g. ci.android.com/builds/branche… has the compiled kernels used in Android. You can also check every other artifact out yourself.

you know the last point makes me really laugh. because unlike Graphene, Google has a completely public CI with verifiable artifacts at ci.android.com, and for the kernel, they also have ci.android.com/builds/branche…. Maybe you should try opening it and see that Google does in fact have CI for everything, including kernels. :D

@TheVancedGamer @GrapheneOS it built fine with `git clone --recursive github.com/GrapheneOS/Mes… && cd Messaging && ./gradlew assembleDebug` btw if you want to complain more about in tree vs out of tree, their kernels are also compiled out of tree and included as prebuilts ^^

@GrapheneOS yknow even with current reproducible builds, I kind of want to see some sort of proof of origin. it's entirely possible that these apps could be hijacked and delivered to specific entities.

@__extern_inline @GrapheneOS doesn't build for me, and besides, that's a debug build, and unreproducible for every run :D

@__extern_inline @GrapheneOS the app doesn't even compile right now, it depends on in-tree modules while being out-of-tree

@TheVancedGamer @GrapheneOS why does it matter if app is built in tree or out of tree? it can still be recompiled and compared with apktool/jadx output?

@GrapheneOS @TrueAmPatriot86 github.com/grapheneos/pla… Where is the signed tag that proves that this app was compiled from a clean tree?

@TheVancedGamer @TrueAmPatriot86 There's a signed tag for every signed binary release of the apps. It's verifiable that the binary releases correspond to the tags. We've provided everything needed to perform the verification. The whole point of verification is that other people do it not cloud CI infra we run...

@TrueAmPatriot86 @GrapheneOS So every GOS user is meant to compile the app and verify it themselves?

@TheVancedGamer @GrapheneOS Build it yourself, dude. Check out the tag, build the app and see if it matches. And if it doesn't match, take a look at the applications with a decompiler and see what the differences are. Don't ask retarded questions you can answer yourself.

@GrapheneOS @watch_rome_burn @forbiddenADA Then prove it that every release put into the git repos so far was compiled without any changes to the source. Thats really all that I ask for.

@TheVancedGamer @watch_rome_burn @forbiddenADA Each of our app releases has both a signed tag release and a signed binary release with a matching version. The binary release can be reproducibly built from the signed tag. It's still unclear why you believe us doing builds/signing via cloud server CI would be an improvement.

@GrapheneOS @watch_rome_burn @forbiddenADA Then make said stored apps verifiable. Make it so that i can check whether the app in the repo was compiled from the same code that's published, without having to trust someone.

There's a signed tag for each of our app releases with reproducible builds. We store the official releases of the apps in Git repositories which provides the recent history of app releases. This is the standard way to include packages with standalone releases in Android. Storing official builds in a Git repository which references the tag to build each release does not somehow make the software not open source or result in it not having reproducible builds. Building the whole OS at once isn't part of reproducibility and isn't how AOSP is built. Your claims are equivalent to claiming that a traditional Linux distribution cannot provide reproducible builds because they distribute components as standalone packages. That doesn't make any sense and is clearly not true. Repeating clearly untrue statements over and over again isn't going to make them any less inaccurate.

@GrapheneOS @watch_rome_burn @forbiddenADA I only said verify the apps that you build out of tree, if you want to move them out of tree that's fine, but make it verifiable, unlike right now where it's uploaded by some random guy

@TheVancedGamer @watch_rome_burn @forbiddenADA Storing official builds in a Git repository which references the tag to build each release does not somehow make the software not open source or result in it not having reproducible builds. Building the whole OS at once isn't part of reproducibility and isn't how AOSP is built.

@GrapheneOS @TrueAmPatriot86 didnt say a web interface, a publicly viewable CI can provide you with hashed source data to verify with the public repository, and hashed artifacts to make sure it wasn't edited. Not really that inaccurate

@TheVancedGamer @TrueAmPatriot86 You're continuing to make highly inaccurate claims about what cloud-based continuous integration systems provide. That doesn't provide any form of verification of assurance about reproducible builds. You're inaccurately claiming a web interface with build info is verification...

@GrapheneOS @TrueAmPatriot86 HOW do you keep deflecting this simple question that i ask. Show me that your apps are built from the same tree that you say they are, with absolutely no variations in the output code.

@TheVancedGamer @TrueAmPatriot86 GrapheneOS provides signed tags for all of the OS and app releases. There are reproducible builds of the OS and apps. The commits adding the official releases of the apps for inclusion in the OS have a consistent format referencing the tag for building the release. It's simple.