Git Product home page Git Product logo

appbundler.jl's Introduction

PeaceFounder.jl

PeaceFounder is a centralised E2E verifiable e-voting system that leverages pseudonym braiding and history trees. The immutability of the bulletin board is maintained replication-free by voter’s client devices with locally stored consistency-proof chains. Meanwhile, pseudonym braiding done via an exponentiation mix before the vote allows anonymisation to be transactional with a single braider at a time. In contrast to existing E2E verifiable e-voting systems, it is much easier to deploy as the system is fully centralised, free from threshold decryption ceremonies, trusted setup phases and bulletin board replication. Furthermore, the body of a vote is signed with a braided pseudonym, enabling unlimited ballot types.

Introduction

everal end-to-end (E2E) verifiable e-voting systems exist, such as Helios, Scytl, Belenios, ElectionGuard, Estonia's system, and Verificatum, with many available under open-source licences. They all encrypt and mix votes through a re-encryption shuffle and use a threshold decryption ceremony. This allows voters to track their encrypted votes and the public to verify the final tally. However, it depends on the integrity of the bulletin board and the coordination of the threshold decryption ceremony, presenting challenges for smaller communities and organisations.

To make a point, let's consider a Helios voting system. The vote in Helios is stored in a group element, encrypted and signed by a digital signature provider, and then submitted to the bulletin board. When the vote closes, votes go through the reencryption shuffle and are decrypted in the threshold decryption ceremony. Voters can ensure that their vote has been counted by finding their encrypted vote within the list of inputs of the mix cascade. Furthermore, everyone can verify the final tally by counting the decrypted votes and verifying supplemented zero-knowledge proofs without compromising privacy. In this way, the integrity of the election result can be assured.

However, issues like forced abstention and potential vote substitution of unverified votes can happen if authorities are corrupt and auditing/monitoring does not occur. Publishing vote-casting signatures can alleviate many of those issues, but that violates participation privacy. The threshold decryption ceremony further compounds the system's complexity; if more than a few are corrupt, votes can remain encrypted, while a low threshold risks privacy breaches. These factors, coupled with the technical intricacies of deployment, make Helios less feasible for small to medium-sized communities, leading to a preference for simpler black box systems to prevent questions from being asked, which can foster trust at the expense of trustworthiness.

A significant improvement over Helios is the Selene system, which offers a voter-assigned tracking number and shows their votes next to them after the vote. Recent usability studies with Selene have demonstrated that voters appreciate the ability to verify their vote in plaintext. This allows them to discard their trust in advanced cryptography as they can see how their vote is counted. As the tracking number is not published before the vote and is deniable, it is also coercion-resistant. In addition to clever cryptography, it can also detect malware interference. However, the threshold decryption ceremony still needs to be deployed along with the bulletin board and thus would generally suit only state-like elections.

Haenni & Spycher proposed a system using exponentiation mixes to anonymise voters' pseudonyms, eliminating the need for a threshold decryption ceremony. However, the benefits of such a system have yet to be reaped as it requires a trusted bulletin board that does not discard unfavourable votes; thus, deployment of such a system needs to be distributed and hence offers minor deployment improvements over Helios. Furthermore, over 13 years, a single open-source system has yet to be implemented.

The innovative approach by PeaceFounder combines pseudonym braiding developed by Haenni & Spycher with a history trees-enabled bulletin board (Crosby & Wallach). When voters cast their vote, their devices receive inclusion proof of the vote, which can later be verified to be binding to the tally with consistency proof. By having only a few voters who request their device to check the proofs, the immutability of the bulletin board is guaranteed. Thus, once the server has assured that the vote is recorded, there is no way for it to be removed. This allows the system to be fully centralised and, thus, makes it easy to self-host.

However, such a system poses many challenges compared to the orthodox approach. To protect against a corrupt server that discards unfavourable votes, voters must have the option to route the vote through proxy/monitor, which adds a challenge with coercion/bribery. To reap the benefits of braiding pseudonyms with any other community/organisation worldwide, the voters must be registered long before the vote starts, which would produce a bad user experience. Therefore, disengaging anonymisation from voting requires long-standing accounts, which poses an issue for continuous member registration and termination; on top of that, the votes need to be delivered over an anonymous channel not to be traceable by a corrupt authority. All of them are addressed with the PeaceFounder project in innovative ways.

Demo

An 8-minute YouTube demonstration is available here:

IMAGE ALT TEXT HERE

References

  • Rolf Haenni and Oliver Spycher. Secure internet voting on limited devices with anonymized DSA public keys. 2011
  • Scott A. Crosby and Dan S. Wallach. Efficient data structures for tamper-evident logging. 2009
  • Björn Terelius and Douglas Wikström. Proofs of restricted shuffles. 2010.

