Standalone Executable

[artoonie]

Auto-create executables using jpackage.

Issues:

1. The version number is now in three different places. We need an easy way to sync this across the project, but I couldn't find a straightforward way yet. We'll need a ticket to track this.
2. We're now creating a ton of packages: the launchable binaries (jpackage), the java runtime image (jlinkZip), SHAs for each, x3 platforms --> the packages are around 350mb. When a release is created, this won't be an issue since people can just download the relevant file, but we should consider whether we want to support the jlinkZip image indefinitely, or if the jpackage will supercede it

[HEdingfield]

Curious why we're merging this into master instead of develop? Just so we can test it out sooner?

MacOS packages aren't signed, and seem impossible to install on newer macs. They are painful to install on older macs. We probably need to sign the packages, which I believe require paying Apple $100/year?

My knee-jerk reaction to this is helllllllll no. But I guess we can see what @chughes297 thinks.

Also, I'm happy to test the bins for Linux and Windows if you can point me to where they are.

The version number is now in three different places. We need an easy way to sync this across the project, but I couldn't find a straightforward way yet. We'll need a ticket to track this.

We should be able to get rid of it in release.yml, right, defaulting to the GitHub tag variable instead? Looks like there are some merge conflicts to resolve with release.yml anyway.

We're now creating a ton of packages: the launchable binaries (jpackage), the java runtime image (jlinkZip), SHAs for each, x3 platforms --> the packages are around 350mb. When a release is created, this won't be an issue since people can just download the relevant file, but we should consider whether we want to support the jlinkZip image indefinitely, or if the jpackage will supercede it

Yeah, I think jpackage will replace jlinkZip. However, we should discuss the ramifications of this with @chughes297 to make sure it doesn't cause any additional security issues having them use a compiled version. Also wondering if we need to provide SHA512 checksums for the bins too.

[chughes297]

MacOS packages aren't signed, and seem impossible to install on newer macs. They are painful to install on older macs. We probably need to sign the packages, which I believe require paying Apple $100/year?

My knee-jerk reaction to this is helllllllll no. But I guess we can see what @chughes297 thinks.

Why hell no? I need to confirm this but I assume RCVRC can cover those costs, especially if it makes install that much easier.

Also, I'm happy to test the bins for Linux and Windows if you can point me to where they are.

We're now creating a ton of packages: the launchable binaries (jpackage), the java runtime image (jlinkZip), SHAs for each, x3 platforms --> the packages are around 350mb. When a release is created, this won't be an issue since people can just download the relevant file, but we should consider whether we want to support the jlinkZip image indefinitely, or if the jpackage will supercede it

Yeah, I think jpackage will replace jlinkZip. However, we should discuss the ramifications of this with @chughes297 to make sure it doesn't cause any additional security issues having them use a compiled version. Also wondering if we need to provide SHA512 checksums for the bins too.

I need a bit more info about what is being discussed - not sure I understand what the potential security issues are if using a compiled version? And yes I believe we'll need to continue providing checksums for each release (if that's what's being asked lol).

[HEdingfield]

@chughes297: Why hell no? I need to confirm this but I assume RCVRC can cover those costs, especially if it makes install that much easier.

I guess because I'm allergic to costs associated with open source software (especially recurring ones) but, more importantly, I thought all the election tabulation stations ran Windows anyway?

@chughes297: I need a bit more info about what is being discussed - not sure I understand what the potential security issues are if using a compiled version? And yes I believe we'll need to continue providing checksums for each release (if that's what's being asked lol).

I guess I was thinking because it's just an extra level of opacity, which probably also creates a registry entry on their machine (correct me if I'm wrong, @artoonie).

[artoonie]

Curious why we're merging this into master instead of develop? Just so we can test it out sooner?

This depended on the hotfix/auto-release branch, and when that was merged into master, github automatically redirected this PR to point at master. Now that that branch is merged into develop, I've updated this PR to also point at develop.

