Create aggregated PGP signature files

[DireWolfM14]

I have noticed several users claiming they are unable to verify GPG signatures in recent months. Most have been solved by changing the file name of the signature file to match that of the binary file in question. This began recently when the development team started issuing signature files by multiple developers, and adding the developer's name to the signature file name.

Just to reiterate the issue; the signature files' names differ from the binary file's name, which prevents GIU GPG applications (with default settings) from reading the binary file when one double-clicks on a signature file. GUI applications expect the signature file's name to be the same as the binary file's name, with the only difference being the addition of .asc extension.

For example;
Binary file name: electrum-4.1.5.dmg
Signature file name: electrum-4.1.5.dmg.asc

Currently if you download the binary and the signature files you'll have the following file names:
The binary file name: electrum-4.1.5.dmg
ThomasV's signature file name: electrum-4.1.5.dmg.ThomasV.asc
SomberNight's signature file name: electrum-4.1.5.dmg.sombernight_releasekey.asc
Emzy's signature file name: electrum-4.1.5.dmg.Emzy.asc

This issue can be resolved by adding all the developers' signatures into one file, please see the attached example. This is common with other packages that issue multiple developers' signatures for binary releases.
electrum-4.1.5.dmg.asc.txt

[SomberNight]

Thanks for the suggestion, I had not realised we could put all sigs into a single file. Indeed this seems to have better UX for GUI users.

[ecdsa]

I started to work on that. Here is how I propose to change the current workflow

Current workflow

• ThomasV uploads his binaries and signatures to the airlock.
• ThomasV pushes a new version of electrum-web to Github
• SomberNight downloads files from the airlock
• SomberNight uploads his file signatures to the airlock, as well as his signature for electrum-web
• deploy.sh checks both electrum-web signatures
• deploy.sh downloads files from the airlock, checks file signatures, deploys the website.
• when adding a new cosigner:
  • ThomasV pushes a new electrum-web commit, and signs it
  • SomberNight signs it
  • deploy.sh checks signatures, fetches electrum-web. Other files are unchanged.

proposal

Note that the current deploy.sh logic will not download files from the airlock unless there is a new version number.
In order to have aggregated signature files, we have to either change that, or to let deploy.sh build the aggregated signature files.

I propose to keep the current logic. Indeed, the purpose of the airlock is to examine potentially toxic data (binary files, html files), before deployment. However, signature files are not toxic. So, I think we do not need to push binary signature files into the airlock. The deploy.sh script can fetch them from Github.

This has several advantages:

• everybody uploads their signatures to the same place (the electrum-signatures repo).
• deploy.sh will not need to examine the content of the airlock when we add a new cosigner. (just like now)

New workflow

• ThomasV upload his binary signatures to Github
• ThomasV uploads binaries and his electrum-web signature to the airlock.
• ThomasV pushes a new electrum-web commit to github
• SomberNight downloads files from airlock
• SomberNight pushes his binary signatures to github
• SomberNight pushes his electrum-web signature to the airlock
• deploy.sh checks both electrum-web signatures
• deploy.sh download files from airlock and signatures from Github, verifies them, creates aggregated signature files.
• when adding a cosigner:
  • ThomasV pushes a new version of electrum-web, with a new cosigner
  • ThomasV pushes his signature for electrum-web to the airlock
  • SomberNight pushes his signature for electrum-web to the airlock
  • deploy.sh checks both electrum-web signatures
  • deploy.sh downloads binary signatures from Github, verifies them, creates aggregated signature file.

[SomberNight]

New workflow: [...]

Sounds good.

Two remarks:

• Note that if we have a reproducibility issue when doing the release, e.g. SomberNight cannot reproduce a binary ThomasV built, by the time we notice, ThomasV's sigs are already committed to the spesmilo/electrum-signatures public git repo. Historically we have restarted the release process on a few occasions due to such issues - usually involving pushing new commits to spesmilo/electrum and force-pushing the git tag (and rebuilding binaries for the new tag). We could in such cases either also force-push the master branch of spesmilo/electrum-signatures or just push a new commit on top replacing the sigs. I would prefer not to force-push the branch. (In the current workflow we would just replace the files in the airlock)
• Unaffected by this change, but just wanted to highlight that if github was unaccessible, we would be unable to do a new release using deploy.sh. (so moving all sig files from our webserver to github does not introduce a new constraint in this sense - as the website git repo is hosted on github and deploy.sh already starts by fetching that)

[ecdsa]

Thanks for reviewing. I did not think about reproducibility issues. I'll try to find a better solution.

[ecdsa]

OK, I came up with a different solution, closer to what we currently do, and robust against reproducibility issues.

See spesmilo/electrum-web@969fa0a and bdbd593

A new script contrib/add_cosigner fetches signatures from a cosigner.
make_download checks how many cosigners there are.
The cosigner signatures must be pushed into the airlock.

The early return in deploy.sh is now based on the commit number, not the version number. If the commit is signed by both ThomasV and SomberNight, the airlock content is downloaded again.

[ecdsa]

this is deployed now