max

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.

Thanks. In the future I work using the Reproducible Builds practices and use OpenBSD to sign my builds.

In the immediate situation I want to know whether there is a way to use GitHub as my trusted third-party builder. I would like to share something with people - some of who might not have the skills to replicate the build themselves, but I still would like to be able to point them to something that is easy to understand and give them argument.

My current argument is: "See, in the github logs you can see that github generated that hash internally during the workflow, and it matches the hash of the file that you have downloaded. So this way you can be sure that this build really comes from this source code, which was only changed here and there". Of course I need to make absolutely sure that my argument is solid. I know that I'm not being malicious, but I don't want to give them an argument of trust and then find out that I have mislead them about the argument, and that it was in fact possible to fake this.

I think you can even upload release files manually, independently of if you use actions or not, so it can never be guaranteed that it was built from the sources.

True, but that's why my current idea is the following:

As part of the wortkflow, GitHub will build the executable, compute a few different hashes (sha256sum, md5, etc..), and those hashes will be printed out in the GitHub logs. In that same workflow, GitHub will upload the files directly to the release.

So, if someone downloads the executable, they can compute the sha256sum and check that it matches the sha256 that was computed by github during the action.

Is this enough to prove that executable they are downloading the same executable that GitHub built during that workflow? Since a workflow is associated a specific push, it is possible to check the source code that was used for that workflow.

In this case, I think that the only one with the authority to fake the logs or mess with the source during the build process would be GitHub, and it would be really hard for them to do it because they would need to prepare in advance specifically for me. Once the workflow goes through, I can save the hashes too and after that both GitHub and I would need to conspire to trick the users.

So, I am trying to understand whether my idea is flawed and there is a way to fake the hashes in the logs, or if I am over-complicating things and there is already a mechanism in place to guarantee a build.

I think that any step that facilitates verifying the build is great. If trust is required, then I should simply not release any executables if I want to remain anonymous. I would like to be able to release executables without needing to ask people to blindly trust me. I would like to be able to show them reasonably good evidence that the program is built from the source that I say it is.

If I understand this correctly, signify would allow someone to verify that the executable was built by me. But then they would still have to trust me, because I can also sign the malicious executable.

Finally. Someone noticed 🥹

Having 55% of hash doesn’t mean you’ll make profit by attempting a doublespend

But a pool could be turned into a malicious pool by an adversary that takes control of it. A clear disadvantages of centralization is that it creates a single point of failure.

Even a malicious pool could at worst mine empty blocks for a while.

Why is this the case? I still have not studied the Monero protocol yet.

The creator of the tool is the admin of lemmings.world, and the tool is hosted at schedule.lemmings.world. So, if you have a user at lemmings.world, you can use this tool without having to trust a third-party.

If you don't have a user there, you can create a user in that instance for the purpose of creating scheduled posts. Removing the need to trust two parties rather than one.

And, of course, since the source code is open anyone else can attach this to their own instance! Pretty cool.

Ah, do you mean "hate speech"?

Thanks! It is some consolation. 🫂