Release proxy 0.3.0 client 0.2.0

[sssoleileraaa]

Description

Add debian package tarballs and changelogs for securedrop-proxy 0.3.0 and securedrop-client 0.2.0

Test plan

• Debian changelog is properly updated
• Tag in securedrop-client is correct
• Tag properly checked out and checksum for securedrop-proxy 0.3.0 pacakge matches what's here in the build log: freedomofpress/build-logs@cfa3647
• Tag properly checked out and checksum for securedrop-client 0.2.0 pacakge matches what's here in the build log: freedomofpress/build-logs@c8c8568

TODO

I don't have release signing privileges so @emkll will do the following:

• Tarball is signed
• Old tarball and sig is removed

[sssoleileraaa]

For the first deb package build, I forgot to record the build logs so I did it again as you can see in the build logs. The only thing I was unable to do was force-push the new packages to keep the commit history clean (seems to be blocked). I will just add two new commits with the second tarballs so that you can verify the checksums and logs.

[emkll]

Thanks @creviera this looks good. For the sake of consistency, what do you think about submitting the first tarball? The reason is that building the deb package comes at a later phase (it requires this PR to be merged into master.

I think it would be best to use the tarballs from the first step (python3 setup.py sdist). Per [1], for each package:

1. git tag -v
2. git checkout tag
3. python3 setup.py sdist
4. sha256sum dist/securedrop-something.tar.gz

You can find an example of a previous production build #162

I've updated the release management docs to provide a description of this procedure, since the instructions were absent

[sssoleileraaa]

Yeah, that works too! The tarballs in this PR are already from the first build. If you look at the log output you'll see that I did:

user@deb-packaging-buster:~/code/securedrop-debian-packaging$ cd ../securedrop-proxy/
user@deb-packaging-buster:~/code/securedrop-proxy$ git checkout 0.3.0
HEAD is now at 200c194 securedrop-proxy 0.3.0
user@deb-packaging-buster:~/code/securedrop-proxy$ python3 setup.py sdist
user@deb-packaging-buster:~/code/securedrop-proxy$ cd ../securedrop-debian-packaging/
user@deb-packaging-buster:~/code/securedrop-debian-packaging$ PKG_VERSION=0.3.0 PKG_PATH=/home/user/code/securedrop-proxy/dist/securedrop-proxy-0.3.0.tar.gz make securedrop-proxy

(I did the same for securedrop-client but checked out the tag 0.2.0)

The only thing I think I still need to provide is the shasum for the first taballs for securedrop-proxy and securedrop-client since the shasums in the build logs are for the second run, correct?

[sssoleileraaa]

oh i see! i need to git tag -v 0.3.0 to show the signature

[emkll]

The only thing I think I still need to provide is the shasum for the first taballs for securedrop-proxy and securedrop-client since the shasums in the build logs are for the second run, correct?

Correct, what needs to be uploaded (and verified) as part of this PR is the sdist tarball (the first tarball in the whole process). We want to make sure that the one you built corresponds to the one submitted in the PR

[sssoleileraaa]

it would be cleaner if i push the second tarballs because that is what i have the shasum for in the build logs and also what i currently have in my dist and tarball directory

[sssoleileraaa]

You can now confirm that the shasums in https://github.com/freedomofpress/build-logs/compare/securedrop-proxy_0.3.0-securdrop-client_0.2.0 match what's in the tarballs directory. I also added logs to show tag signatures for client and proxy.

[emkll]

Thanks @creviera looks good to me!

I've added two commits

1. Remove previous version tarballs
2. Added detached sigs for tarballs

Since I've pushed some commits to your branch, could you please take a look and merge if all looks good to you?

[sssoleileraaa]

I see, so when we publish a new tarball, we want to remove the old tarballs from previous deploys? And I see that you added your signature to the tarballs (which you had to do instead of me for security reasons).

[emkll]

I see, so when we publish a new tarball, we want to remove the old tarballs from previous deploys?

Exactly, that's the process we've been following so far, for example in #162.