You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently manually build and upload tarballs as part of the release process. Per this repo’s README:
Build tarballs, and create a detached signature with the release key
This involves two people at a minimum: one person to prepare the PR, and another to review it. As of #185, tarballs are reproducible. This means we can safely automate the creation of tarballs via a buildbot. The bot would open a PR (from a fork or branch) with the tarball artifact.
A person with signing authority would verify the build locally and push a commit with a detached signature, then merge it, reducing the number of people involved to 1.
This issue should be considered blocked on #147 to prevent accidental merges of unsigned artifacts by a reviewer.
In scope of this issue
Investigate implementation options for a buildbot that opens PRs (cf. previous efforts such as @redshiftzero's backport bot)
Implement a buildbot that creates tarballs and opens PRs into this repo as soon as a release tag is pushed to a SecureDrop Workstation project repo.
Update the procedures in this repo’s README
The text was updated successfully, but these errors were encountered:
Depending on the implementation strategy, this issue may result in changes in other repos. It may also be worth considering the benefits of tooling beyond our primary toolchain; e.g., does Codefresh give us options here that CircleCI does not?
We discussed this further in today's tech meeting. I'm provisionally closing this issue in favor of a clearer focus on going straight for an experimental reproducible & automated .deb build. The main rationale is that the team is leaning towards removing the tarballs/ directory from this repo. #185 added tooling for significantly simplifying the tarball build step, so the benefit to ourselves of keeping the tarballs around is very limited, while the benefit for third parties (e.g., researchers) also seems limited, given that there are other ways to obtain a specific version of a package, such as the GitHub auto-generated tarballs: https://github.com/freedomofpress/securedrop-client/tags
If we decide that we want to preserve the tarballs/ step, we can reopen.
We currently manually build and upload tarballs as part of the release process. Per this repo’s README:
This involves two people at a minimum: one person to prepare the PR, and another to review it. As of #185, tarballs are reproducible. This means we can safely automate the creation of tarballs via a buildbot. The bot would open a PR (from a fork or branch) with the tarball artifact.
A person with signing authority would verify the build locally and push a commit with a detached signature, then merge it, reducing the number of people involved to 1.
This issue should be considered blocked on #147 to prevent accidental merges of unsigned artifacts by a reviewer.
In scope of this issue
The text was updated successfully, but these errors were encountered: