News
2026-04-13 - New Release: tor-interface 0.6.7
Published new version of the tor-interface crate to crates.io based on commit 11df30efb536b06f055b8ecc4efbf756543f04e8.
The major changes since tor-interface 0.6.6 follow:
- tor-interface
- X25519PrivateKey no longer needs to check for clamping; version 2.0.1 of the x25519-dalek crate no longer clamsp on construction
2026-04-13 - New Release: tor-interface 0.6.6
Published new version of the tor-interface crate to crates.io based on commit cfa60b8b1251b8bc3cd5df7d92f8112014dcc0af.
The major changes since tor-interface 0.6.5 follow:
- tor-interface
- fix typo in X25519PrivateKey::from_raw() which prevented key round-tripping
2026-04-07 - New Release: tor-interface 0.6.5
Published new version of the tor-interface crate to crates.io based on commit b3a7336cc1458e7d29e68e29f58b7f1467a183e3.
The major changes since tor-interface 0.6.4 follow:
- tor-interface
- implement/derive Eq, Ord, PartialEq, and PartialOrd for public key types
2026-02-23 - New Release: tor-interface 0.6.4, gosling 0.5.3, and cgosling 0.5.3
Published new versions of the tor-interface and gosling crates to crates.io based on commit bd11d540c8a44faaca308fc6b08c6f889d901e32.
The major changes since tor-interface 0.63, gosling 0.5.2, and cgosling 0.5.2 follow:
- tor-interface
- implement pass-through getters for TargetAddr
- derive PartialEq BridgeLine and ProxyConfig types
- implement ToString trait for BridgeLine
- add getters to ProxyConfig types
2026-02-18 - New Release: tor-interface 0.6.3
Published new version of the tor-interface crate to crates.io based on commit acfcefb61c7812f254631454edff0fb24b1afcaf.
The major changes since tor-interface 0.6.2 follow:
- tor-interface
- implemented TryFrom<String,u16> for TargetAddr
2025-11-13 - New Release: tor-interface 0.6.2, gosling 0.5.2, cgosling 0.5.2
Today, we published new versions of the tor-interface and gosling crates to crates.io based on commit e7be9bd5739f63d7fe362c7449812996b7dba9c1.
The major changes since tor-interface 0.6.1, gosling 0.5.1, and cgosling 0.5.1 follow:
- tor-interface
- fix bug in LegacyTorClient when setting up pluggable-transports
2025-11-08 - New Release: tor-interface 0.6.1, gosling 0.5.1, cgosling 0.5.1
Today, we published new versions of the tor-interface and gosling crates to crates.io based on commit 34e4063f398ed6eb97bb84ca0cea09b9b115f47f.
The major changes since tor-interface 0.6.0, gosling 0.5.0, and cgosling 0.5.0 follow:
- tor-interface
- fix bug in LegacyTorClient SETCONF ReachableAddresses call
- fix bug in bridge line parsing
2025-10-03 - New Release: honk-rpc 0.3.1, tor-interface 0.6.0, gosling 0.5.0, cgosling 0.5.0
We have published new versions of the honk-rpc, tor-interface, and gosling crates to crates.io based on commit aff524511ced4bc7b6aa6268a23e6ddbf4c16931.
The major changes since honk-rpc 0.3.0, tor-interface 0.5.0, gosling 0.4.0, and cgosling 0.4.0 follow:
- honk-rpc
- fix clippy and formatting errors
- tor-interface
- initial incomplete arti TorProvider implementation
- updated arti-csliient crate (and dependencies) to 0.33.0
- implement SAFECOOKIE and NULL authorisation for LegacyTorClient
- implement LegacyTorClientConfig::try_from_environment() function to read tor settings from environment variables
- add connect_async() function to TorPrvider trait and implement for all implementations
- make Ed25519PrivateKey::from_key_blob_legacy() function public
- gosling
- fix clippy and formatting errors
- cgosling
- fix clippy and formatting errors
2024-11-17 - New Release: tor-interface 0.5.0, gosling 0.4.0, and cgosling 0.4.0
by morgan
Yesterday, we published new versions of the tor-interface and gosling crates to crates.io based on commit 1b37699c6edaca4fd2e838f16fa565ed33d09367.
The major changes since tor-interface 0.4.0, gosling 0.3.1, and cgosling 0.3.1 follow:
- tor-interface
- updated arti-client crate (and dependencies) to 0.24.0
- implemented add_client_auth() and remove_client_auth() methods for ArtiClientTorClient TorProvider
- improved test reliability
- gosling
- add support for in-process ArtiClientTorClient TorProvider
- cgosling
- improved API documentation
- enable link-time optimisation for all targets when supported
- callbacks now pass through user-supplied arbitrary pointer
- add support for arti-client based gosling_tor_provider
2024-11-12 - Second Security Review by Radically Open Security Completed!
by morgan
Gosling has undergone a second security review by Radically Open Security. One actionable issue in cgosling’s Java bindings was found and has since been resolved.
The full report can be found on our security reviews page.
2024-09-24 - NGI Assure interview posted
by morgan
One of Blueprint for Free Speech’s funders is NLnet, who have funded development work for both Gosling and Ricochet-Refresh. A few months back, they sent out a questionnaire to various NLnet-funded projects. My answers seem to have been posted a few weeks ago! It’s a fairly short read, so please go take a look! It should give some insight into why we do the work we do, and how we think about software and user security+privacy:
2024-07-06 - New minor features and configuration options
by richard
The work for the past month or so has been focused on implementing various features unrelated to the Gosling protocol itself.
We anticipate developers of gosling-using applications may also want
to connect to other third party domains or onion services. To mitigate
anonymity and linkability concerns, we have introduced a
connect function on the gosling and cgosling interfaces.
This will allow developers to connect to domains anonymously through the
packaged tor daemon. Some use cases may be for anonymous update pings or
for accessing 3rd party services.
Users or application packagers are also very likely going to want to
have the option to use a system tor daemon for their gosling-using
applications (rather than launching and managing their own tor
instance). To enable this, we have generalised the idea of building a
gosling_tor_provider by instead building a
gosling_tor_provider_config, and then generating a
gosling_tor_provider through that config.
This change in API surface means we won’t need to worry as much about API breakage if we want to add additional configuration options to an existing tor provider type. The now currently supported config types are:
- bundled legacy tor daemon: the previous default, and how Ricochet-Refresh, Tor Browser, and brave package and manage tor; these applications launch, configure and exclusively owned a tor instance.
- system legacy to daemon: a new option which allows users to connect to and manage an existing system-wide tor daemon, provided they know the control-port password; this configuration is necessary for systems such as Tails
- mock tor client: this provides a fake in-process tor network to use for testing
Finally, users need the ability to set various configuration options to use tor or bypass censorship. The bundled legacy tor daemon configuration now has options for the proxy, open firewall ports, pluggable transports, and bridges.
2024-05-25 -
Initial arti-client integration
by richard
Arti is the Tor Project’s pure-Rust tor implementation. This effort has been on-going for a few years, but it has not been until relatively recently that we could begin the work of adding Arti support to Gosling.
The first part of this work actually happened last summer with the implementation of the MockTorClient. This client implements the TorProvider trait using local sockets and testing the Gosling protocol easier and much more rigorous.
Once the entire stack was updated to use a generic TorProvider, implementing more became a much easier task. The ArtiClientTorClient integrates and wraps the same backend crates used by the Tor Project’s arti crate.
This tor implementation runs in the same process as Gosling itself, and there is no need for a SOCKS5 proxy or a control port controller. For now, this (and all of the implementations of TorProvider) are gated behind a Rust feature-flag. When building with CMAKE, these flags may be enabled using config options. See the root REAMDE for more details.
For now, this feature is not available for use in Gosling itself, due to arti’s missing implementation of client authentication. Client auth prevents tor clients from connecting to an onion service, unless they have a particular private key which allows them to decrypt the so-called ‘descriptor’ which contains required routing information. Client auth is used by Gosling’s endpoint servers as a security-in-depth feature to prevent DDOS in the event the onion service id leaks.
We expect client auth to be implemented upstream in the relatively near future. When it is available, we will do the remaining integration work in the tor-interface crate and plumbing through to cgosling’s C-FFI.
2024-03-27 - Some Cargo Annoyances
by richard
So in the previous post I mentioned using patchelf to set the SONAME attribute on the libcgosling.so shared library to facilitate proper debian packaging. I further mentioned this was due to an upstream cargo issue. Well, it turns out a similar issue exists for macOS binaries. Rather than playing whack-a-mole and manually fixing every single eventual build target, I took a step back and re-thought my approach and what could be done that would be most maintainable long term.
The end-result is this.
To summarise, rather than manually patching and generally futzing with build outputs, I am instead only building cgosling as a static lib, and then building a shared lib using each platforms C tooling. This way, we can lean on CMake to do the heavy lifting when it comes to platform-specific metadata, symbolic-links, naming, etc. Unfortunately there is no standard way using cmake to just build a shared library which exports all of a static libraries public symbols.
As a result, I’ve had to do some interesting engineering in
the cgosling crate using proc macros. Without going into too much
detail, we are now building two copies of the cgosling static library,
one for direct consumption by downstream projects, and another
_impl suffixed copy whose functions have also been renamed
to include an _impl suffix. Then, using our existing
code-generation pipeline, a cgosling shared library is written which
defines public functions with the names found in the generated header,
which simply pass-through all arguments to the _impl
versions. Hopefully the compilers will optimise away this
little overhead but if not I would be surprised if it is actually a big
deal.
This work has allowed me to pretty rapidly and confidently implement both an Homebrew Formula for macOS (and Linux) and a PKGBUILD script for msys2 Windows environments.
2024-02-28 - Debian Source Packages
by richard
This past week I’ve been diving into the wonderful world of debian packaging. Specifically, constructing a debian source package via CMake which can be used to build the cgosling library from source, and generate both binary and dev packages.
This exercise has been a bit difficult for a few reasons:
- I knew almost nothing about debian source packing at the start of this process.
- The current debian stable only has rustc version 1.63 in the apt repositories, which means I had to make some changes to remove the rustc 1.66 dependency.
- An upstream bug in cargo (rust-lang/cargo#5045 - Support soname for cdylibs) meant following the debian documentation results in deb packages with lintian errors.
This last issue proved to be the most time consuming. Essentially, the debian tools used to generate a binary package from a source package depend on the presence of the soname metadata field in the provided elf binaries to trigger a call to ldconfig on package installation. This ldconfig step essentially updates some data-store which tells the runtime linker what runtime libraries are available, as well as their versions. However, the rust toolchain does not set this metadata field for cdylib targets like it should. This resulted in libraries which the debian tools did not realise were libraries
To work around this, I have added a patchelf step which updates this soname field manually for Linux builds. I have also renamed the Linux shared-library target to include full semantic version at the end (libcgosling.so.0.2.1) and added symlinks to this library in the standard format (libcsogling.so and libcgosling.so.0) to play nicely in actual deployments.
As part of this, I have also moved the crate’s semantic version definition out of its Cargo.toml file, and instead into the CMake part of the build-system. This way, we can generate all the various files (Cargo.toml, debian/control, debian/rules, etc) which need the semantic and major versions.
With commit 5ae906c, we are now able to build debian source packages, and end-users can build binary and dev packages. This is the first step in eventually getting cgosling into debian. Hopefully it will be all the easier by having a properly formatted (with no lintian errors!) source package to start from.
2024-02-01 - FOSDEM!
by richard
The Blueprint for Free Speech’s Gosling and Ricochet Refresh team is going to Brussels to attend one of the world’s largest free software events – FOSDEM 2024
We’ll be sharing our progress on Gosling and Ricochet Refresh, as well as exploring what the rest of the community is busy building.
Drop by if you can to FOSDEM - it’s free!
2023-07-04 - No news is good news!
by richard
Nothing to report here.