appbundler.jl's People

Contributors

janiserdmanis avatar pallharaldsson avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

appbundler.jl's Issues

Discouraging use of Pkg.BinaryPlatforms

Over in Pkg.jl, I'm trying to fix invalidations. AppBunder is using the old Pkg.BinaryPlatforms API rather than sticking with the newer Base.BinaryPlatforms.

One of my proposed fixes involves making Pkg.BinaryPlatforms.Linux and the related platform types into a constructor for Base.BinaryPlatforms.Platform. Methods such as Sys.islinux should continue to work in the expected way.

julia> Pkg.BinaryPlatforms.Linux(:x86_64) |> typeof
Base.BinaryPlatforms.Platform

julia> Sys.islinux(Pkg.BinaryPlatforms.Linux(:x86_64))
true

Could you consider refactoring to not use Pkg.BinaryPlatforms.Linux as a type?

JuliaLang/Pkg.jl#3736

Clarify README

Hi,

Reading through the README, I think the package works on all three platforms to make (GUI) apps already, but I want to know does it for sure make one file (for each) that you can download and install by double-clicking by end-users, in one step and it installs and runs? At least on Windows (and also for Linux)?

AppBundler expects an application folder which contains main.jl, Project.toml and Manifest.toml. The application entry point is the main.jl, which allows starting the application with julia --project=. main.jl from the project directory. A Project.toml contains many adjustable template variables under a [bundle] section.

That's all you need at a minimum, and I think at installation the dependencies will be downloaded for you? Or bundled with? I've seen suggested that Julia itself could NOT be bundled rather referred to. I'm ok with whatever that works for now, but cool if the bundled could be really small. In all cases source code is distributed (compressed) and you end up with it decompressed, not compiled, but that's a possible add-on with PackageCompiler.jl? And it doesn't make your work redundant, more like they are complementary and could work together.

The configuration of the bundle sits in a meta folder from where files take precedence over the AppBunlder recepies folder.

2 typos: AppBunlder recepies -> AppBundler recipes

bundle_app(MacOS(:x86_64), "MyApp", "build/MyApp-x64.app")

That implies 64-bit, x86. I don't care too much about 32-bit, on Windows, I suppose it could be done and ARM build etc. for Macs. x86_64 may be safer for now, also to work for older macs. Can you make a "fat binary" i.e. the first step is x86 since good enough, and it dynamically chooses ARM Julia or x86 Julia?

For Linux, the extension .snap and Windows .zip for destination determines whether the output is compressed, which can be overridden by compress=false in the keyword arguments.

This is a bit unclear, .snap is compressed. And .zip is too (on all platforms) but you get a MSIX bundle on Windows?! I suppose it is compressed and .snap and all you distribute, so when do you want uncompressed?

The resulting bundles can be easily tested on the resulting platforms. The testing phase works without any postprocessing as follows:

You can just double-click to test (with or) without postprocessing on at least MacOS (so then since it works, why does it need any postprocessing?). I understand the rest as you must do post-processing on the platform, as a developer, not end-user. But hypothetically it would not be needed, could be done on e.g. Linux for a Windows bundle.

Note that you will face difficulties when using AppBundler from Windows for Linux, macOS and other UNIX operating systems, as Windows does not have a concept of execution bit. By hand, you could set chmod +x to every executable on the resulting platform. Technically, this can be resolved by directly bundling files into a tar archive and processing the incoming archives without extraction, but this will not happen. Thus, it is better to use WSL when bundling for other platforms on Windows.

I suggest something like "AppBundler apps made with Windows for other platforms: Linux macOS and other UNIX operating systems. Since Windows".. At first I read as from "Windows for Linux" as if that were a thing, you confusing with WSL. or wine. You mean you can "cross-compile" except no compilation done, but can you also make one bundle that works on app platforms?

For snap, it is also worth mentioning the snap try myapp command, which allows one to install an application without squashing.

Rather without unsquashing (use unsquashfs)? Or did that refer to mksquashfs?

For Windows, one has to install makappx, signtool, and editbin installed with WindowsSDK.

typo for MakeAppx?!

You need those tools, i.e. "cross-compiling" from Linux is maybe not possible, or would work with wine?

Installation of Windows SDK fails.

[I'm unclear why, or only on non-Windows/Parallels, but I think you're saying not a problem.]

Set julia.exe to be Windows application editbin /SUBSYSTEM:WINDOWS myapp\julia\bin\julia.exe

That part is to make it a GUI Windows app (to not get a console window). Since the GUI vs console distinction isn't there on other platforms, can it be stated this works for non-GUI programs too? On non-Windows at least. And on Windows if you skip that step.

Suggestions on AppBundler

