This week I’ve been paying by cash, and I noticed a few things.

One thing is that there is a lot of people paying with cash that are doing so because they do not have another option. Some of them are simply tourists without a working card, but I suspect some of them might really have no card at all.

The other is that the people at the shop do notice when a long line of buyers stand to pay with cash. I have seen cashiers struggling to get someone to stand on the second cash register to offload some customers.

As for the ethical vendors… I struggle with this. It is just so much more convenient to go buy from the Albert Heijn that’s right under my apartment. I tried the shops around, but they rarely have what I want, products are often more expensive, and lower quality. I also don’t know how to tell whether specific small vendors are ethical vendors or not. So, for now I just go to AH for most of my purchases.

Dank je wel!

Thanks! Not only is this a great list of actions, but it also has helped me see this whole issue from a new perspective. More specifically, I multiple times I have tried to switch to cash-only because of privacy reasons, and I eventually become discouraged. For example, I recently gave up again. I have a shared card with my girlfriend, and she doesn’t really care much about privacy, so I felt like I was punishing myself for not good reason by paying with cash if my girlfriend next was going to pay with our card anyway.

But now that you have framed it from the point of view of those accepting cash, it does give me an additional source of motivation. It’s not only about my personal privacy, but also about pressuring vendors to accept it. This makes it worth it even in cases where there might not be a privacy benefit. Starting now, attempt #I-lost-count begins.

You are right… Cash is king, and letting it be phased out is not a good idea.

You have me on board - how do we stop this?

Interesting. I haven’t followed development in the space of “official” crypto currencies, but my impression is that these will probably be centralized, have little to no privacy features, and that the governments will be able to control access to the funds.

But I may be wrong - maybe they are actually building decentralized crypto networks? I just find it hard to believe that a government would do this.

Yes, it is increasingly difficult to pay with cash in the Netherlands. Even at the Albert Heijn they have set it up such that it is a lot more convenient NOT to pay with cash. They have a large amount of self-service pin-only checkouts, and one or maybe two workers accepting cash at the manual checkout lane.

One path is to make an effort to resist this digital move and pressure politicians so that they enforce these type of rules and that cash is accepted. But I think this can at best slow this process down.

The other path is to embrace the digital move and start integrating crypto currencies into our societies in a more substantial manner. I know that many people have given up in crypto, but, putting speculation and hype aside, crypto is the best way we know of to integrate cash-like payments into the digital world. Right? Or is this something others disagree with?

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?

Ooh, I did not know this one was of the properties of Rust.

Thanks! I am convinced now, I will learn how to create reproducible builds.

My worry is that the build is run through npm, and I think that the dependencies rely on additional dependencies such as openssl libraries. I worry that it will be a lot of work to figure out what every npm dependency is, what libraries they depend on, and how to make sure that the correct versions can be installed and linked by someone trying to reproduce the build 10 years from now. So it looks like a difficult project, but I will read more about it and hopefully it is not as complicated as it looks!

Ooh, I think I found the paper!

Oof:

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

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?

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 🥹

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.