all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "André Batista" <nandre@riseup.net>
To: Nigko Yerden <nigko.yerden@gmail.com>
Cc: 70332@debbugs.gnu.org, 70302@debbugs.gnu.org, 70341@debbugs.gnu.org
Subject: bug#70302: [bug#70341] [PATCH v3] services: tor: Add support for pluggable transports.
Date: Wed, 24 Apr 2024 18:11:10 -0300	[thread overview]
Message-ID: <Zil1buljj2AfL2zL@andel> (raw)
In-Reply-To: <3af678c4310a58373fe1e86b84f75a1d37e02295.1713758319.git.nigko.yerden@gmail.com>

Hi Nigko,

seg 22 abr 2024 às 08:58:39 (1713787119), nigko.yerden@gmail.com enviou:
> Pluggable transports are programs that disguise Tor traffic, which
> can be useful in case Tor is censored.  Pluggable transports
> cannot be configured by #:config-file file exclusively because Tor
> process is run via 'least-authority-wrapper' and cannot have access
> to transport plugin, which is a separate executable (Bug#70302,
> Bug#70332).

I can confirm that the tor service is unable to fork-exec a
pluggable-transport and the bootstrap process is halted at its start
when trying to use a system wide bridge + PT. However, this patch
does not seem to address the issue at hand, since it just creates
new tor-service-type configuration options that accomplish the
same as configuring on config-file directly. Have you had success
with this? I had no luck.

More comments bellow.

> * doc/guix.texi (Networking Services): Document 'transport-plugin' and
> 'pluggable-transport' options for 'tor-configuration'.
> * gnu/services/networking.scm: Export 'tor-configuration-transport-plugin-path',
> 'tor-configuration-pluggable-transport'.
> (<tor-configuration>): Add 'transport-plugin' and 'pluggable-transport'
> fields.
> (tor-configuration->torrc)[transport-plugin]: Add content to 'torrc'
> computed-file.
> (tor-shepherd-service)[transport-plugin]: Add file-system-mapping.
> 
> Change-Id: I64e7632729287ea0ab27818bb7322fddae43de48
> ---
>  doc/guix.texi               | 11 ++++++++
>  gnu/services/networking.scm | 54 ++++++++++++++++++++++++++-----------
>  2 files changed, 49 insertions(+), 16 deletions(-)
> 
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 65af136e61..eb0837860e 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -127,6 +127,7 @@
>  Copyright @copyright{} 2024 Herman Rimm@*
>  Copyright @copyright{} 2024 Matthew Trzcinski@*
>  Copyright @copyright{} 2024 Richard Sent@*
> +Copyright @copyright{} 2024 Nigko Yerden@*
>  
>  Permission is granted to copy, distribute and/or modify this document
>  under the terms of the GNU Free Documentation License, Version 1.3 or
> @@ -21849,6 +21850,16 @@ Networking Services
>  @file{/var/run/tor/control-sock}, which will be made writable by members of the
>  @code{tor} group.
>  
> +@item @code{transport-plugin} (default: @code{#f})
> +This must be either @code{#f} or a ``file-like'' object pointing to the
> +pluggable transport plugin executable.  In the latter case the
> +@code{#:config-file} file should contain line(s) configuring
> +one or more bridges.
> +
> +@item @code{pluggable-transport} (default: @code{"obfs4"})
> +A string that specifies the type of the pluggable transport in
> +case @code{#:transport-plugin} is not @code{#f}.
> +
>  @end table
>  @end deftp
>  
> diff --git a/gnu/services/networking.scm b/gnu/services/networking.scm
> index 8e64e529ab..6e535ea8ef 100644
> --- a/gnu/services/networking.scm
> +++ b/gnu/services/networking.scm
> @@ -22,6 +22,7 @@
>  ;;; Copyright © 2023 Declan Tsien <declantsien@riseup.net>
>  ;;; Copyright © 2023 Bruno Victal <mirai@makinata.eu>
>  ;;; Copyright © 2023 muradm <mail@muradm.net>
> +;;; Copyright © 2024 Nigko Yerden <nigko.yerden@gmail.com>
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -159,6 +160,8 @@ (define-module (gnu services networking)
>              tor-configuration-hidden-services
>              tor-configuration-socks-socket-type
>              tor-configuration-control-socket-path
> +            tor-configuration-transport-plugin-path
> +            tor-configuration-pluggable-transport
>              tor-onion-service-configuration
>              tor-onion-service-configuration?
>              tor-onion-service-configuration-name
> @@ -955,7 +958,11 @@ (define-record-type* <tor-configuration>
>    (socks-socket-type tor-configuration-socks-socket-type ; 'tcp or 'unix
>                       (default 'tcp))
>    (control-socket?  tor-configuration-control-socket-path
> -                    (default #f)))
> +                    (default #f))
> +  (transport-plugin tor-configuration-transport-plugin-path
> +                    (default #f))
> +  (pluggable-transport tor-configuration-pluggable-transport
> +                    (default "obfs4")))
>  
>  (define %tor-accounts
>    ;; User account and groups for Tor.
> @@ -988,7 +995,8 @@ (define-configuration/no-serialization tor-onion-service-configuration
>  (define (tor-configuration->torrc config)
>    "Return a 'torrc' file for CONFIG."
>    (match-record config <tor-configuration>
> -    (tor config-file hidden-services socks-socket-type control-socket?)
> +    (tor config-file hidden-services socks-socket-type control-socket?
> +         transport-plugin pluggable-transport)
>      (computed-file
>       "torrc"
>       (with-imported-modules '((guix build utils))
> @@ -1027,6 +1035,13 @@ (define (tor-configuration->torrc config)
>                                      (cons name mapping)))
>                                   hidden-services))
>  
> +               (when #$transport-plugin
> +                 (format port "\
> +UseBridges 1
> +ClientTransportPlugin ~a exec ~a~%"
> +                         #$pluggable-transport
> +                         #$transport-plugin))
> +
>                 (display "\
>  ### End of automatically generated lines.\n\n" port)

Even if it had succeded though, I'm not sure if this is the best
approach to it, since it would break guix system configuration, right?
How would one know beforehand which binary to point to? One would first
need to install the PT and look to its path on store and then link to
it in a new configuration. And then this link would have to be manualy
updated. Am I missing something here?

Finally, next time, try to keep the issue to a single thread. I'm
replying to #70332 and #70302 just for reference, but let's keep to
#70341 going forward.

Cheers!




  reply	other threads:[~2024-04-24 21:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-11 14:48 [bug#70341] [PATCH] gnu: Add support for pluggable transports to tor-service-type Nigko Yerden
2024-04-20 14:43 ` [bug#70341] [PATCH v2] services: tor: Add support for pluggable transports Nigko Yerden
2024-04-22  3:58 ` [bug#70341] [PATCH v3] " Nigko Yerden
2024-04-24 21:11   ` André Batista [this message]
2024-04-25  6:08     ` Nigko Yerden
2024-04-30  9:13       ` Nigko Yerden
2024-05-10  8:32 ` [bug#70341] [PATCH v4] " Nigko Yerden
2024-05-23 21:49   ` André Batista
2024-05-31  5:43 ` [bug#70341] [PATCH v5] " Nigko Yerden
2024-07-11 13:27 ` [bug#70341] [PATCH v6] " Nigko Yerden
2024-08-09  9:15 ` [bug#70341] [PATCH v7] " Nigko Yerden
2024-09-04 14:08   ` Ludovic Courtès
2024-09-17 13:11 ` [bug#70341] [PATCH v8] " Nigko Yerden
2024-10-06 17:39 ` [bug#70341] [PATCH v9] " Nigko Yerden
2024-10-14 11:41   ` bug#70341: " Ludovic Courtès
2024-10-14 16:36     ` [bug#70341] " Nigko Yerden
2024-10-15  6:26     ` Nigko Yerden
2024-10-15 15:43       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Zil1buljj2AfL2zL@andel \
    --to=nandre@riseup.net \
    --cc=70302@debbugs.gnu.org \
    --cc=70332@debbugs.gnu.org \
    --cc=70341@debbugs.gnu.org \
    --cc=nigko.yerden@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.