guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#61789] ‘tor-hidden-service’ deprecation


From: Ludovic Courtès
Subject: [bug#61789] ‘tor-hidden-service’ deprecation
Date: Mon, 06 Mar 2023 17:05:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

HI,

Bruno Victal <mirai@makinata.eu> skribis:

> I think it's difficult to split this one into meaningful patches, reason 
> being that
> 'tor-hidden-service-type' can't be used alone since the record constructor 
> for a
> Tor hidden service (hidden-service, which is IMO a "collision prone" name) is 
> not exported.
>
> The fact that it isn't exported also means that the 'hidden-services field 
> from <tor-configuration>
> was impossible to configure. Extending 'tor-service-type' was also impossible 
> save for the
> (to be deprecated) 'tor-hidden-service' procedure which provisions a 
> 'tor-hidden-service-type'
> that is simply a service extension for 'tor-service-type'.
>
> The 'tor-hidden-service' and 'tor-hidden-service-type' are extremely 
> misleading to what will
> happen behind the scenes should more than one hidden-service be provisioned 
> (with 'tor-hidden-service').
> Since it does so via a 'tor-hidden-service-type' which has its own name, only 
> one of the hidden-services
> will get configured, which one = dice roll.
>
> IMO this 'tor-hidden-service-type' shouldn't exist at all and 
> tor-hidden-service can safely be
> converted into a simple-service that extends tor-service-type.

Hmm, can we still open a separate issue for it?  :-)

I can’t really make up my mind right now.  I think
‘tor-hidden-service-type’ brings a bit of clarity compared to
‘simple-service’, for instance when looking at ‘guix system
extension-graph’.

Then there’s the other issue that upstream calls this “onion services”
these days, so we should also change that.

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]