First off, I want to say "thank-you" for doing this. Appbundler.jl seems like a huge step for the Julia community: being able to distribute double-clickable applications is a big deal, and without this tool, I wouldn't know where to begin to start tackling this issue. The fact that you've tried to do this for MacOS, Windows, and Linux is even more impressive!

I realize that this is not the final polished version, and it is really a first draft, but I wanted to give some feedback on the documentation that would allow Appbundler to be more accessible to the Julia community at large.

  1. Could you explain the recipes in more detail? What are they for? How do they work? When should I use them, and how do I use them?

  2. I found this example confusing: "bundle_app(MacOS(:x86_64), APP_DIR, "$BUILD_DIR/gtkapp-x64.app")". I'm no MacOS/Unix command-line expert (I'm guessing most of the incoming Julia users are not), but when I read this, I assumed the $BUILD_DIR was some sort of special variable. I initially tried something like this:

AppBundler.bundle_app(MacOS(:aarch64), "/Users/…/Development/AppBuilderVersion/Trichromacy", "$BUILD_DIR/Trichromacy.app")

…and got this as an error:

ERROR: UndefVarError: `BUILD_DIR` not defined`

Of course, this works:

AppBundler.bundle_app(MacOS(:aarch64), "/Users/…/Development/Trichromacy/AppBuilderVersion/Trichromacy", "/Users/…/Development/Trichromacy/AppBuilderVersion/Trichromacy.app")

Is $BUILD_DIR a variable that we should know about? Is it part of AppBundler, but isn't working for some reason? If not, maybe it would be easier to show an example like this:

AppBundler.bundle_app(MacOS(:aarch64), "/Users/…/Development/myAppProject/myApp", "/Users/…/Development/myAppProject/myApp.app")

Take home message: When in doubt, pretend we are dumb!

MacOS

  • Many of us have never had to codesign an app before (and I've been coding on Macs since 1993! I miss Codewarrior…). Maybe include a link to this Youtube video on how to make a certificate:

https://www.youtube.com/watch?v=OpR9-onRZko

  • Also, feel free to include my command line example for codesigning:
sudo codesign --verbose --deep --force --sign "MyCertificate" --options runtime --entitlements "/Users/…/Development/myAppProject/myApp.app/Contents/MacOS/Resources/Entitlements.plist" "/Users/…/Development/myAppProject/myApp.app"

Overall, this is a really cool tool! I can't thank you enough for doing this, as I think this has the potential to have a huge effect on the future of Julia outside of academia.

First try on MacOS

Julia 1.9.3.
MacOS 14.0
ARM64

I entered the following from the terminal:

julia> import AppBundler
julia> import Pkg.BinaryPlatforms: Linux, MacOS, Windows
julia> AppBundler.bundle_app(MacOS(:x86_64), "/Users/.../AppBuilder Version/trichromacy", "/Users/.../AppBuilder Version/trichromacy.app")

(paths edited to maintain privacy).

AppBundler.bundle_app(MacOS(:x86_64), "/Users/.../AppBuilder Version/trichromacy", "/Users/.../AppBuilder Version/trichromacy.app")
[ Info: Rule with origin macos/Resources is skipped as not found in default or override path.
[ Info: Rule with origin precompile.jl is skipped as not found in default or override path.
ERROR: IOError: mkdir("/Users/.../AppBuilder Version/trichromacy.app/Contents/Libraries/startup/SplashScreen"; mode=0o777): no such file or directory (ENOENT)
Stacktrace:
 [1] uv_error
   @ ./libuv.jl:100 [inlined]
 [2] mkdir(path::String; mode::UInt16)
   @ Base.Filesystem ./file.jl:185
 [3] mkdir
   @ ./file.jl:177 [inlined]
 [4] merge(source::String, target::String)
   @ AppBundler ~/.julia/packages/AppBundler/7VFZ4/src/bundler.jl:64
 [5] build(bundle::AppBundler.Bundle, destination::String, parameters::Dict{String, Any})
   @ AppBundler ~/.julia/packages/AppBundler/7VFZ4/src/bundler.jl:121
 [6] bundle_app(platform::MacOS, source::String, destination::String; julia_version::VersionNumber, with_splash_screen::Nothing)
   @ AppBundler ~/.julia/packages/AppBundler/7VFZ4/src/recepies.jl:34
 [7] bundle_app(platform::MacOS, source::String, destination::String)
   @ AppBundler ~/.julia/packages/AppBundler/7VFZ4/src/recepies.jl:1
 [8] top-level scope
   @ REPL[23]:1

It does create a MacOS application package containing:

Contents
...Libraries
...Resources
......icon.icns

It looks like it is trying to make a splash screen, despite the parameter set to "nothing".

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.