Also, I'm happy to test the bins for Linux and Windows if you can point me to where they are.

https://github.com/BrightSpots/rcv/actions/runs/4801866529

The version number is now in three different places. We need an easy way to sync this across the project, but I couldn't find a straightforward way yet. We'll need a ticket to track this.

We should be able to get rid of it in release.yml, right, defaulting to the GitHub tag variable instead? Looks like there are some merge conflicts to resolve with release.yml anyway.

Not anymore -- the version number generated by jpackage is based on the version number in build.gradle, which can differ from the tag or ref_name. I tried this solution, but it doesn't work for development builds, so I'll need to find another solution that works in all cases.

I guess I was thinking because it's just an extra level of opacity, which probably also creates a registry entry on their machine (correct me if I'm wrong, @artoonie).

Yes, that is true -- when installing the software, you cede some control to the operating system which could be seen as reducing transparency. For example: If you try installing 1.3.0 but you previously had 1.4.0 installed, will your operating system decline to downgrade, but show you that it succeeded? The answer is No today, but that's the type of thing we lose control over.

(This may not be the best example of what can go wrong, but it's the only thing I can think of right now.)

However, assuming other election software follows the same model (which I expect they do), I think we can feel safe following the same best practices?

[chughes297]

@chughes297: Why hell no? I need to confirm this but I assume RCVRC can cover those costs, especially if it makes install that much easier.

I guess because I'm allergic to costs associated with open source software (especially recurring ones) but, more importantly, I thought all the election tabulation stations ran Windows anyway?

Most do. So far in my experience, though, some offices have a Linux machine handy and others may have a Mac workstation they can use. I lean towards being as comprehensive as possible with OSes so we can be flexible and jurisdictions can ideally use a piece of hardware they already have sitting around instead of having to buy a new one.

I guess I was thinking because it's just an extra level of opacity, which probably also creates a registry entry on their machine (correct me if I'm wrong, @artoonie).

Yes, that is true -- when installing the software, you cede some control to the operating system which could be seen as reducing transparency. For example: If you try installing 1.3.0 but you previously had 1.4.0 installed, will your operating system decline to downgrade, but show you that it succeeded? The answer is No today, but that's the type of thing we lose control over.

(This may not be the best example of what can go wrong, but it's the only thing I can think of right now.)

However, assuming other election software follows the same model (which I expect they do), I think we can feel safe following the same best practices?

I'm curious to hear more about the security/opacity argument (maybe easier to talk out on the phone?). And I would need to ask vendors what their standard practice is but I imagine it is similar to what Armin described.

[artoonie]

@HEdingfield this is ready for review. I've tested on mac, windows, and linux, and the binaries all work. The mac version is signed to avoid warnings with the strictest operating systems -- it's "notarized" which, among other things, sends a hash Apple when building, and that hash is verified by the user's machine before opening.

[HEdingfield]

Some light changes for you here to review too, per our discussion.

[HEdingfield]

I assume it was 1.3.1 just for testing purposes? Can we set to 1.4.0 now?

[artoonie]

I'm a little afraid to set it to 1.4.0 prematurely, as we'd have fake but signed 1.4.0 versions floating around. I guess the same is true with 1.3.1?

The issue stems from the fact that Mac won't allow a bundle to have a -alpha at the end, so we need some way of signifying a fake/development version number. See: https://stackoverflow.com/questions/70066384/javafx-gradle-jlink-plugin-jpackageimage-fails-because-of-1-0-snapshot-conta

Perhaps we should use 0.0.0 unless we are building a release? Or maybe this just isn't a real issue, and we're okay having "false" 1.4.0s around?

[HEdingfield]

Dumb Apple. That may be a blessing in disguise in a small way, though, because we don't want to be creating these builds / releasing alpha versions. I'd say we set it to 1.4.0-alpha here now so the find-replace is easier later (plus I guess it'll block building).

[HEdingfield]

Fantastic job! This would have taken me forever to get going.