Raphiel Rollerscaperers

@GrapheneOS @TrueAmPatriot86 Who is the verifier? How do they verified it? Where could one verify it? This is literally the gist of my questions too

@raphielscape @TrueAmPatriot86 Security preview releases are reproducible and can be confirmed across multiple locations run by different people. The default are the regular non-security-preview releases which are what the web installer and releases page use. Security preview releases are completely optional.

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.

@GrapheneOS @TrueAmPatriot86 Lack of good faith? You're completely evading my questions here, I'm unrelated to OP or SailfishOS, I'm just giving my bread a dip on a coffee, if you say it's completely worthless, how is your inexistent solution be better than that?

@raphielscape @TrueAmPatriot86 No, it's completely worthless and irrelevant. It demonstrates a lack of good faith engagement on your part. It shows you're primarily here to support the person who made this thread to attack our project with fabrications to support SailfishOS. We're well aware of the context.

@GrapheneOS @TrueAmPatriot86 Publishing the logs will attest to the build hashes that used to build the images at time, as I said on the other thread, how would one attest reproducibility for builds that has embargoed changes? Logs can be a Proof-of-hash used to build prior when embargoed code slated to GA

@raphielscape @TrueAmPatriot86 It simply isn't useful to publish build logs and the claims both of you are making about CI infrastructure and build logs do not make any sense whatsoever. Publishing a build log from our build machines would not have any value for verifying anything. What do you think those are?

@GrapheneOS @TrueAmPatriot86 And how about the builds that has embargoed changes from your partners?

@GrapheneOS @TrueAmPatriot86 The scenarios I described is for pre-flash and pre-OTA installation, narrowing the scope a bit, do your Alpha and Beta testers tests the Reproducibility of the build they tested? If so, why don't you provide a way to easily attest to their build reproducibility results?

@GrapheneOS @TrueAmPatriot86 @TheVancedGamer I'm going to further extend to your collaboration too, you for sure can't apply reproducible build as an attestation for the build reproducibility until the embargo lifted up, how the build can be trusted before flashing until reproducibility can be tested externally?

@GrapheneOS @TrueAmPatriot86 @TheVancedGamer If users can trust the build from you and that you can attest that by making your build transparent to begin with without telling user to "Just build the OS like we described on #reproducible-builds" target="_blank" rel="nofollow noopener">grapheneos.org/build#reproduc…", for a pre-flash attest, why are you vehemently refused it?

@TrueAmPatriot86 @GrapheneOS @TheVancedGamer In a way the compiler can be swapped at build and it would be count as one

@TrueAmPatriot86 @GrapheneOS @TheVancedGamer I know that the term used strictly for compilers itself, but in this case, it can be slightly broadened to that

@TrueAmPatriot86 @GrapheneOS @TheVancedGamer Users is unlikely to verify the build directly (and let's be real no one verifies OTA before applying it) so this is a case of a possible Trusting Trust attack

@TrueAmPatriot86 @GrapheneOS @TheVancedGamer My question is legitimate, if you don't have any inputs here, you're the one who's trolling, in cases where the infiltration happens during build that is clearly opaque (malicious actor within the team itself), it can be hard to be quickly identified when OTA is served

@GrapheneOS @TrueAmPatriot86 @TheVancedGamer This would also require the user to trust everything too, especially for parts that you ships as prebuilt, how can we verify that you're not vulnerable to Trusting Trust attack?

@raphielscape @TrueAmPatriot86 @TheVancedGamer Read x.com/GrapheneOS/sta… in full which already addresses this. We have reproducible builds of our apps and OS which are going to be used for configurable client-side enforcement of enforcing matching results from multiple first and third party build locations. Read the post.

@TrueAmPatriot86 @GrapheneOS @TheVancedGamer It does not guarantee that the build can be trusted, though if update engine has a vulnerability (e.g signature parser buf overflow), both cros and android would be in a lot of pain, but there is a possibility of this might happen and unknown to even Google

@raphielscape @GrapheneOS @TheVancedGamer If somebody tampers with the OTA update artifact delivered to your phone, your phone refuses to install because the OTA artifact is signed with a key known to the phone. Honestly, you should have fewer opinions and more time to read up on how things work.

@TrueAmPatriot86 @GrapheneOS @TheVancedGamer If you're part of Android Security or anywhere near Device and Services, we're doomed

@raphielscape @GrapheneOS @TheVancedGamer CI.android.com builds internally on Google servers owned by Google. They do not build on any third party cloud. I worked for Google. I would know.

@GrapheneOS @TrueAmPatriot86 @TheVancedGamer In cases where the OTA is somehow intercepted (as in one somehow convinced update engine to accept the OTA), this would be your weak point if you didn't let users verify the build beforehand, before they accepted the OTA to be installed

@GrapheneOS @TrueAmPatriot86 @TheVancedGamer Stock Pixel verifies the OTA integrity too, and I didn't see you deviate far from it based on your changes on the update engine and your OTA app, this also assumes that the hash is a trusty and you verify the hash pre-OTA

@TrueAmPatriot86 @TheVancedGamer @GrapheneOS Logs are one point of truth, Point-of-time build logging is one of the truth, artifact, and the build itself would need to be verifiable too, as I said on the other thread, if the whole build flow is not verifiable, how would one trust the OTA builds?

@raphielscape @TheVancedGamer @GrapheneOS Well, if you think that looking at logs means that you have verified that a build reproduces to the published source code, then — respectfully — you are talking flatulence out of your anus, and you should not be in software engineering.