Ooh, I did not know this one was of the properties of Rust.
- 0 Followers
- 0 Following
- 7 Posts
But then there is also the question if you trust github (and because of that microsoft, but also the USA because of laws) with always building from the sources, and adding nothing more.
Yesterday I would have said ‘blah, they would not care about my particular small project’. But since then I read the paper recommended by a user in this post about building a compromised compiler that would installs a back-door to a type of login field. I now think it is not so crazy to think that intelligence agencies might collude with Microsoft to insert specific back-doors that somehow allows them to break privacy-related protocols or even recover private keys. Many of these might rely on a specific fundamental principle and so this could be recognized and exploited by a compiler. I came here for a practical answer to a simple practical situation, but I have learned a lot extra 😁
No, I’m not concerned about a lawsuit. It’s something that I want to do because I think that it is important. If I want to share tools with non-tech savvy people who are unable to build them from source, I want to be able to share these without anyone needing to “trust” me. The reproducible builds standards are a very nice idea, and I will learn how to implement them.
But I still wonder whether my approach is valid or not - is printing the hash of the output executable during Github’s build process, such that it is visible in the workflow logs, very strong evidence that the executable in the release with the same hash was built by github through the transparent build process? Or is there a way a regular user would be able to fake these logs?
But, if during Github’s build process the sha156sum of the output binary is printed, and the hash matches what is in the release, isn’t this enough to demonstrate that the binary in the release is the binary built during the workflow?
Thanks! I am convinced now, I will learn how to create reproducible builds.
My worry is that the build is run through npm, and if I think that the dependencies rely on additional dependencies such as openssl libraries, and I worry that it will be a lot of work to figure out what every dependency is and how to make sure that the correct versions can be installed 10 years from now. So it does look like a difficult project, but I will read more about it and hopefully it is not as complicated as it looks!
Reflections on Trusting Trust
Reflections on Trusting Trust - nano.garden
The linked paper was pointed out to me during a discussion about trusting executables built from source. Perhaps this paper is a well-known document in the hacking community, but I thought it was quite interesting and thought I’d share it. The document described how the author created a bugged C compiler that would compile UNIX code in which the “login” command would insert a backdoor. > The actual bug I planted in the compiler would match code in the UNIX “login” command. The re- placement code would miscompile the login command so that it would accept either the intended encrypted password or a particular known password. Thus if this code were installed in binary and the binary were used to compile the login command, I could log into that system as any user. The author also describes strategies to build such bugged compiler in a way that would be very difficult to detect. The document ends with a moral statement about hacking with a perspective from 1984 which is also an interesting read.
Ooh, I think I found the paper!
Ah. Cool. I was under the impression that docker images suffered from a similar issue - that one can’t verify that the image is built from the source. I’m happy to be mistaken about that.
How does a docker distribution solve this problem? Is it because the build instructions are automated by the Dockerfile?
My new phone runs GrapheneOS and I love it.
One recommendation that I would give people is that it does not need to be an all-or-nothing jump into the abyss. It can be a bit disheartening when you try to get rid of all the privacy-invasive things in your life and you get cut off from your family and friends.
After some failed attempts, the strategy that I have found more successful is that I have new phone that I installed GrapheneOS into, and I keep the older phone with whatsapp. The older phone is in Airplane mode connected to WiFi at my home. It is effectively a landline. I can still use it once or twice a day to check on my family through WhatsApp without having to broadcast my location all day to Meta. This way I don’t need to install any sandboxed Google Play services into my new phone. The old phone is the sandboxed Google Play. I also use the old phone for verifications, 2FA, and any other things that I don’t want to contaminate my new phone with.
Over time I am finding that my GrapheneOS is perfectly functional. The main difficulty is the chats services that are used by my family, friends, and work-related “group chats”. I have convinced some people to join my XMPP server, including my mom (wuhuu), but it is an uphill battle. That’s why the other phone is still essential for me.