[bug#70341] [PATCH v3] services: tor: Add support for pluggable transports.

[Nigko Yerden]

Hi André,

Here is some additional information about the patched tor-service-type 
which reveals:
1) Why it can fail if not properly configured.
2) Its internal workings which I find kind of cool.

First, it is not necessary to use PT-plugin from ready-to-go Guix 
package. It is possible to download PT-plugin source code and compile it 
directly, say, somewhere in $HOME folder. The corresponding 
configuration may look like this

(service tor-service-type
    (config-file (plain-file "torrc" ".... Bridge obfs4 ..."))
    (transport-plugin
       (local-file "/home/..../lyrebird"
                   #:recursive? #t)))

But this will not necessary work. The reason why it can fail is somewhat 
interesting. As we know, the tor process, thanks to the 
'least-authority-wrapper', is run inside a container, which, in 
particular, means it has very limited view of the file system. But 
PT-plugin executable is linked dynamically by default and has its 
dependency libraries inaccessible from within the container. However, if 
PT-plugin is linked statically, the configuration above will work.

Similarly, if PT-plugin is specified as a direct string path to the 
store item like this

(transport-plugin "/gnu/store/..../bin/lyrebird")

it may not work for the same reason.


However, if a file-like object is used instead like this

(transport-plugin (file-append PT-PACKAGE "/bin/lyrebird"))

all the dependencies of PT-PACKAGE are added automatically to the list 
of allowed paths inside the container (this is provided by the call to
'references-file' from inside 'least-authority-wrapper' procedure). As 
for me this means that the suggested patch fits very well to the guix'y 
way of doing things.


Regards,
Nigko