Hi Everyone!It's been a minute since the last time I posted to this list about Gosling (December, 2021 what the actual heck: https://lists.torproject.org/pipermail/tor-dev/2021-December/014684.html ). Well, since then I have been quite busy leading the applications team and shipping browsers by day, and developing Ricochet-Refresh and Gosling by night!
To summarise, gosling is a Rust crate (and cgosling is a C-FFI library) which generalises and encapsulates all the hard parts of building peer-to-peer applications using tor, where a peer's long-term identity is an onion-service id. My vision and hope is that this allows for the creation new peer-to-peer applications with all of the various properties and guarantees of tor baked in, and that developers won't need to go spend some years becoming tor experts to do it correctly and safely.
The next version of Ricochet-Refresh will be using Gosling as its foundation, and so of course heavily informed Gosling's features and development direction.
The specific properties/features offered by Gosling: - long-term peer identity: an onion-service id - anonymous: it's onion-services and tor - secure: end-to-end encrypted from tor-client to tor-client because tor - nat-punching: more tor - censorship-circumvention: tor + pluggable-transports and bridges Ok and the novel/harder stuff:- authentication: cryptographically prove connecting clients control the private key of their claimed onion-service identity and their provided client-auth keys - customisable/application-specific handshakes: on top of the baseline cryptographic authentication, the 'add me as a peer' handshake also allows for an additional challenge+response requirement; imagine for instance a one-time code verification, password verification, socialist millionaire scheme, proof-of-work or stake, etc - metadata-resistant: the only metadata available to untrusted clients is your primary identity's onion-service's online/offline status; this onion-service is not required to be online to connect with trusted clients (unlike with other Ricochet-derived IM clients)
If any of this sounds exciting or useful to you, I'd love to invite you over to the project Github to take a look:
- https://github.com/blueprint-freespeech/goslingI'm hoping for Gosling to hit version 1.0.0 and lock-down/converge on a plausible stable API before the end of this year. The current API surface is very informed by my experience with what would be useful for Ricochet-Refresh, but I'm sure there are blind-spots here or improvements that could be made for other potential use-cases.
The goal from day one has been to make this code usable outside the Rust ecosystem. To that end, I've tried to make the C-FFI API design consistent, familiar and safe as possible, since it eventually will be used from Ricochet-Refresh's C++ codebase.
---The vast majority of the protocol work and initial implementation was completed around the beginning of 2023. So what have I been up to for the past couple years?
Basically, all of the 'boring' (quite exciting actually) software engineering work to get Gosling both usable and trustworthy. To be specific, I've been working on the following areas:
- code-cleanup: refactored Gosling into separate crates which may be individually useful:
- honk-rpc: the bson-based, json-rpc inspired RPC protocol- tor-interface: probably should have a better name, but this encapsulates the tor-daemon configuration and lifecycle, control-port communications, and connectivity
- gosling: the Rust protocol implementation - cgosling: gosling wrapped in a safe+friendly C-FFI- improved CMake project layout; cgosling should be relatively usable/integratable into existing CMake projects - build+test automation: build and run tests on github CI/CD Linux, macOS, and Windows runners, publish code-coverage, generated Rust documentation, doxygen C/C++ documentation
- fuzzing: fuzz the Rust crates including the C-FFI - identified and fixed a lot of bugs in the entire stack this year :D- language bindings: build a cbindgen -> c-header -> json idl pipeline for the cgosling crate; json idl used to automatically generate:
- C/C++ headers, static+shared libraries - python bindings to shared library - Java/JNI shared library and jar - packaging/deployment - published Rust crates to crates.io - deb-source package generation for debian-based Linux - homebrew flask formula generation for macOS - MSYS2 pkgbuild generation for Windows - some minor new features:- connect API to connect to non-gosling onion-services and clearnet targets using tor - use an already-running tor rather than running/configuring own tor process - configure bundled tor with all the familiar stuff: proxy, firewall, pluggable transports, and bridges - initial protoyping for in-proc arti-client backend (currently on version 0.18 so a bit behind)
The remaining planned work in this area before hopefully shifting my focus back on Ricochet-Refresh are a documentation pass on all my Rust crates, cleaning up/documenting the example projects, and completing a security audit. The Java and Python bindings could also use some love and automation.
--Anyway, I think that's enough technical non-sense for your inbox. If any of this sounds interesting, come check things out the project website ( https://gosling.technology/ ) which links to all the relevant stuff.
best, -richard
Attachment:
OpenPGP_0xDE47360363F34B2C.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev