Re: Removal of GNUNET_CONFIGURATION_default() in 0.23

[Martin Schanzenbach]

To say it a bit more bluntly: Using the GNUnet configuration as your
own application's configuration was never a good idea.
After all, none of the paths actually belong to your application and
you probably should not mess with any of those.

This is why you should pass your applications own ProjectData to
GNUNET_PROGRAM_run and friends.

Of course it is understandable that you want to use GNUnet services and
connect to them.
That is why GNUnet's config is still available for you to use.

You can check out gnunet-gtk on how that is supposed to happen now.
(Commit
https://git.gnunet.org/gnunet-gtk.git/commit/?id=2e31cdf347d2fe93b6d388693027771b94fa60ef)

BR
Martin


On Tue, 2024-12-10 at 17:27 +0100, Alessio Vanni wrote:
> Hello,
> 
> GNUnet 0.23 changed the way GNUNET_OS_ProjectData is used, moving it 
> from being global state to a function parameter in commit 
> 9ab62c62c3d508033d31ea5289013255ec7a0c87.
> 
> The same commit also removes the GNUNET_CONFIGURATION_default
> function 
> to return a new configuration object with GNUnet's "default" values.
> 
> This removal breaks third-party applications with a 
> GNUNET_OS_ProjectData that is different from GNUnet's own, because
> the 
> configuration object given as argument to the "main" function called
> by 
> e.g. GNUNET_PROGRAM_run does not contain the values GNUnet expects.
> 
> I have attached a minimal test program to explain the issue. Compile
> it 
> with:
> gcc -o mybinary $(pkg-config --cflags gnunetutil) test.c $(pkg-config
> --libs gnunetutil)
> 
> then start GNUnet and execute the mybinary program. You will see that
> the program is not able to detect whether the GNS service is
> available 
> or not despite being running.
> 
> The only way to make it work is to use GNUnet's configuration, but
> there 
> is no way to obtain it without replicating GNUnet's logic (reading
> env 
> variables, expanding paths, using defaults, etc.) which is something 
> third-party applications should never do.
> 
> GNUNET_CONFIGURATION_create() only sets some path values, it does not
> load the actual configuration and that makes it unsuitable to connect
> to 
> services due to missing important values found in each service's
> section 
> of the configuration.
> 
> Applications which do not need to set a different project data value
> are 
> not affected, since they can use GNUnet's own one.
> 
> Thank you,
> A. V.