build for Android and add binary .deb files to test repo

[eighthave]

This creates the first, complete builds of snowflake for Android in the form of a shared library that can be integrated into https://github.com/guardianproject/AndroidPluggableTransports (https://github.com/guardianproject/AndroidPluggableTransports/issues/9). It builds using the libwebrtc-android-arm-magic.a binary that is included in https://github.com/keroserene/go-webrtc.

This requires https://github.com/keroserene/go-webrtc/pull/90 to be merged in order for the Android stuff to work.

This also adds ./build-deb to build a really simple binary .deb package for easy testing. Then via GitLab CI, it adds an apt source that can be added to Debian/stretch, Ubuntu/bionic, or newer to get the binary debs. The apt repo is based on GitLab Pages, and automatically available on forks on gitlab. For example, once this is merged into the official repo on git.torproject.org, there will be a repo here:

• https://torproject.gitlab.io/snowflake/

You can see my fork's repo here:

• https://eighthave.gitlab.io/snowflake/

The GitLab-CI builds for all this can be seen here: https://gitlab.com/eighthave/snowflake/pipelines/37667955

@n8fr8 @uniqx @arlolra @keroserene

[eighthave]

The TravisCI build failure was inherited from @arlolra's last two commits. It seems there is some incompatibility with Go 1.8.x. The GitLab CI jobs don't have this, they are running Go 1.11 and 1.10.

[eighthave]

@infinity0 since you worked on making this all work on Debian in the past, perhaps you might be interested in this.

[arlolra]

Snowflake development generally happens on Tor's trac these days, with gitweb.torproject.org/pluggable-transports/snowflake.git now being the canonical repo, but we can get this merged here.

[infinity0]

This won't be able to enter Debian until Google's C++ webrtc library can be built as a public shared library ("component_build=on" in their terminology). We cannot distribute binary blobs like this.

I see there was some progress in go-webrtc as well as some progress in webrtc itself, but don't have the time to examine the situation to see what work is still left to do for Debian.

edit: clarify that there is most likely still a bunch of work remaining, based on what I read about the above issues.

[uumaro]

Snowflake development generally happens on Tor's trac these days, with gitweb.torproject.org/pluggable-transports/snowflake.git now being the canonical repo, but we can get this merged here.

Right, personally I would prefer to handle Snowflake issues (as opposed to go-webrtc ones) on Tor Trac.

Related to that, the patch refers to both github.com/keroserene/snowflake and git.torproject.org/pluggable-transports/snowflake.git. The former isn't used anymore. If there are any projects the build depends on that still refer to github.com/keroserene/snowflake, we need to get them updated.

[uumaro]

What's the purpose of building deb packages? I'm confused because the ones in the patch contain client, broker, standalone proxy, WebSocket server, and the useful-only-for-debugging WebRTC server. Nobody needs all of these at once, other than developers; who is the anticipated user of the deb?

The gitlab-ci part of this seems fine to me, if that's convenient for your purposes for https://github.com/guardianproject/AndroidPluggableTransports.

[eighthave]

I put together the Debian packages and repo as an easy way to test without knowing Go. Of course, before it can be included in Debian, there needs to be a free build of libwebrtc. But building the source code is only one part of packaging and integrating with Debian. Other parts include figuring out which binaries should go into what packages, what config options should be included, what services should be registered with systemd, etc. All that work can be done in parallel with building from source, and indeed they require different skill sets. So providing binary packages for people to mess with means someone can start working on the integration stuff without needing to know anything about building Go or libwebrtc.

As for the anticipated users: "anyone who wants to easily mess with snowflake on Debian or Ubuntu". Guardian Project will be doing some integration work with PTs, and we'll be building a full working prototype of how orgs like Wikimedia can integrate into their setups.

Like @infinity0 said, all parts of snowflake need to be 100% free software and buildable from source on Debian builders to be included in Debian :smile: I'm not proposing these binaries are ready for inclusion in Debian.

[arlolra]

The TravisCI build failure was inherited from @arlolra's last two commits. It seems there is some incompatibility with Go 1.8.x.

Fixed at 596d28b

[eighthave]

I agree: the /debian/ folder should not be included in the source releases. It is not the end of the world if the source releases do have /debian/ in them. Debian has a process for repacking source packages as needed, but it can slow down maintenance a lot. Ideally, the debian packaging files would removed from this repo and just be maintained in the Debian source repo:

https://salsa.debian.org/pkg-privacy-team/snowflake

Anyone can make an account on salsa.debian.org and contribute there (forks, merge requests, issues, etc), just like gitlab.com.