Navigation

News

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: - https://ngi.eu/ngi-interviews/interview-with-morgan/

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:

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:

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.