Hello tor-project@,
this month I have done the following things for the Tor project.
# Onion Service Reliability
I performed research on the reliability of onion services in various
setup environments, including arti to arti, ctor to ctor and the two
ones being mixed together. These findings resulted in the conclusion
that the arti implementation is well-done and has a similar failure of
its ctor pedant, which is around 0.5% or 1 in every 200 connection being
a failure. Those failures are flaky circuits which probably happen due
to simply having bad luck while choosing the circuit. Nonetheless,
those results are acceptable.
Besides, this research has led to an improvement within the arti
documentation, namely the addition of a method named
`is_fully_reachable` which checks whether the `State` of a
`tor-hsservice` indicates that it is reachable from the outside. This
change was necessary because there are right now two states which
indicate that the service is reachable, with only one of them sounding
like a success.
After all, this research led to the creation of the following tickets
and merge requests in the arti repository:
* arti#1887
* arti#1890
* arti!2850
# GPN23
I have opened a ticket (outreach#40103) for Tor activities at the GPN23
in Karlsruhe this June. I will be present at the event myself and I am
open for giving a Tor related talk there too. This is however still
early planning.
# oniux
This month, I continued working on oniux, namely statically integrating
onionmasq into the oniux binary, so oniux users no longer need to
provide a path to the onionmasq binary themselves; instead oniux is now
a beautiful self-container monolithic binary.
Besides all of this, I also did some research regarding the use of
`user_namespaces(7)` in oniux with the eventual goal of oniux being
capable to no longer need any `capabilities(7)`. This change is
non-trivial and would probably require a rewrite of the tool in a shell
scripting language, as a network stack such as [pasta](https://passt.top)
would be required for proper functioning. Right now, this is not a
priority but a nice to have. Our current use of capabilities is
probably not a security risk, as all capabilities are being dropped very
early on and no code originating from a malicious actor is executed with
capabilities at all.
Also, I have made two release tags for oniux this month: v0.1.0 and
v0.2.0.
Last but not least I have fixed a bug, namely that procfs was not
remounted in the PID namespace created by oniux leading to an incorrect
view when performing process related operations such as `ps aux`.
After all, the following tickets have been addressed:
* oniux#1 (for now)
* oniux#2
* oniux#3
# onionmasq
This month I gave onionmasq more attention again, this mainly included
fixing various RenovateBot related updates and keeping this up-to-date
in general.
Besides this, I have performed some clean-ups and fixed some clippy
warnings that occurred during the development.
Also, as outlined in oniux, I have moved code a little bit around,
meaning it is now possible to integrate onionmasq as a library into
existing Rust application like I did with oniux.
Last but not least I performed some testing with the onionmasq CI in
order to hopefully make it possible to run the integration tests outside
of privileged containers, there has not been much success there though.
After all, my work cumulated in the following tickets/MR's:
* onionmasq#135
* onionmasq#136
* onionmasq#137
* onionmasq#138
* onionmasq!404
* onionmasq!403
* onionmasq!401 (WIP)
* onionmasq!400
* onionmasq!398
* onionmasq!397 (WIP)
* onionmasq!393
# arti
Besides the addition of the `is_fully_reachable` method, I also support
and supported gabi@ in the release of the new arti version.
ยทยทยท
_______________________________________________
tor-project mailing list -- tor-project@lists.torproject.org
To unsubscribe send an email to tor-project-leave@lists.torproject.org