Create versions and changelogs for Snowflake pieces

This is a prerequisite for packaging Snowflake for Debian (#19409 (moved)).

We already have versions for the snowflake browser proxy. It could make sense to version different pieces of snowflake (client, browser proxy, proxy-go) separately since these pieces are largely distinct. That would be more work though. I'm ok with having one version/changelog for all the pieces and then just bumping the version number whenever it's convenient.

Trac:
Parent Ticket: #19409 (moved)

added component::circumvention/snowflake parent::19409 priority::medium resolution::fixed severity::normal status::closed type::task labels

We discussed in the anti-censorship meeting today how to handle this. My proposal for this would be to:

1. split up the Snowflake mono repo into two repositories: one for the browser-based Snowflake proxy code (written in JavaScript), and one for the main Go Snowflake components (client, server, proxy-go, and broker code)

2. Each of these repos have a repo-wide version. So we'll keep doing webextension versioning as before (though maybe remove the webext prefix since it applies to the badge as well), and then have a version for all Go Snowflake components (this ties in with the recent move to Go modules in #33330 (moved) as well).

Full meeting logs are available here: http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-03-12-17.59.html

Trac:
Status: new to needs_review

My proposal for this would be to

Seems ok to me if others are on board. As mentioned in the logs, it's important to me to maintain the git history.

Replying to arlolra:

My proposal for this would be to

Seems ok to me if others are on board. As mentioned in the logs, it's important to me to maintain the git history.

Agreed on the proposal and on the importance of preserving our git history!

Okay here's a test-run of how this could look. I ran the following commands from the snowflake repository root:

$ git subtree split -P proxy proxy-only $ mkdir ../snowflake-webext $ cd ../snowflake-webext $ git init $ git pull ../snowflake proxy-only

This split out the proxy subdirectory into it's own repo, which you can see here: https://github.com/cohosh/snowflake-webext

I had to do a couple fixes to get submodules working: https://github.com/cohosh/snowflake-webext/commit/70f32b18afb48e97d7a3794f952fb6dbcc7ce690

And then transferring the tags was tricky because this command changes the commit hashes. I did this manually and then pushed all the tags to the remote using git push <remote> --tags.

The original snowflake repository keeps all the commit history and all the old tags. I cleaned it up a bit in this branch: https://github.com/cohosh/snowflake/tree/ticket/33593 The changes I made were to:

• Remove the translation submodule
• Remove the proxy/ subdirectory
• Remove web proxy instructions from README.md
• tagged snowflake as v1.0.0

If everyone is okay with this plan we can create a new snowflake-webext repository on gitweb.tp.o and then once that's up and running, merge this branch to master on the main snowflake repository.

And then transferring the tags was tricky because this command changes the commit hashes.

Since the current tags are more relevant to the webext repo, it might be more worth trying to preserve them there.

An alternative approach might just be to fork the repo and make commits removing the code that's no longer relevant as you did for the main repo.

Remove the proxy/ subdirectory

Probably also want to rename proxy-go to proxy

Replying to arlolra:

And then transferring the tags was tricky because this command changes the commit hashes.

Since the current tags are more relevant to the webext repo, it might be more worth trying to preserve them there.

An alternative approach might just be to fork the repo and make commits removing the code that's no longer relevant as you did for the main repo.

By "preserve", do you mean keep the same mapping with git hashes, or have the tags refer to the same commits? Because this setup currently does the latter.

By "preserve", do you mean keep the same mapping with git hashes, or have the tags refer to the same commits? Because this setup currently does the latter.

The former

Replying to arlolra:

An alternative approach might just be to fork the repo and make commits removing the code that's no longer relevant as you did for the main repo.

I too would slightly prefer a fork-and-delete that preserves commit hashes over a git subtree split or git filter-branch --subdirectory-filter that rewrites commit hashes.

Okay, let's do a full fork, that's pretty easy to accomplish. I'll make the appropriate ticket with the sysadmin team.

Made #33740 (moved)

Thanks to irl, we now have a new repository just for the web extension: https://gitweb.torproject.org/snowflake-webext.git/

Here are some pull requests to tidy up each of the respositories:

• for the main snowflake Go repo: https://github.com/cohosh/snowflake/pull/26
• for the new webext repo:https://github.com/cohosh/snowflake-webext/pull/1

(I didn't make any GitHub mirrors, if those would be useful please do make some tickets)

Replying to cohosh:

Thanks to irl, we now have a new repository just for the web extension: https://gitweb.torproject.org/snowflake-webext.git/

I assumed this was going to nest under pluggable-transports/ also but I guess it's no big deal.

Here are some pull requests to tidy up each of the respositories:

• for the main snowflake Go repo: https://github.com/cohosh/snowflake/pull/26
• for the new webext repo: https://github.com/cohosh/snowflake-webext/pull/1

The pulls seem fine. I left comments about some trivial things that were missed.

Replying to arlolra:

Replying to cohosh: I assumed this was going to nest under pluggable-transports/ also but I guess it's no big deal.

I could move it quickly now before anyone bookmarks links to it, let me know.

Replying to irl:

Replying to arlolra:

Replying to cohosh: I assumed this was going to nest under pluggable-transports/ also but I guess it's no big deal.

I could move it quickly now before anyone bookmarks links to it, let me know. Ah. I think since this is a stand-alone thing and doesn't have any PT code (there's no client or server interactions with the PT spec) that top-level is the best place.

I... don't have a strong opinion. Our meeting is in ~90 minutes, how about we discuss it there.

Sorry irl for the confusion.

No problem, just highlight me in IRC if you want it changed. I'll do it after dinner.

Replying to irl:

No problem, just highlight me in IRC if you want it changed. I'll do it after dinner. Okay we've decided to move it to pluggable-transports/. Thanks again for handling this.

Done. (The old repo will disappear from gitweb shortly).

Replying to arlolra:

The pulls seem fine. I left comments about some trivial things that were missed.

Thanks! Made these changes. I'll just wait for an ok from someone before merging. And then we can move forward with the two separate repos.

I also noticed our documentation is outdated now: https://trac.torproject.org/projects/tor/wiki/doc/Snowflake#HowtorunaSnowflakeproxy

We can use this ticket to track those changes after the merge.

I'll just wait for an ok from someone before merging.

lgtm

Trac:
Status: needs_review to merge_ready

Merged! We now have two snowflake repos :D

Replying to cohosh:

I also noticed our documentation is outdated now: https://trac.torproject.org/projects/tor/wiki/doc/Snowflake#HowtorunaSnowflakeproxy

We can use this ticket to track those changes after the merge.

Okay there weren't many edits necessary: https://trac.torproject.org/projects/tor/wiki/doc/Snowflake?action=diff&version=56

Is the only remaining task under this ticket to write changelogs for the two repos? As I understand it, that's a requirement of Debian packaging?

Trac:
Status: merge_ready to needs_information

Thanks for bringing this back up.

IMO, we are nowhere near being about to move forward on Debian packaging. We have too many dependencies that are changing very rapidly. I think we should wait and let snowflake development settle down a bit before trying.

So we can either start using changelogs or decide not to and close this ticket. I don't have strong opinions either way. I like the idea of having snowflake versions to track major changes but it's not high priority for me.

Okay, I'll just close the ticket.

Trac:
Resolution: N/A to fixed
Status: needs_information to closed

closed

mentioned in issue #33740 (moved)

moved to tpo/anti-censorship/pluggable-transports/snowflake#33593 (closed)