Skip Navigation
How can I prove that a downloadable executable is built from the published source?
  • 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 😁

  • How can I prove that a downloadable executable is built from the published source?
  • 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?

  • How can I prove that a downloadable executable is built from the published source?
  • 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?

  • How can I prove that a downloadable executable is built from the published source?
  • 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!

  • Hacking @lemmy.ml Max @nano.garden
    Reflections on Trusting Trust

    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 describes 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.

    1
    How can I prove that a downloadable executable is built from the published source?
  • 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

  • Keep Your XMR Private: What is a DeGoogled Phone? (video)
  • 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.

  • How can I prove that a downloadable executable is built from the published source?
  • 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.

  • How can I prove that a downloadable executable is built from the published source?
  • 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.

  • How can I prove that a downloadable executable is built from the published source?
  • I think that any step that facilitates verifying the build is a 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.

  • How can I prove that a downloadable executable is built from the published source?

    I have forked a project's source code on GitHub. The program takes a private key as an input and that key must never leave the client. If I want to share a pre-built executable as a release it is essential that I can prove beyond reasonable doubt that it is built from the published source.

    I have learned about how to publish the releases by using a Workflow in the GitHub actions such that GitHub itself will build the project and then repare a release draft with the built files as well as the file hashes..

    However, I noticed that the release is first drafted, and at that point I have the option to manually swap the executable and the hashes. As far as I can tell, a user will not be able to tell if I swapped a file and its corresponding hashes. Or, is there a way to tell?

    One potential solution that I have found is that I can pipe the output of the hashing both to a file that is stored and also to the publicly visible logs by using "tee". This will make it such that someone can look through the logs of the build process and confirm that the hashes match the hashes published in the release.

    Like this:

    !

    I would like to know whether:

    • There is already some built-in method to confirm that a file is the product of a GitHub workflow

    • The Github Action logs can easily be tampered by the repo owner, and the hashes in the logs can be swapped, such that my approach is still not good enough evidence

    • If there is another, perhaps more standard method, to prove that the executable is built from a specific source code.

    41
    51% Attack
  • 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.

  • App to schedule posts on Lemmy
  • 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.

  • How's your week going?
  • PhD thesis! 😅

    Gluing my ass to the chair won't be sufficient. I think I have some form of computer distraction addiction or undiagnosed ADHD, because when I am sitting at the computer I find it really hard to do what I need to do. I am able to find a universe of distractions by slightly moving my fingers, and I have an inordinate ability to psychologically (not rationally!!!) justify it as being somewhat useful. The only thing that saves me is that I can be very efficient when I do focus, but this has become more difficult as the complexity of the work increases, and so many different figures, tables, and concepts have to coalesce together to tell a story that I genuinely believe...

    I would probably have a better chance trying to write with pencil and paper in an isolated island than with LaTeX in my computer....

  • How's your week going?
  • Thanks! I'm at 90% now :) Things that affect the nerves are scary, but the doctor helped calm my fears as symptoms were consistent with a not-too-serious sinus infection.

  • Lemmy instances @lemmy.ml Max @nano.garden
    New instance: nano.garden

    I have set up an instance to host an unofficial community centered around the cryptocurrency Nano (XNO): https://nano.garden

    The purpose of the instance is to have a space in the lemmyverse to discuss the Nano cryptocurrency project and the community projects being built around it.

    I want to play around with the integration of nano into the fediverse, but I don't want to do this in an invasive manner, so I've set up an instance to try to build some of these tools directly into the UI without inconveniencing others. Anyone else who needs an instance to try out their own nano-related inventions is more than welcome to try them out here. You may consider it a nano-playground in the Lemmyverse.

    I chose Nano for this because I know that there are many open source projects related to 'tipping bots' and faucets, transfers are very fast and free, and the community that I've encountered is nice. I also found out that there is already a nano tipping button implemented in a mastodon instance, and I may draw some inspiration from that: https://xno.social/home

    0
    InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)MA
    Max @nano.garden
    Posts 3
    Comments 35