GNUnet 0.21.0 released

[Schanzenbach, Martin]

We are pleased to announce the release of GNUnet 0.21.0.
GNUnet is an alternative network stack for building secure, 
decentralized and privacy-preserving distributed applications. Our goal 
is to replace the old insecure Internet protocol stack. Starting from an 
application for secure publication of files, it has grown to include all 
kinds of basic protocol components and applications towards the creation 
of a GNU internet.


This release marks a noteworthy milestone in that it includes a 
completely new transport layer. It lays the groundwork for fixing some 
major design issues and may also already alleviate a variety of issues 
seen in previous releases related to connectivity. This change also 
deprecates our testbed and ATS subsystem.


This is a new major release. It breaks protocol compatibility with the 
0.20.x versions. Please be aware that Git master is thus henceforth (and 
has been for a while) INCOMPATIBLE with the 0.20.x GNUnet network, and 
interactions between old and new peers will result in issues. In terms 
of usability, users should be aware that there are still a number of 
known open issues in particular with respect to ease of use, but also 
some critical privacy issues especially for mobile users. Also, the 
nascent network is tiny and thus unlikely to provide good anonymity or 
extensive amounts of interesting information. As a result, the 0.21.0 
release is still only suitable for early adopters with some reasonable 
pain tolerance.


Download links:

http://ftpmirror.gnu.org/gnunet/gnunet-0.21.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.21.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.21.0.tar.gz

The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

Note that due to mirror synchronization, not all links might be 
functional early after the release. For direct access try 
http://ftp.gnu.org/gnu/gnunet/


Changes:

A detailed list of changes can be found in the git log, the NEWS and the 
bug tracker.


Known Issues:

- There are known major design issues in the CORE subsystems which 
will need to be addressed in the future to achieve acceptable usability, 
performance and security.
- There are known moderate implementation limitations in CADET that 
negatively impact performance.
- There are known moderate design issues in FS that also impact 
usability and performance.
- There are minor implementation limitations in SET that create 
unnecessary attack surface for availability.

- The RPS subsystem remains experimental.

In addition to this list, you may also want to consult our bug tracker 
at https://bugs.gnunet.org/ which lists about 190 more specific issues.


Thanks:

This release was the work of many people. The following people 
contributed code and were thus easily identified: Christian Grothoff, 
t3sserakt, TheJackiMonster, Pedram Fardzadeh, dvn, Sebastian Nadler and 
Martin Schanzenbach.

Re: GNUnet 0.21.0 released

[Schanzenbach, Martin]

Hi,

On 07.03.24 14:09, bastianschm...@danwin1210.de wrote:

Hello,


first of all,
GNUnet 0.21.0 - finally brought to this part of the multiverse, that's a
biggy. Lots of important work went into it for reaching this point - among
others integration of TNG, right?
Virtual applause to all devs contributing to this!

This important news item -
https://www.gnunet.org/en/news/2024-03-0.21.0.html - hasn't appeared on
the info-gnu mailing list, yet:
https://lists.gnu.org/archive/html/info-gnu/2024-03/threads.html

A look into the info-gnu mailing list archive reveals that news of previous
GNUnet version publications did appear on this mailing list - for example
GNUnet 0.12.0, on Fri, 20 Dec 2019 10:28:59 +0900:
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=GNUnet=Search%21=info-gnu=20=normal=date%3Alate

But planet gnu got it: https://planet.gnu.org/


It is easier to do the news entry first, and that is automatically 
distributed to planet.gnu.org (RSS).
I never got around to writing that script that parses the .j2 file into 
a plain text that can be sent via email.




This is a major major release, so please make sure that said news item to
it also gets on the info-gnu mailing list.

And in the long run—suggestion for improvement:
This kind of instance has a history, all together sketching an outlook for
process improvement by automation, whenever a major release is on the
table.
Can't there be any kind of script created, pushing the according news item
to planet gnu and the info-gnu mailing list all together just by the push
of 1 button?
So that not only Martin(?) or tesserakt(?) are eased from this specific
task, but also all important spots are covered with this kind of news item
securely at the same, immediate time?

Last time that got addressed, Martin replied

"Still, writing both the email AND the news post is tedious, so it would
be nice to only write it once, from a template, and then generate both. Or
generate one out of the other, without having to actually send HTML email.


That being said, I would actually prefer to only send the link to the news
entry, even for major releases. That is the simplest solution.


BR" -
https://lists.gnu.org/archive/html/gnunet-developers/2023-09/msg4.html

What's status regarding that?




It is true that just sending the link is easier. But for a major release 
we should just send the whole message in order to better distribute it 
to people that would otherwise not follow the link occasionally (i.e. 
for major releases).




Reasoning:
This release is a quite important milestone among all releases, and
therefore deserves to get spotlight according to that.



Yes, but we already do that: Minor releases only go to our mailing lists 
with a link to the news, major releases get a full email.

The email will always be delayed a bit, as I use the news entry as template.

BR



Best regards,
Bastian Schmidt

Re: gnunet-gtk GTK4 port

[Schanzenbach, Martin]

Well I think at least the use of cambalache would imply the use of 
libadwaita as well.


Br
Martin

On 06.03.24 08:20, Gotam Gorabh wrote:
Hello, I would like to know if we plan to use *Libadwaita* during the 
porting process. After that I will prepare my GSoC proposal accordingly.


BR

Thanks

Re:

[Schanzenbach, Martin]

Hi,

first of all, this is the primary GSoC issue: 
https://bugs.gnunet.org/view.php?id=5679


There are unfortunately no gnunet-gtk issues to point to I think.
This is the full list: https://bugs.gnunet.org/view_all_bug_page.php

But, I am not sure how many of those actually still apply.

Maybe look around in the current UI and try to fix obvious ugly things.

BR

On 28.02.24 10:46, Gotam Gorabh wrote:

Hello,

Can you suggest to me some Issues or features to work on to get a better 
understanding of the codebase?


Thanks and regards

Gotam

Re: GSoC 2024: gnunet-gtk gtk4 upgrade

[Schanzenbach, Martin]

Just to also throw another option out there. Since we now have a REST 
API we may even want to consider writing it in something else than C:

https://www.gtk.org/docs/language-bindings/index

Even if we write it in C, we may want to use the REST API, it would 
theoretically make it easier to do graphical remote or container 
administration.


In any case, I do not mind using RAD again, but calling the output of 
glade and friends something other than madness did not really look into 
what those XML files look like. They are unmaintainable, unless the tool 
continues to work and you know how to use it.


Maybe GtkBuilder and hand-crafted XML files is a good compromise?

BR
Martin

On 28.02.24 01:20, Jacki wrote:

Exactly. In GTK3 you can still use Glade but import the UI files via
GtkBuilder. In GTK4 they adjusted widgets quite a bit. So instead of
Glade you need to use Cambalache because Glade won't be ported over. In
fact Cambalache is developed by one of the core contributors behind
Glade.

Since Camabalache is still in development we could port over to GTK3
using GtkBuilder with designing UI in Glade though. The required
changes from GTK3 to GTK4 shouldn't be huge in most cases. Cambalache
also supports converting the UI files from GTK3 to GTK4.

I think GNOME published a blog post for porting from GTK3 to GTK4 as
well.

But I assume it's also possible to use Cambalache already. Most
important functionality should work.

BR
Jacki

On Tue, 2024-02-27 at 20:58 +0100, Christian Grothoff wrote:

Let me just say this: using a RAD tool like Glade is just the only
logical thing, it is 1000% more productive for UX development then
doing
the building of Gtk objects by hand. So for the sake of sanity,
please
use *some* RAD tool. Besides, AFAIK GtkBuilder isn't deprecated, just
Glade itself is being rewritten/replaced.  We used Glade for quite a
while despite it being WIP/in beta, with GNOME's reluctance to
declare
something stable I'm not sure a WIP RAD tool is inherently a bad
idea.
But I *am* sure that doing gtk_box_add() by hand is the road to
insanity.  So I would very strongly recommend using Cambalance ---
and
to use the opportunity to clean up the GUIs ;-).

On 2/27/24 20:51, Schanzenbach, Martin wrote:

I think our use of glade is historical.
It just made sense to somebody (not me, my guess is Christian).

I personally have no issue with moving away from glade as RAD tool
as I
find it very cumbersome myself.
Note, however, that it will also mean writing a lot of code that is
currently hidden behind those glade XML files.

OTOH moving to a WIP RAD tool is also not such a smart idea, maybe.
But
that depends on the maturity of cambalanche, which I cannot judge
myself
right now as I have never tried it.

BR

On 27.02.24 20:19, Gotam Gorabh wrote:

Hello Martin,

     Note that migration from gtk3 to gtk4 especially for gnunet-
gtk is
not
     trivial: We use libglade, which does not exist for gtk4.
     We will need to decide if we want to migrate to something
like

https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-released/
 
<

https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-release
d/> or
     something different entirely.


Why can't we use the proper GObject concept like other gnome
application does? E.g. GNOME Settings,  Nautilus, etc. which can
handle the properties, and signals in a structured way.

Thanks. Regards

Gotam Gorabh

Re: GSoC 2024: gnunet-gtk gtk4 upgrade

[Schanzenbach, Martin]

Try exporting GNUNET_PREFIX:
You may have provided "--prefix=" to configure. If you did not, 
it is "/usr/local". Before you run gnunet-gtk, run:


$ export GNUNET_PREFIX=/lib

Br

On 28.02.24 05:52, Gotam Gorabh wrote:

Hey,

I built and installed *gnunet* and *gnunet-gtk *successfully**but while 
testing the changes by compiling and running the binary file of 
gnunet-gtk (e.g. Runing ./src/fs/gnunet-fs-gtk). It gives following error.

However, the Installed binary is running successfully.

WARNING `stat' failed on file
`/home/firefly/gnunet-gtk/src/share/gnunet/config.d' at disk.c:836
with error: No such file or directory
ERROR Failed to load

`/home/firefly/gnunet-gtk/src/share/gnunet/gnunet_fs_gtk_main_window.glade': 
Failed to open file 
“/home/firefly/gnunet-gtk/src/share/gnunet/gnunet_fs_gtk_main_window.glade”: No 
such file or directory


Should I pass any further arguments to the command line while running 
binary or something else?


Thanks & regards

Gotam Gorabh

Re: GSoC 2024: gnunet-gtk gtk4 upgrade

[Schanzenbach, Martin]

I think our use of glade is historical.
It just made sense to somebody (not me, my guess is Christian).

I personally have no issue with moving away from glade as RAD tool as I 
find it very cumbersome myself.
Note, however, that it will also mean writing a lot of code that is 
currently hidden behind those glade XML files.


OTOH moving to a WIP RAD tool is also not such a smart idea, maybe. But 
that depends on the maturity of cambalanche, which I cannot judge myself 
right now as I have never tried it.


BR

On 27.02.24 20:19, Gotam Gorabh wrote:

Hello Martin,

Note that migration from gtk3 to gtk4 especially for gnunet-gtk is not
trivial: We use libglade, which does not exist for gtk4.
We will need to decide if we want to migrate to something like
https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-released/
 or
something different entirely.


Why can't we use the proper GObject concept like other gnome application 
does? E.g. GNOME Settings,  Nautilus, etc. which can handle the 
properties, and signals in a structured way.


Thanks. Regards

Gotam Gorabh

Re: Interacting with other peers

[Schanzenbach, Martin]

Yes, you can use the MQ from the ConnectEventHandler to send a message 
to the connected peer (s).
You know that you have to throw the peer/MQ away when the 
DisconnectEventHandler is called.


BR
Martin

On 27.02.24 11:39, Andrei Ușurelu wrote:

By using the CORE service I mean fetching each peer identity and
storing it internally in a list in case there's no way to multicast a
message to all known peers. I was wondering if the message queue
received in connects() correlates with the remote peer that just
connected or with the current peer.

În mar., 27 feb. 2024 la 12:28, Andrei Ușurelu
 a scris:


Good day! I have a question, how would  I be able to multicast a message from 
one peer to the rest of the peers using the CORE service?

Recent peerstore changes in git head

[Schanzenbach, Martin]

Hello,

due to recent changes in the peerstore DB layout, you will need to purge 
your old peerstore sqlite.db file found (probably) in


$HOME/.local/share/gnunet/peerstore/sqlite.db

Otherwise, your peerstore will fail to start.

BR

Re: FS replication level

[Schanzenbach, Martin]

Hi,

the replication level defines to what degree a degree the data is 
(redundantly) replicated.


Say, at replication level 0 your file is divided into blocks,
exactly 1 peer would be authoritative in the DHT for that block and 
store it.
With a replication level of 1, one additional peer is also caching that 
block. With a level of 2, there are three peers holding a copy of that 
block.


As you can see, this helps when the network as a lot of churn to keep 
the data available. The larger the value, the better the availability, 
but the less (space) efficient it is.


Br

On 24.02.24 19:29, Andrei Ușurelu wrote:

I looked at fs.conf and got my answer about the set. Still, what
exactly is the replication level supposed to do?

În sâm., 24 feb. 2024 la 19:53, Andrei Ușurelu
 a scris:


Good day! I don't quite understand what the replication level does
when a file/block is published. Also, how is "CONTENT_PUSHING" set?

Re: GNUnet Monthly Meeting Sunday, 3rd December, 8 PM Paris/Berlin/Rome

[Schanzenbach, Martin]

I don't even think that was malicious. Somebody just used a translator.
Well, that's the tradeoff for using a public pad...
But, if we wanted to actually preserve the minutes we would check them 
into the git, so it's whatever.


BR

On 11.12.23 17:16, Marcos Marado wrote:

Hi there,

FYI, it seems that someone translated the two latest month entries into 
Chinese...


On Tue, Nov 28, 2023, 10:01 > wrote:


Dear all,


quick reminder for our monthly meeting on

Sunday, 3rd December, 8 PM Paris/Berlin/Rome

on mumble server: gnunet.org 

everyone is very invited!

Pad for meeting minutes and possible agenda:

https://pep.pad.foebud.org/GNUnet-jour-fixe


To see the meeting start time in your time zone, run this in GNU Bash,

date --date='TZ="Europe/Rome" 20:00 this sun'

or in GNU Emacs type,

M-!

followed by,

date --date='TZ="Europe/Rome" 20:00 this sun'


Cheers,
Bastian Schmidt

Re: GNUnet Name System Questions

[Schanzenbach, Martin]

I'm sorry I do not understand the question. How does any of this relate 
to GNS?


Best
Martin

On 03.12.23 09:56, retrovirus-...@juno.com wrote:

I almost forget to mention that there is a possible issue with URL 
https://IPv4_IP_address and https://[IPv6_IP_address]. SSL certification, at 
least for the domain name, will not cover https:// protocol and IP address 
combinations. Are insecure URL https://IPv4_IP_address and 
https://[IPv6_IP_address considered possible man-in-the-middle attack 
vulnerabilities?

--
Sincerely,
retrovirus-...@juno.com

Re: GNUnet Name System Questions

[Schanzenbach, Martin]

There is a first-come-first-served registrar for .pin subdomain which is 
a history service by the gnunet project.


Any zone owner can potentially act as a zone registrar and sell (or give 
away) subdomains.


We are currently working on a new registrar service that will also be 
integrated with GNU Taler to allow for payments.


Owning a GNUnet zone is free (since a zone is created by creating a 
public/private key pair).


The question is, if users can reach your zone.
To understand this problem space a bit better, I urge you to read:

Section 7.1. Start Zones: https://lsd.gnunet.org/lsd0001/#name-start-zones

and

Section 9.5 Zone Management: 
https://lsd.gnunet.org/lsd0001/#name-zone-management


from the spec.

I do not know what you mean by "omit IP addresses". A registrar would 
likely just delegate to your zone (public key). Nothing to do with A or 
 records, or IP addresses. (Think NS records in DNS)


Best
Martin



On 03.12.23 09:49, retrovirus-...@juno.com wrote:

Hello GNUnet Developers,

I was wondering since the last build, if the GNUnet Name System has a domain 
name registrar service (would owning a GNUnet domain name be free [probably 
not, but thought it wouldn't hurt to ask])? And if that service can omit 
certain information such as IPv4 and IPv6 IP addresses?

--
Sincerely,
John Doe
retrovirus-...@juno.com

Re: RFC 9498: The GNU Name System

[Schanzenbach, Martin]

Hi,

On 21.11.23 18:55, Maxime Devos wrote:

Op 21-11-2023 om 08:34 schreef Schanzenbach, Martin:

We are happy to announce that our *The GNU Name System* (GNS)
specification is now published as RFC 9498 [0].


in order to transparently enable this functionality for migration 
purposes, a local GNS-aware SOCKS5 proxy [RFC1928] can be configured 
to resolve domain names


Are you sure this is transparent?  Consider the case where a website has 
a log-in system, and instead of being based on passwords, it is based on 
TLS client certificates (for example, https://ci.guix.gnu.org/ has such 
a system to decide who is allowed to adjust ‘specifications’ and 
‘restart builds’).


Given that the SOCKS5 proxy is technically a MITM attack, and the client 
certificates instead of only server certificates, I would expect (and 
hope) that the SOCKS5 proxy can't convince the server that it is the 
client.




obviously, TLS client authentication does not work in this case and this 
migration path, unless the proxy itself does it.
I do not see a problem with the proxy doing it. It just somehow needs to 
have access to your client certs.

Out implementation does not support this kind of flow atm.

BR


It's a somewhat niche use case, so mostly transparent, sure.
But transparent, without qualifiers, I don't think so.

Best regards,
Maxime Devos

RFC 9498: The GNU Name System

[Schanzenbach, Martin]

We are happy to announce that our *The GNU Name System* (GNS)
specification is now published as RFC 9498 [0].

GNS addresses long-standing security [1] and privacy [2] issues in the
ubiquitous Domain Name System (DNS) [3]. Previous attempts to secure DNS
(DNSSEC [4]) fail to address critical security issues [5] such as end-to-end
security, query privacy, censorship, and centralization of root zone
governance. After 40 years of patching, it is time for a new beginning.

The GNU Name System is our contribution towards a decentralized and
censorship-resistant domain name resolution system that provides a
privacy-enhancing alternative to the Domain Name System (DNS).

As part of our work on RFC 9498, we have also contributed to the
specification of the .alt top-level domain [6] to be used by alternative
name resolution systems and have established the GANA registry for
".alt" [7].

GNS is implemented according to RFC 9498 in GNUnet 0.20.0. It is also
implemented as part of GNUnet-Go [8].

We thank all reviewers for their comments. In particular, we thank D. J.
Bernstein, S. Bortzmeyer, A. Farrel, E. Lear, and R. Salz for their
insightful and detailed technical reviews. We thank J. Yao and J.
Klensin for the internationalization reviews. We thank Dr. J. Appelbaum
for suggesting the name "GNU Name System" and Dr. Richard Stallman for
approving its use. We thank T. Lange and M. Wachs for their earlier
contributions to the design and implementation of GNS. We thank J. Yao
and J. Klensin for the internationalization reviews. We thank NLnet [9]
and NGI DISCOVERY [10] for funding work on the GNU Name System.

The work does not stop here: We encourage further implementations of RFC
9498 to learn more both in terms of technical documentation and actual
deployment experiences. Further, we are currently working on the
specification of the R^5N DHT [11] and BFT Set Reconciliation [12] which are
underlying building blocks of GNS in GNUnet and not covered by RFC 9498.

[0]: https://www.rfc-editor.org/rfc/rfc9498.html
[1]: https://www.wired.com/2014/03/quantum/
[2]: https://roarmag.org/essays/nsa-leak-domain-name-system/
[3]: https://www.rfc-editor.org/rfc/rfc882
[4]: https://www.rfc-editor.org/rfc/rfc9364
[5]: https://www.rfc-editor.org/rfc/rfc8324
[6]: https://www.rfc-editor.org/rfc/rfc9476.html
[7]: https://gana.gnunet.org/dot-alt/dot_alt.html
[8]: https://git.gnunet.org/gnunet-go.git/
[9]: https://nlnet.nl
[10]: https://nlnet.nl/project/GNS/
[11]: https://lsd.gnunet.org/lsd0004
[12]: https://lsd.gnunet.org/lsd0003

RFC 9498: The GNU Name System

[Schanzenbach, Martin]

We are happy to announce that our *The GNU Name System* (GNS)
specification is now published as RFC 9498 [0].

GNS addresses long-standing security [1] and privacy [2] issues in the
ubiquitous Domain Name System (DNS) [3]. Previous attempts to secure DNS
(DNSSEC [4]) fail to address critical security issues [5] such as end-to-end
security, query privacy, censorship, and centralization of root zone
governance. After 40 years of patching, it is time for a new beginning.

The GNU Name System is our contribution towards a decentralized and
censorship-resistant domain name resolution system that provides a
privacy-enhancing alternative to the Domain Name System (DNS).

As part of our work on RFC 9498, we have also contributed to the
specification of the .alt top-level domain [6] to be used by alternative
name resolution systems and have established the GANA registry for
".alt" [7].

GNS is implemented according to RFC 9498 in GNUnet 0.20.0. It is also
implemented as part of GNUnet-Go [8].

We thank all reviewers for their comments. In particular, we thank D. J.
Bernstein, S. Bortzmeyer, A. Farrel, E. Lear, and R. Salz for their
insightful and detailed technical reviews. We thank J. Yao and J.
Klensin for the internationalization reviews. We thank Dr. J. Appelbaum
for suggesting the name "GNU Name System" and Dr. Richard Stallman for
approving its use. We thank T. Lange and M. Wachs for their earlier
contributions to the design and implementation of GNS. We thank J. Yao
and J. Klensin for the internationalization reviews. We thank NLnet [9]
and NGI DISCOVERY [10] for funding work on the GNU Name System.

The work does not stop here: We encourage further implementations of RFC
9498 to learn more both in terms of technical documentation and actual
deployment experiences. Further, we are currently working on the
specification of the R^5N DHT [11] and BFT Set Reconciliation [12] which are
underlying building blocks of GNS in GNUnet and not covered by RFC 9498.

[0]: https://www.rfc-editor.org/rfc/rfc9498.html
[1]: https://www.wired.com/2014/03/quantum/
[2]: https://roarmag.org/essays/nsa-leak-domain-name-system/
[3]: https://www.rfc-editor.org/rfc/rfc882
[4]: https://www.rfc-editor.org/rfc/rfc9364
[5]: https://www.rfc-editor.org/rfc/rfc8324
[6]: https://www.rfc-editor.org/rfc/rfc9476.html
[7]: https://gana.gnunet.org/dot-alt/dot_alt.html
[8]: https://git.gnunet.org/gnunet-go.git/
[9]: https://nlnet.nl
[10]: https://nlnet.nl/project/GNS/
[11]: https://lsd.gnunet.org/lsd0004
[12]: https://lsd.gnunet.org/lsd0003

Re: GNUnet 0.20.0 released

[Schanzenbach, Martin]

Still, writing both the email AND the news post is tedious, so it would 
be nice to only write it once, from a template, and then generate both.
Or generate one out of the other, without having to actually send HTML 
email.


That being said, I would actually prefer to only send the link to the 
news entry, even for major releases. That is the simplest solution.


BR

On 25.09.23 19:33, Christian Grothoff wrote:

Dear Bastian,

I actually don't think this release is that big a deal. 0.21.0 is 
expected to finally integrate TNG, which will deserve a bigger 
announcement (assuming that we're sure enough it works well ;-)).


0.20.0 is more incremental small improvements, and many mostly for GNU 
Taler 0.9.3. So I don't think we should go info-gnu this time.


My 2 cents

Christian

On 9/25/23 19:11, bastianschm...@danwin1210.de wrote:

Hello,


first of all,
GNUnet project wanted to release GNUnet 0.20.0 before the 40th GNU
Anniversary Hacker Meeting.
GNUnet project succeeded in reaching this aim.
Virtual applause to all devs contributing to this!

This important news item -
https://www.gnunet.org/en/news/2023-09-0.20.0.html - hasn't appeared on
the info-gnu mailing list, yet:
https://lists.gnu.org/archive/html/info-gnu/2023-09/threads.html

A look into the info-gnu mailing list archive reveals that news of 
previous

GNUnet version publications did appear on this mailing list - for example
GNUnet 0.12.0, on Fri, 20 Dec 2019 10:28:59 +0900:
https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=GNUnet=Search%21=info-gnu=20=normal=date%3Alate

But planet gnu got it: https://planet.gnu.org/

This is a major major release, so please make sure that said news item to
it also gets on the info-gnu mailing list.

And in the long run—suggestion for improvement:
This kind of instance has a history, all together sketching an outlook 
for

process improvement by automation, whenever a major release is on the
table.
Can't there be any kind of script created, pushing the according news 
item

to planet gnu and the info-gnu mailing list all together just by the push
of 1 button?
So that not only Martin(?) or tesserakt(?) are eased from this specific
task, but also all important spots are covered with this kind of news 
item

securely at the same, immediate time?

Reasoning:
This release is a quite important milestone among all releases, and
therefore deserves to get spotlight according to that.


Best regards,
Bastian Schmidt

Re: purge_secrets missing return on non-void function

[Schanzenbach, Martin]

Hi,

it is thanks. I just fixed it in git head.

BR
Martin

On 25.09.23 14:18, Andreas Stieger wrote:

Hello,

I am not sure if this is new as of 0.20.0 or earlier, but this seems to
be related to bb4036:

[   50s] gnunet-communicator-udp.c: In function 'purge_secrets':
[   50s] gnunet-communicator-udp.c:1401:1: error: no return statement in
function returning non-void [-Werror=return-type]
[   50s]  1401 | }
[   50s]   | ^

The documented intent here is to return an GNUNET_GenericReturnValue,
specifically if GNUNET_YES if any secret was deleted. It actually does
the counting but the GNUNET_YES/GNUNET_NO logic seems to be missing.

So the following makes sense:

Index: gnunet-0.20.0/src/transport/gnunet-communicator-udp.c
===
--- gnunet-0.20.0.orig/src/transport/gnunet-communicator-udp.c
+++ gnunet-0.20.0/src/transport/gnunet-communicator-udp.c
@@ -1398,6 +1398,10 @@ purge_secrets (struct SharedSecret *ss_l
    }
    GNUNET_log (GNUNET_ERROR_TYPE_DEBUG,
    "Finished purging all, deleted %u.\n", deleted);
+  if (deleted > 0) {
+    return GNUNET_YES;
+  }
+  return GNUNET_NO;
  }


Andreas

Re: Adding generic cryptographic self-authenticating block on DHT

[Schanzenbach, Martin]

More info:
The registry is in the docs: 
https://docs.gnunet.org/gana/gnu_name_system_record_types.html

and you probably want to use this for GNS:
https://docs.gnunet.org/developers/subsystems/gnsstack.html

Am 28.05.23 um 17:11 schrieb Schanzenbach, Martin:

Hi!

Am 28.05.23 um 11:17 schrieb marty1885:

Hi,

I've been working on my own to build a private messaging system on
GNUnet (just for fun, as a hobby project). It's not exactly the same
as libgnunetchat. My goal is to create a system that works like email
and supports message delivery even when the receiving node is offline.
No working code yet, just designing and building my C++ binding. The
binding is available on my GitHuib
(https://github.com/marty1885/gnunetpp).

After iterations of design and failing. I realized a challenge when
Alice sends a message to Bob while Bob is offline. Bob needs to
publish his encryption public key on DHT under the hash of his Ego's
public key `hash(bob_ego_pk)`. However, attackers who know Bob's ego
can flood the DHT with garbage data, making it difficult for Alice to
find the actual record. Since the DHT functions as a plain key-value
store, there's no way to prevent attackers from doing so.



What you actually want is to use GNS, not the DHT directly.
Using GNS, you can create an Ego and publish information under that ego.
The data will also be signed in a way that if you carefully choose the 
key, it provides even more security (privacy) guarantees.
You can read the spec here: 
https://datatracker.ietf.org/doc/draft-schanzen-gns/



I want to add a few self-authenticating blocks that all nodes validate
and do not propagate or store if the validation fails. This way,
attackers won't be able to spam garbage data in the hopes of hiding
Bob's public key. Even if they try, other nodes around them will see
the invalid messages and stop the attack right there. This validation
process is similar to how CADET validates messages before sending or
receiving. After reading the DHT source code, it seems that it only
validates the HELLO messages. Also, the current DHT block types are
quite specific besides the TEST block. I believe GNUnet could benefit
from having blocks that can store generic messages.


Yes, you want GNS.



Could someone point me in the right direction to get started? I
understand that in order to contribute, I'll need to sign the PDF and
send an email to GANA to add the types. Is there anything else I
should do? I've attached some preliminary details, in case they are
helpful.


You may want to add GNS record types for your purposes via GANA:
https://git.gnunet.org/gana.git/tree/gnu-name-system-record-types/POLICY

The DHT block types are here: 
https://git.gnunet.org/gana.git/tree/gnunet-dht-block-types/README

But there is no registration policy (yet) it seems.
But consider GNS first!

BR
Martin



Best regards,

Martin

=

I would like to introduce two new block types: SELF_HASH and
ECDSA_SELF_SIGNED. SELF_HASH functions similarly to how the FS block
works. In SELF_HASH, the DHT key must be the hash of the entire block.
This block type is useful for sharing anonymous public messages while
preventing attackers from overwhelming it.

ECDSA_SELF_SIGNED works similarly to GNS's block. The structure of the
message would look like the following:

|--|--|--...--||

   ECDSA-PK   TOPIC    message    SIG

SIG represents the ECDSA signature of all the preceding bytes,
including the PK and the topic. This block type must be published
under HMAC(PK, TOPIC). This block allows Egos to publish information.

For both block types, it's possible to add an extra layer of
indirection and encryption for better privacy and security. I have
omitted them to keep the explanation simple.

Also I understand that this could be achieved by using the GNS as a
key-value store. But that seems excessive and just not right.

Or maybe I should just publish GNS blocks and let GNS do the
filtering?

Re: Adding generic cryptographic self-authenticating block on DHT

[Schanzenbach, Martin]

Hi!

Am 28.05.23 um 11:17 schrieb marty1885:

Hi,

I've been working on my own to build a private messaging system on
GNUnet (just for fun, as a hobby project). It's not exactly the same
as libgnunetchat. My goal is to create a system that works like email
and supports message delivery even when the receiving node is offline.
No working code yet, just designing and building my C++ binding. The
binding is available on my GitHuib
(https://github.com/marty1885/gnunetpp).

After iterations of design and failing. I realized a challenge when
Alice sends a message to Bob while Bob is offline. Bob needs to
publish his encryption public key on DHT under the hash of his Ego's
public key `hash(bob_ego_pk)`. However, attackers who know Bob's ego
can flood the DHT with garbage data, making it difficult for Alice to
find the actual record. Since the DHT functions as a plain key-value
store, there's no way to prevent attackers from doing so.



What you actually want is to use GNS, not the DHT directly.
Using GNS, you can create an Ego and publish information under that ego.
The data will also be signed in a way that if you carefully choose the 
key, it provides even more security (privacy) guarantees.
You can read the spec here: 
https://datatracker.ietf.org/doc/draft-schanzen-gns/



I want to add a few self-authenticating blocks that all nodes validate
and do not propagate or store if the validation fails. This way,
attackers won't be able to spam garbage data in the hopes of hiding
Bob's public key. Even if they try, other nodes around them will see
the invalid messages and stop the attack right there. This validation
process is similar to how CADET validates messages before sending or
receiving. After reading the DHT source code, it seems that it only
validates the HELLO messages. Also, the current DHT block types are
quite specific besides the TEST block. I believe GNUnet could benefit
from having blocks that can store generic messages.


Yes, you want GNS.



Could someone point me in the right direction to get started? I
understand that in order to contribute, I'll need to sign the PDF and
send an email to GANA to add the types. Is there anything else I
should do? I've attached some preliminary details, in case they are
helpful.


You may want to add GNS record types for your purposes via GANA:
https://git.gnunet.org/gana.git/tree/gnu-name-system-record-types/POLICY

The DHT block types are here: 
https://git.gnunet.org/gana.git/tree/gnunet-dht-block-types/README

But there is no registration policy (yet) it seems.
But consider GNS first!

BR
Martin



Best regards,

Martin

=

I would like to introduce two new block types: SELF_HASH and
ECDSA_SELF_SIGNED. SELF_HASH functions similarly to how the FS block
works. In SELF_HASH, the DHT key must be the hash of the entire block.
This block type is useful for sharing anonymous public messages while
preventing attackers from overwhelming it.

ECDSA_SELF_SIGNED works similarly to GNS's block. The structure of the
message would look like the following:

|--|--|--...--||

   ECDSA-PK   TOPICmessageSIG

SIG represents the ECDSA signature of all the preceding bytes,
including the PK and the topic. This block type must be published
under HMAC(PK, TOPIC). This block allows Egos to publish information.

For both block types, it's possible to add an extra layer of
indirection and encryption for better privacy and security. I have
omitted them to keep the explanation simple.

Also I understand that this could be achieved by using the GNS as a
key-value store. But that seems excessive and just not right.

Or maybe I should just publish GNS blocks and let GNS do the
filtering?

Re: Another GNUnet Project GSOC 2023 Contributor

[Schanzenbach, Martin]

Hi Igor,

sounds good.

Try running

$ ldconfig

or (if you have GNUnet installed in $GNUNET_PREFIX)

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GNUNET_PREFIX

and see if that fixes the problem.

Best
Martin

Am 22.03.23 um 00:25 schrieb Игорь Антонов:

Hi GNUnet developers!

Just like Marshall Stone I got interested in GNUnet thanks to the GSOC 
program. I think it might be a very interesting project to contribute to.
I'm a first year Software Development student at South East 
Technological University, Carlow, Ireland.
Currently I'm in the process of trying to get the latest versions of 
gnunet and gnunet-gtk running on my machine. Still working on it. After 
downgrading sphinx and fixing some errors I compiled them both 
successfully, but I can't run gnunet-fs-gtk because it can't find 
libgnunetgtk.so.3. Gotta figure out how to fix that.
I hope if contributor's applications succeed everybody has a great 
summer of code. I look forward to hearing from you all and to that 
meeting on 2nd of April!

Kind regards,
Igor Antonow

Re: Hello from the libp2p project

[Schanzenbach, Martin]

Hi Max,

thanks for reaching out.
Indeed, it would be great to establish an exchange between our projects.

There are actually a few ideas floating around already in my head, but due to 
lack of time there is little chance that I will take a serious myself in the 
near future such as a GNS implementation on top of the libp2p DHT or an R5N 
implementation for libp2p.
t3ss is currently (soon?) working on the NAT traversal functionality for our 
transport layer rewrite so from what I have seen on your HP, this may also be 
of interest to you and your insights valuable.

Regarding the libp2p day: I will be unable to attend unfortunately. Maybe 
others can?

Best
Martin

> On 16. Sep 2022, at 11:57, Max Inden  wrote:
> 
> Hi there,
> 
> This is Max [5], one of the maintainers of the libp2p [1] [2] project.
> 
> I have been following the GnuNet project for a couple of months. Obviously I 
> am quite into p2p networking, thus reading your living standards page [3] as 
> well as various other resources was wonderful. Thanks for making this 
> material available.
> 
> I think we can learn a lot from each other, thus I am reaching out to 
> connect. I will try to join one of the upcoming GnuNet monthly get-togethers. 
> Also I want to use the chance to invite you folks to our "libp2p day" [4] end 
> of October in Lisbon. Let me know in case you would like to join.
> 
> Regards,
> Max
> 
> ---
> 
> [1]: https://libp2p.io/
> [2]: https://github.com/libp2p/specs/
> [3]: https://www.gnunet.org/en/livingstandards.html
> [4]: 
> https://discuss.libp2p.io/t/first-ever-libp2p-day-oct-30-lisbon-portugal/1582
> [5]: https://max-inden.de/

Re: About GNUrl and cURL

[Schanzenbach, Martin]

My very last commit actually broke it again (fixed now) but see buildbot for an 
example that in debian, curl-gnutls is detected correctly:

https://buildbot.gnunet.org/#/builders/13/builds/133/steps/2/logs/configure

> On 8. Sep 2022, at 09:46, madmurphy  wrote:
> 
> No, libcurl.so is a symlink to libcurl.so.4.8.0. However my glue package (a 
> super-minimal one) now provides a libcurl-gnutls.so, which is a symlink to 
> libcurl-gnutls.so.4.8.0.
> 
> By the way, after the last commits GNUnet's configure script does not detect 
> libcurl-gnutls also with my glue package (config.log attached). However I 
> just discovered these two packages in that fantastic place that is AUR: 
> libcurl-gnutls-minimal-git, libcurl3-gnutls. I think I should definitely give 
> them a try.
> 
> --madmurphy
> 
> 
> On Thu, Sep 8, 2022 at 7:55 AM Martin Schanzenbach  
> wrote:
> I checked the log and the test runs correctly.
> The condition
> 
> CURLSSLSET_OK != curl_global_sslset(CURLSSLBACKEND_GNUTLS, NULL, ))
> 
> is evaluated against "-lcurl" and it is false.
> Hence the library linked against (-lcurl) does not support GnuTLS.
> The detection works.
> Are you sure that your libcurl.so is linked against the
> libcurl-gnutls.so* files?
> 
> BR
> 
> Excerpts from madmurphy's message of 2022-09-08 06:49:00 +0100:
> > I tried again, just to be sure. Still get
> >
> > ...
> > HTTP Client:curl (OpenSSL)
> > ...
> >
> > My config.log attached.
> >
> > --madmurphy
> >
> > On Wed, Sep 7, 2022 at 8:17 PM Martin Schanzenbach 
> > wrote:
> >
> > > I am quite sure it works now as expected so you would need to provide me
> > > with the config.log to debug.
> > > Maybe your link now points to the "Normal" curl because of the testing?
> > >
> > > Excerpts from madmurphy's message of 2022-09-07 18:55:19 +0100:
> > > > I now commited a programmatic check for GnuTLS. Try it out. It should 
> > > > not
> > > > require your fix.
> > > >
> > > > Mmm without my trick the configure script still prints
> > > >
> > > > ...
> > > > HTTP Client:curl (OpenSSL)
> > > > ...
> > > >
> > > > --madmurphy
> > > >
> > > > On Wed, Sep 7, 2022 at 3:44 PM Schanzenbach, Martin <
> > > mschanzenb...@posteo.de>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On 7. Sep 2022, at 14:59, madmurphy  wrote:
> > > > > >
> > > > > > Hi Martin,
> > > > > >
> > > > > > That means, if you can find out how the packages linked against
> > > > > libcurl-compat or libcurl-gnutls are built from source, you can do the
> > > same
> > > > > with the gnunet package.
> > > > > > The packages in the official repositories that explicitly require
> > > > > libcurl-gnutls (and not simply libcurl) are spotify-launcher (PKGBUILD
> > > /
> > > > > package source code) and steam-native-runtime (PKGBUILD / no source
> > > code
> > > > > here, it's just glue). But it is a mystery to me how they would find
> > > out.
> > > > >
> > > > > They probably do not distinguish between the two versions. The package
> > > > > build simply makes sure that during linking, the correct link is set.
> > > > >
> > > > > >
> > > > > > Ah look here:
> > > > >
> > > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > > > > The curl-compat package does link libcurl.so against the versioned
> > > files.
> > > > > > And curl-gnutls does the same:
> > > > >
> > > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > > > > > That libcurl-compat package compiles curl with different build
> > > settings,
> > > > > then renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally
> > > links
> > > > > libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0,
> > > > > libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, 
> > > > > libcurl.so.4.6.0,
> > > > > libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old
> > > > > versions, and the files libcurl.so, libcurl.so.4 and libcu

Re: A more general question about curl

[Schanzenbach, Martin]

Imagine that a "GET /download" downloads 1GB of data.
If your code looks like this (not the actual API but for demonstration 
purposes):

data = wget_get("/download")
// Wait until download completes

Then you have a blocking API.

Instead you can have a non-blocking API that allows you to "select" or "epoll" 
file descriptors of the download.
See https://curl.se/libcurl/c/libcurl-multi.html

> On 7. Sep 2022, at 16:28, madmurphy  wrote:
> 
> I never used the curl API, so I don't know what the multi interface is, but 
> if I remember correctly wget2 introduced non-blocking sockets. That's all I 
> know. I did not find a lot of info on Google, except maybe for this email on 
> gnutls mailing list: 
> https://lists.gnutls.org/pipermail/gnutls-devel/2019-June/014051.html
> 
> --madmurphy
> 
> On Wed, Sep 7, 2022 at 2:54 PM Schanzenbach, Martin  
> wrote:
> We need a non-blocking API such as curl_multi.
> Last time I checked, libwget2 does not have that.
> 
> BR
> 
> > On 7. Sep 2022, at 15:46, madmurphy  wrote:
> >
> > I don't know all the reasons behind using curl and all GNUnet's 
> > requirements, but have you guys thought about switching to wget2? It is a 
> > GNU package and has a nice library (libwget). It supports GNU TLS natively, 
> > it is supposed to download faster than curl, and if a minor feature is 
> > missing it might be an opportunity to make libwget grow.
> >
> > A comparison table (by curl):
> >
> > https://curl.se/docs/comparison-table.html
> >
> > --madmurphy
> 



signature.asc
Description: Message signed with OpenPGP

Re: About GNUrl and cURL

[Schanzenbach, Martin]

> On 7. Sep 2022, at 14:59, madmurphy  wrote:
> 
> Hi Martin,
> 
> That means, if you can find out how the packages linked against 
> libcurl-compat or libcurl-gnutls are built from source, you can do the same 
> with the gnunet package.
> The packages in the official repositories that explicitly require 
> libcurl-gnutls (and not simply libcurl) are spotify-launcher (PKGBUILD / 
> package source code) and steam-native-runtime (PKGBUILD / no source code 
> here, it's just glue). But it is a mystery to me how they would find out.

They probably do not distinguish between the two versions. The package build 
simply makes sure that during linking, the correct link is set.

> 
> Ah look here: 
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> The curl-compat package does link libcurl.so against the versioned files.
> And curl-gnutls does the same: 
> https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> That libcurl-compat package compiles curl with different build settings, then 
> renames libcurl.so.4.8.0 to libcurl-compat.so.4.8.0, and finally links 
> libcurl.so.3, libcurl.so.4.0.0, libcurl.so.4.1.0, libcurl.so.4.2.0, 
> libcurl.so.4.3.0, libcurl.so.4.4.0, libcurl.so.4.5.0, libcurl.so.4.6.0, 
> libcurl.so.4.7.0 to libcurl-compat.so.4.8.0 (these version are all old 
> versions, and the files libcurl.so, libcurl.so.4 and libcurl.so.4.8.0 remain 
> linked to the binary shipped by the original curl package).
> 
> That libcurl-gnutls package does exactly the same, but the basename of the 
> symlinks becomes libcurl-gnutls.so.* instead of simply libcurl.so.*.
> 
> FYI I updated the detection logic again. You may check if that works for you 
> know.
> If I try to build the last GNUnet commit with libcurl-gnutls from the 
> official Arch repository I still get
> 
> ...
> HTTP Client:curl (OpenSSL)
> ...
> 
> while if I use my hacked libcurl-gnutls I get
> 
> ...
> HTTP Client:curl-gnutls
> ...
> 
> I think I found a solution. I will publish a glue package on AUR named 
> libcurl-gnutls.so, which will depend on the official libcurl-gnutls, and on 
> which GNUnet will depend. All this glue package will do is simply creating an 
> unversioned symlink.

Yeah.. curl-config just seems to be a bash script where the supported backends 
are hardcoded when it is "compiled".
So even if you install curl-gnutls it will still say "openssl"... great.

I now commited a programmatic check for GnuTLS. Try it out. It should not 
require your fix.
No idea if anybody actually ships curl with multiple TLS backends, but we check 
on runtime anyway so its fine.
We may want to set the backend explicity maybe with curl_global_sslset...

BR
Martin

> 
> --madmurphy
> 
> 
> On Wed, Sep 7, 2022 at 7:33 AM Martin Schanzenbach  
> wrote:
> FYI I updated the detection logic again. You may check if that works for
> you know.
> Know that even if it detected "curl-openssl" for you the last time, it
> probably was correctly linked against the "drop-in" libcurl-gnutls.
> We just were not able to detect that.
> 
> BR
> 
> Excerpts from Martin Schanzenbach's message of 2022-09-07 06:06:52 +:
> > Excerpts from madmurphy's message of 2022-09-06 22:17:53 +0100:
> > > Okay, about the libcurl-gnutls package, Martin was right. If I add this
> > > line to the PKGBUILD of that package,
> > >
> > > ln -s libcurl-gnutls.so.4.8.0 "${pkgdir}"/usr/lib/libcurl-gnutls.so
> > >
> > > Everything goes well in GNUnet and the configure script prints
> > >
> > > ...
> > > HTTP Client:curl-gnutls
> > > ...
> > >
> > > Now the question is what to do. In theory I could publish my own version 
> > > of
> > > libcurl-gnutls on AUR with only that line added, and make GNUnet depend on
> > > it. But I wonder why Arch developers did that. My guess is that for
> > > creating the libcurl-gnutls package they copied and hacked the section of
> > > the PKGBUILD that builds libcurl-compat
> > > , which is a
> > > glue package that also does not ship the unversioned .so file
> > > . Who
> > > knows…
> > >
> >
> > Ah look here: 
> > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> > The curl-compat package does link libcurl.so against the versioned
> > files.
> > And curl-gnutls does the same: 
> > https://github.com/archlinux/svntogit-packages/blob/packages/curl/trunk/PKGBUILD#L94
> >
> > So, this would actually confirm my initial thoughts that those are
> > drop-in replacements and that we should not check for libcurl-gnutls at
> > all.
> > I have no idea how to "detect" the version of curl in this case.
> > But, I also do not think it really matters.
> > So maybe we should just remove the logic that tries to identify the curl
> > version.
> >
> > > Jacki, what do you suggest? The PKGBUILD 

Re: A more general question about curl

[Schanzenbach, Martin]

We need a non-blocking API such as curl_multi.
Last time I checked, libwget2 does not have that.

BR

> On 7. Sep 2022, at 15:46, madmurphy  wrote:
> 
> I don't know all the reasons behind using curl and all GNUnet's requirements, 
> but have you guys thought about switching to wget2? It is a GNU package and 
> has a nice library (libwget). It supports GNU TLS natively, it is supposed to 
> download faster than curl, and if a minor feature is missing it might be an 
> opportunity to make libwget grow.
> 
> A comparison table (by curl):
> 
> https://curl.se/docs/comparison-table.html
> 
> --madmurphy



signature.asc
Description: Message signed with OpenPGP

Re: About GNUrl and cURL

[Schanzenbach, Martin]

> On 6. Sep 2022, at 15:03, madmurphy  wrote:
> 
> Okay, the first thing I notice in the list of the files installed by 
> libcurl-gnutls is that there is no libcurl-gnutls.pc file. Do you think there 
> is a way to check without passing through pkgconf?
> 

I am pretty sure we do not use pkgconf.
I tested this locally by copying my libcurl.so* files to libcurl-gnutls.so* and 
it was detected correctly.
So this is odd.
I can investigate here, maybe check your config.log again to see what is going 
on. You should see a check that tries to link a binary against libcurl-gnutls.

BR

> 
> On Tue, Sep 6, 2022 at 1:47 PM madmurphy  wrote:
> I will try to check the configure.ac file. I don't get an error btw, only 
> that "curl-openssl" http client...
> 
> On Tue, Sep 6, 2022 at 1:45 PM Schanzenbach, Martin  
> wrote:
> Yes. I *think* I have found a better way to check for this and it should be 
> compatible with debian as well.
> 
> BR
> 
> > On 6. Sep 2022, at 12:32, madmurphy  wrote:
> >
> > Hi Martin,
> >
> > If "normal" curl is found, the check for curl-gnutls is skipped.
> > I guess we should prefer curl-gnutls.
> > Yes, libcurl-gnutls should be checked first. Also because apparently Arch 
> > is not the only distro that has a split package of cURL linked against GNU 
> > TLS…
> >
> > --madmurphy
> >
> >
> > On Tue, Sep 6, 2022 at 9:59 AM Schanzenbach, Martin 
> >  wrote:
> > Ah sorry I just checked:
> > If "normal" curl is found, the check for curl-gnutls is skipped.
> > I guess we should prefer curl-gnutls.
> >
> > Br
> >
> > > On 6. Sep 2022, at 10:51, Schanzenbach, Martin  
> > > wrote:
> > >
> > > Hi,
> > >
> > > check your config.log and check for the test against libcurl-gnutls.
> > > There should be test somewhere in there that fails for reasons.
> > >
> > > BR
> > > Martin
> > >
> > >> On 5. Sep 2022, at 20:21, madmurphy  wrote:
> > >>
> > >> Hi Christian,
> > >>
> > >> I tried to run ./configure twice. The first time I had installed on my 
> > >> machine curl (which is linked against openssl) and gnurl, but I did not 
> > >> have libcurl-gnutls installed. Under these conditions at the end of the 
> > >> configure script I got printed:
> > >>
> > >> ...
> > >> HTTP Client:gnurl
> > >> ...
> > >>
> > >> The second time I had curl and libcurl-gnutls installed, but gnurl was 
> > >> not installed. Under these conditions at the end of the configure script 
> > >> I got printed:
> > >>
> > >> ...
> > >> HTTP Client:curl-openssl
> > >> ...
> > >>
> > >> For some reasons in the second scenario the configure script sees the 
> > >> curl package but does not see libcurl-gnutls and so the latter is not 
> > >> used (I guess). The files shipped by the latter are:
> > >>
> > >> /usr/
> > >> /usr/lib/
> > >> /usr/lib/libcurl-gnutls.so.3
> > >> /usr/lib/libcurl-gnutls.so.4
> > >> /usr/lib/libcurl-gnutls.so.4.0.0
> > >> /usr/lib/libcurl-gnutls.so.4.1.0
> > >> /usr/lib/libcurl-gnutls.so.4.2.0
> > >> /usr/lib/libcurl-gnutls.so.4.3.0
> > >> /usr/lib/libcurl-gnutls.so.4.4.0
> > >> /usr/lib/libcurl-gnutls.so.4.5.0
> > >> /usr/lib/libcurl-gnutls.so.4.6.0
> > >> /usr/lib/libcurl-gnutls.so.4.7.0
> > >> /usr/lib/libcurl-gnutls.so.4.8.0
> > >> /usr/share/
> > >> /usr/share/licenses/
> > >> /usr/share/licenses/libcurl-gnutls
> > >>
> > >> How can we ensure that the configure script correctly sees the 
> > >> libcurl-gnutls package?
> > >>
> > >> I paste below both complete outputs.
> > >>
> > >> Installed: curl, gnurl
> > >> Not installed: libcurl-gnutls:
> > >>
> > >> $ ./configure
> > >> checking build system type... x86_64-pc-linux-gnu
> > >> checking host system type... x86_64-pc-linux-gnu
> > >> checking target system type... x86_64-pc-linux-gnu
> > >> checking for a BSD-compatible install... /usr/bin/install -c
> > >> checking whether build environment is sane... yes
> > >> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> > >> checking for gawk... gawk
> > >> checkin

Re: About GNUrl and cURL

[Schanzenbach, Martin]

Yes the curl pacakge does contain libcurl.so.
The question is why curl-gnutls does not. Maybe that is on purpose.

BR

> On 6. Sep 2022, at 19:32, TheJackiMonster  wrote:
> 
> In Arch most packages already contain the required files for
> development. There isn't really a separation between development
> packages and usage packages. Only exceptions I'm aware of are explicit
> packages to contain the headers (for example linux-headers and vulkan-
> headers).
> 
> So maybe this could just get fixed by adding a symbolic link in
> libcurl-gnutls, I assume.
> 
> Happy hacking
> Jacki
> 
> On Tue, 2022-09-06 at 17:16 +, Schanzenbach, Martin wrote:
>> I know why this does not work for you.
>> For example, in debian, there is a libcurl4-gnutls-dev which includes
>> the ".so" file.
>> That arch package is missing the (_unversioned_) ".so" file.
>> I do not know if there is a "-dev" equivalent in arch.
>> 
>> BR
>> 
>>> On 6. Sep 2022, at 18:48, Schanzenbach, Martin
>>>  wrote:
>>> 
>>> 
>>> 
>>>> On 6. Sep 2022, at 15:03, madmurphy 
>>>> wrote:
>>>> 
>>>> Okay, the first thing I notice in the list of the files installed
>>>> by libcurl-gnutls is that there is no libcurl-gnutls.pc file. Do
>>>> you think there is a way to check without passing through
>>>> pkgconf?
>>>> 
>>> 
>>> I am pretty sure we do not use pkgconf.
>>> I tested this locally by copying my libcurl.so* files to libcurl-
>>> gnutls.so* and it was detected correctly.
>>> So this is odd.
>>> I can investigate here, maybe check your config.log again to see
>>> what is going on. You should see a check that tries to link a
>>> binary against libcurl-gnutls.
>>> 
>>> BR
>>> 
>>>> 
>>>> On Tue, Sep 6, 2022 at 1:47 PM madmurphy 
>>>> wrote:
>>>> I will try to check the configure.ac file. I don't get an error
>>>> btw, only that "curl-openssl" http client...
>>>> 
>>>> On Tue, Sep 6, 2022 at 1:45 PM Schanzenbach, Martin
>>>>  wrote:
>>>> Yes. I *think* I have found a better way to check for this and it
>>>> should be compatible with debian as well.
>>>> 
>>>> BR
>>>> 
>>>>> On 6. Sep 2022, at 12:32, madmurphy 
>>>>> wrote:
>>>>> 
>>>>> Hi Martin,
>>>>> 
>>>>> If "normal" curl is found, the check for curl-gnutls is
>>>>> skipped.
>>>>> I guess we should prefer curl-gnutls.
>>>>> Yes, libcurl-gnutls should be checked first. Also because
>>>>> apparently Arch is not the only distro that has a split package
>>>>> of cURL linked against GNU TLS…
>>>>> 
>>>>> --madmurphy
>>>>> 
>>>>> 
>>>>> On Tue, Sep 6, 2022 at 9:59 AM Schanzenbach, Martin
>>>>>  wrote:
>>>>> Ah sorry I just checked:
>>>>> If "normal" curl is found, the check for curl-gnutls is
>>>>> skipped.
>>>>> I guess we should prefer curl-gnutls.
>>>>> 
>>>>> Br
>>>>> 
>>>>>> On 6. Sep 2022, at 10:51, Schanzenbach, Martin
>>>>>>  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> check your config.log and check for the test against libcurl-
>>>>>> gnutls.
>>>>>> There should be test somewhere in there that fails for
>>>>>> reasons.
>>>>>> 
>>>>>> BR
>>>>>> Martin
>>>>>> 
>>>>>>> On 5. Sep 2022, at 20:21, madmurphy
>>>>>>>  wrote:
>>>>>>> 
>>>>>>> Hi Christian,
>>>>>>> 
>>>>>>> I tried to run ./configure twice. The first time I had
>>>>>>> installed on my machine curl (which is linked against
>>>>>>> openssl) and gnurl, but I did not have libcurl-gnutls
>>>>>>> installed. Under these conditions at the end of the
>>>>>>> configure script I got printed:
>>>>>>> 
>>>>>>> ...
>>>>>>> HTTP Client:gnurl
>>>>>>> ...
>>>>>>> 
>>>>>>> The second tim

Re: About GNUrl and cURL

[Schanzenbach, Martin]

I know why this does not work for you.
For example, in debian, there is a libcurl4-gnutls-dev which includes the ".so" 
file.
That arch package is missing the (_unversioned_) ".so" file.
I do not know if there is a "-dev" equivalent in arch.

BR

> On 6. Sep 2022, at 18:48, Schanzenbach, Martin  
> wrote:
> 
> 
> 
>> On 6. Sep 2022, at 15:03, madmurphy  wrote:
>> 
>> Okay, the first thing I notice in the list of the files installed by 
>> libcurl-gnutls is that there is no libcurl-gnutls.pc file. Do you think 
>> there is a way to check without passing through pkgconf?
>> 
> 
> I am pretty sure we do not use pkgconf.
> I tested this locally by copying my libcurl.so* files to libcurl-gnutls.so* 
> and it was detected correctly.
> So this is odd.
> I can investigate here, maybe check your config.log again to see what is 
> going on. You should see a check that tries to link a binary against 
> libcurl-gnutls.
> 
> BR
> 
>> 
>> On Tue, Sep 6, 2022 at 1:47 PM madmurphy  wrote:
>> I will try to check the configure.ac file. I don't get an error btw, only 
>> that "curl-openssl" http client...
>> 
>> On Tue, Sep 6, 2022 at 1:45 PM Schanzenbach, Martin 
>>  wrote:
>> Yes. I *think* I have found a better way to check for this and it should be 
>> compatible with debian as well.
>> 
>> BR
>> 
>>> On 6. Sep 2022, at 12:32, madmurphy  wrote:
>>> 
>>> Hi Martin,
>>> 
>>> If "normal" curl is found, the check for curl-gnutls is skipped.
>>> I guess we should prefer curl-gnutls.
>>> Yes, libcurl-gnutls should be checked first. Also because apparently Arch 
>>> is not the only distro that has a split package of cURL linked against GNU 
>>> TLS…
>>> 
>>> --madmurphy
>>> 
>>> 
>>> On Tue, Sep 6, 2022 at 9:59 AM Schanzenbach, Martin 
>>>  wrote:
>>> Ah sorry I just checked:
>>> If "normal" curl is found, the check for curl-gnutls is skipped.
>>> I guess we should prefer curl-gnutls.
>>> 
>>> Br
>>> 
>>>> On 6. Sep 2022, at 10:51, Schanzenbach, Martin  
>>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> check your config.log and check for the test against libcurl-gnutls.
>>>> There should be test somewhere in there that fails for reasons.
>>>> 
>>>> BR
>>>> Martin
>>>> 
>>>>> On 5. Sep 2022, at 20:21, madmurphy  wrote:
>>>>> 
>>>>> Hi Christian,
>>>>> 
>>>>> I tried to run ./configure twice. The first time I had installed on my 
>>>>> machine curl (which is linked against openssl) and gnurl, but I did not 
>>>>> have libcurl-gnutls installed. Under these conditions at the end of the 
>>>>> configure script I got printed:
>>>>> 
>>>>> ...
>>>>> HTTP Client:gnurl
>>>>> ...
>>>>> 
>>>>> The second time I had curl and libcurl-gnutls installed, but gnurl was 
>>>>> not installed. Under these conditions at the end of the configure script 
>>>>> I got printed:
>>>>> 
>>>>> ...
>>>>> HTTP Client:curl-openssl
>>>>> ...
>>>>> 
>>>>> For some reasons in the second scenario the configure script sees the 
>>>>> curl package but does not see libcurl-gnutls and so the latter is not 
>>>>> used (I guess). The files shipped by the latter are:
>>>>> 
>>>>> /usr/
>>>>> /usr/lib/
>>>>> /usr/lib/libcurl-gnutls.so.3
>>>>> /usr/lib/libcurl-gnutls.so.4
>>>>> /usr/lib/libcurl-gnutls.so.4.0.0
>>>>> /usr/lib/libcurl-gnutls.so.4.1.0
>>>>> /usr/lib/libcurl-gnutls.so.4.2.0
>>>>> /usr/lib/libcurl-gnutls.so.4.3.0
>>>>> /usr/lib/libcurl-gnutls.so.4.4.0
>>>>> /usr/lib/libcurl-gnutls.so.4.5.0
>>>>> /usr/lib/libcurl-gnutls.so.4.6.0
>>>>> /usr/lib/libcurl-gnutls.so.4.7.0
>>>>> /usr/lib/libcurl-gnutls.so.4.8.0
>>>>> /usr/share/
>>>>> /usr/share/licenses/
>>>>> /usr/share/licenses/libcurl-gnutls
>>>>> 
>>>>> How can we ensure that the configure script correctly sees the 
>>>>> libcurl-gnutls package?
>>>>> 
>>>>> I paste below b

Re: About GNUrl and cURL

[Schanzenbach, Martin]

> On 6. Sep 2022, at 14:43, madmurphy  wrote:
> 
> Alright, it works now :-)
> 
> HTTP Client:curl-openssl
> Just out of curiosity, why do I get
> 
> gstreamer:  no
> ?
> 

I am assuming you are missing some headers. But I noticed that on our CI as 
well so I will investigate.

> 
> On Tue, Sep 6, 2022 at 11:35 AM Martin Schanzenbach  
> wrote:
> I cleaned up the curl detection in afea0eea1ecfa41150fdf9ee052acac75eee6534 
> (next release 0.17.6).
> Feel free to try.
> It should be a bit more intelligent with respect to curl-gnutls
> detection.
> 
> BR
> 
> Excerpts from Schanzenbach, Martin's message of 2022-09-06 08:59:23 +:
> > Ah sorry I just checked:
> > If "normal" curl is found, the check for curl-gnutls is skipped.
> > I guess we should prefer curl-gnutls.
> >
> > Br
> >
> > > On 6. Sep 2022, at 10:51, Schanzenbach, Martin  
> > > wrote:
> > >
> > > Hi,
> > >
> > > check your config.log and check for the test against libcurl-gnutls.
> > > There should be test somewhere in there that fails for reasons.
> > >
> > > BR
> > > Martin
> > >
> > >> On 5. Sep 2022, at 20:21, madmurphy  wrote:
> > >>
> > >> Hi Christian,
> > >>
> > >> I tried to run ./configure twice. The first time I had installed on my 
> > >> machine curl (which is linked against openssl) and gnurl, but I did not 
> > >> have libcurl-gnutls installed. Under these conditions at the end of the 
> > >> configure script I got printed:
> > >>
> > >> ...
> > >> HTTP Client:gnurl
> > >> ...
> > >>
> > >> The second time I had curl and libcurl-gnutls installed, but gnurl was 
> > >> not installed. Under these conditions at the end of the configure script 
> > >> I got printed:
> > >>
> > >> ...
> > >> HTTP Client:curl-openssl
> > >> ...
> > >>
> > >> For some reasons in the second scenario the configure script sees the 
> > >> curl package but does not see libcurl-gnutls and so the latter is not 
> > >> used (I guess). The files shipped by the latter are:
> > >>
> > >> /usr/
> > >> /usr/lib/
> > >> /usr/lib/libcurl-gnutls.so.3
> > >> /usr/lib/libcurl-gnutls.so.4
> > >> /usr/lib/libcurl-gnutls.so.4.0.0
> > >> /usr/lib/libcurl-gnutls.so.4.1.0
> > >> /usr/lib/libcurl-gnutls.so.4.2.0
> > >> /usr/lib/libcurl-gnutls.so.4.3.0
> > >> /usr/lib/libcurl-gnutls.so.4.4.0
> > >> /usr/lib/libcurl-gnutls.so.4.5.0
> > >> /usr/lib/libcurl-gnutls.so.4.6.0
> > >> /usr/lib/libcurl-gnutls.so.4.7.0
> > >> /usr/lib/libcurl-gnutls.so.4.8.0
> > >> /usr/share/
> > >> /usr/share/licenses/
> > >> /usr/share/licenses/libcurl-gnutls
> > >>
> > >> How can we ensure that the configure script correctly sees the 
> > >> libcurl-gnutls package?
> > >>
> > >> I paste below both complete outputs.
> > >>
> > >> Installed: curl, gnurl
> > >> Not installed: libcurl-gnutls:
> > >>
> > >> $ ./configure
> > >> checking build system type... x86_64-pc-linux-gnu
> > >> checking host system type... x86_64-pc-linux-gnu
> > >> checking target system type... x86_64-pc-linux-gnu
> > >> checking for a BSD-compatible install... /usr/bin/install -c
> > >> checking whether build environment is sane... yes
> > >> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> > >> checking for gawk... gawk
> > >> checking whether make sets $(MAKE)... yes
> > >> checking whether make supports nested variables... yes
> > >> checking whether UID '1000' is supported by ustar format... yes
> > >> checking whether GID '1000' is supported by ustar format... yes
> > >> checking how to create a ustar tar archive... gnutar
> > >> checking whether make supports nested variables... (cached) yes
> > >> checking for gawk... (cached) gawk
> > >> checking for gcc... gcc
> > >> checking whether the C compiler works... yes
> > >> checking for C compiler default output file name... a.out
> > >> checking for suffix of executables...
> > >> checking whether we are cross compiling... no
> > >> checking 

Re: About GNUrl and cURL

[Schanzenbach, Martin]

Yes. I *think* I have found a better way to check for this and it should be 
compatible with debian as well.

BR

> On 6. Sep 2022, at 12:32, madmurphy  wrote:
> 
> Hi Martin,
> 
> If "normal" curl is found, the check for curl-gnutls is skipped.
> I guess we should prefer curl-gnutls.
> Yes, libcurl-gnutls should be checked first. Also because apparently Arch is 
> not the only distro that has a split package of cURL linked against GNU TLS…
> 
> --madmurphy
> 
> 
> On Tue, Sep 6, 2022 at 9:59 AM Schanzenbach, Martin  
> wrote:
> Ah sorry I just checked:
> If "normal" curl is found, the check for curl-gnutls is skipped.
> I guess we should prefer curl-gnutls.
> 
> Br
> 
> > On 6. Sep 2022, at 10:51, Schanzenbach, Martin  
> > wrote:
> >
> > Hi,
> >
> > check your config.log and check for the test against libcurl-gnutls.
> > There should be test somewhere in there that fails for reasons.
> >
> > BR
> > Martin
> >
> >> On 5. Sep 2022, at 20:21, madmurphy  wrote:
> >>
> >> Hi Christian,
> >>
> >> I tried to run ./configure twice. The first time I had installed on my 
> >> machine curl (which is linked against openssl) and gnurl, but I did not 
> >> have libcurl-gnutls installed. Under these conditions at the end of the 
> >> configure script I got printed:
> >>
> >> ...
> >> HTTP Client:gnurl
> >> ...
> >>
> >> The second time I had curl and libcurl-gnutls installed, but gnurl was not 
> >> installed. Under these conditions at the end of the configure script I got 
> >> printed:
> >>
> >> ...
> >> HTTP Client:curl-openssl
> >> ...
> >>
> >> For some reasons in the second scenario the configure script sees the curl 
> >> package but does not see libcurl-gnutls and so the latter is not used (I 
> >> guess). The files shipped by the latter are:
> >>
> >> /usr/
> >> /usr/lib/
> >> /usr/lib/libcurl-gnutls.so.3
> >> /usr/lib/libcurl-gnutls.so.4
> >> /usr/lib/libcurl-gnutls.so.4.0.0
> >> /usr/lib/libcurl-gnutls.so.4.1.0
> >> /usr/lib/libcurl-gnutls.so.4.2.0
> >> /usr/lib/libcurl-gnutls.so.4.3.0
> >> /usr/lib/libcurl-gnutls.so.4.4.0
> >> /usr/lib/libcurl-gnutls.so.4.5.0
> >> /usr/lib/libcurl-gnutls.so.4.6.0
> >> /usr/lib/libcurl-gnutls.so.4.7.0
> >> /usr/lib/libcurl-gnutls.so.4.8.0
> >> /usr/share/
> >> /usr/share/licenses/
> >> /usr/share/licenses/libcurl-gnutls
> >>
> >> How can we ensure that the configure script correctly sees the 
> >> libcurl-gnutls package?
> >>
> >> I paste below both complete outputs.
> >>
> >> Installed: curl, gnurl
> >> Not installed: libcurl-gnutls:
> >>
> >> $ ./configure
> >> checking build system type... x86_64-pc-linux-gnu
> >> checking host system type... x86_64-pc-linux-gnu
> >> checking target system type... x86_64-pc-linux-gnu
> >> checking for a BSD-compatible install... /usr/bin/install -c
> >> checking whether build environment is sane... yes
> >> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> >> checking for gawk... gawk
> >> checking whether make sets $(MAKE)... yes
> >> checking whether make supports nested variables... yes
> >> checking whether UID '1000' is supported by ustar format... yes
> >> checking whether GID '1000' is supported by ustar format... yes
> >> checking how to create a ustar tar archive... gnutar
> >> checking whether make supports nested variables... (cached) yes
> >> checking for gawk... (cached) gawk
> >> checking for gcc... gcc
> >> checking whether the C compiler works... yes
> >> checking for C compiler default output file name... a.out
> >> checking for suffix of executables...
> >> checking whether we are cross compiling... no
> >> checking for suffix of object files... o
> >> checking whether the compiler supports GNU C... yes
> >> checking whether gcc accepts -g... yes
> >> checking for gcc option to enable C11 features... none needed
> >> checking whether gcc understands -c and -o together... yes
> >> checking whether make supports the include directive... yes (GNU style)
> >> checking dependency style of gcc... gcc3
> >> checking whether gcc and cc understand -c and -o together... yes
> >> checking whether ln -s works... yes
> >> checking w

Re: About GNUrl and cURL

[Schanzenbach, Martin]

Ah sorry I just checked:
If "normal" curl is found, the check for curl-gnutls is skipped.
I guess we should prefer curl-gnutls.

Br

> On 6. Sep 2022, at 10:51, Schanzenbach, Martin  
> wrote:
> 
> Hi,
> 
> check your config.log and check for the test against libcurl-gnutls.
> There should be test somewhere in there that fails for reasons.
> 
> BR
> Martin
> 
>> On 5. Sep 2022, at 20:21, madmurphy  wrote:
>> 
>> Hi Christian,
>> 
>> I tried to run ./configure twice. The first time I had installed on my 
>> machine curl (which is linked against openssl) and gnurl, but I did not have 
>> libcurl-gnutls installed. Under these conditions at the end of the configure 
>> script I got printed:
>> 
>> ...
>> HTTP Client:gnurl
>> ...
>> 
>> The second time I had curl and libcurl-gnutls installed, but gnurl was not 
>> installed. Under these conditions at the end of the configure script I got 
>> printed:
>> 
>> ...
>> HTTP Client:curl-openssl
>> ...
>> 
>> For some reasons in the second scenario the configure script sees the curl 
>> package but does not see libcurl-gnutls and so the latter is not used (I 
>> guess). The files shipped by the latter are:
>> 
>> /usr/
>> /usr/lib/
>> /usr/lib/libcurl-gnutls.so.3
>> /usr/lib/libcurl-gnutls.so.4
>> /usr/lib/libcurl-gnutls.so.4.0.0
>> /usr/lib/libcurl-gnutls.so.4.1.0
>> /usr/lib/libcurl-gnutls.so.4.2.0
>> /usr/lib/libcurl-gnutls.so.4.3.0
>> /usr/lib/libcurl-gnutls.so.4.4.0
>> /usr/lib/libcurl-gnutls.so.4.5.0
>> /usr/lib/libcurl-gnutls.so.4.6.0
>> /usr/lib/libcurl-gnutls.so.4.7.0
>> /usr/lib/libcurl-gnutls.so.4.8.0
>> /usr/share/
>> /usr/share/licenses/
>> /usr/share/licenses/libcurl-gnutls
>> 
>> How can we ensure that the configure script correctly sees the 
>> libcurl-gnutls package?
>> 
>> I paste below both complete outputs.
>> 
>> Installed: curl, gnurl
>> Not installed: libcurl-gnutls:
>> 
>> $ ./configure
>> checking build system type... x86_64-pc-linux-gnu
>> checking host system type... x86_64-pc-linux-gnu
>> checking target system type... x86_64-pc-linux-gnu
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for a race-free mkdir -p... /usr/bin/mkdir -p
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether make supports nested variables... yes
>> checking whether UID '1000' is supported by ustar format... yes
>> checking whether GID '1000' is supported by ustar format... yes
>> checking how to create a ustar tar archive... gnutar
>> checking whether make supports nested variables... (cached) yes
>> checking for gawk... (cached) gawk
>> checking for gcc... gcc
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether the compiler supports GNU C... yes
>> checking whether gcc accepts -g... yes
>> checking for gcc option to enable C11 features... none needed
>> checking whether gcc understands -c and -o together... yes
>> checking whether make supports the include directive... yes (GNU style)
>> checking dependency style of gcc... gcc3
>> checking whether gcc and cc understand -c and -o together... yes
>> checking whether ln -s works... yes
>> checking whether make sets $(MAKE)... (cached) yes
>> checking for pkg-config... /usr/bin/pkg-config
>> checking pkg-config is at least version 0.29.2... yes
>> checking how to print strings... printf
>> checking for a sed that does not truncate output... /usr/bin/sed
>> checking for grep that handles long lines and -e... /usr/bin/grep
>> checking for egrep... /usr/bin/grep -E
>> checking for fgrep... /usr/bin/grep -F
>> checking for ld used by gcc... /usr/bin/ld
>> checking if the linker (/usr/bin/ld) is GNU ld... yes
>> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
>> checking the name lister (/usr/bin/nm -B) interface... BSD nm
>> checking the maximum length of command line arguments... 1572864
>> checking how to convert x86_64-pc-linux-gnu file names to 
>> x86_64-pc-linux-gnu format... func_convert_file_noop
>> checking how to convert x86_64-pc-linux-gnu file names to toolchain 
>> format... func_convert_file_noop
>> check

Re: About GNUrl and cURL

[Schanzenbach, Martin]

Hi,

check your config.log and check for the test against libcurl-gnutls.
There should be test somewhere in there that fails for reasons.

BR
Martin

> On 5. Sep 2022, at 20:21, madmurphy  wrote:
> 
> Hi Christian,
> 
> I tried to run ./configure twice. The first time I had installed on my 
> machine curl (which is linked against openssl) and gnurl, but I did not have 
> libcurl-gnutls installed. Under these conditions at the end of the configure 
> script I got printed:
> 
> ...
> HTTP Client:gnurl
> ...
> 
> The second time I had curl and libcurl-gnutls installed, but gnurl was not 
> installed. Under these conditions at the end of the configure script I got 
> printed:
> 
> ...
> HTTP Client:curl-openssl
> ...
> 
> For some reasons in the second scenario the configure script sees the curl 
> package but does not see libcurl-gnutls and so the latter is not used (I 
> guess). The files shipped by the latter are:
> 
> /usr/
> /usr/lib/
> /usr/lib/libcurl-gnutls.so.3
> /usr/lib/libcurl-gnutls.so.4
> /usr/lib/libcurl-gnutls.so.4.0.0
> /usr/lib/libcurl-gnutls.so.4.1.0
> /usr/lib/libcurl-gnutls.so.4.2.0
> /usr/lib/libcurl-gnutls.so.4.3.0
> /usr/lib/libcurl-gnutls.so.4.4.0
> /usr/lib/libcurl-gnutls.so.4.5.0
> /usr/lib/libcurl-gnutls.so.4.6.0
> /usr/lib/libcurl-gnutls.so.4.7.0
> /usr/lib/libcurl-gnutls.so.4.8.0
> /usr/share/
> /usr/share/licenses/
> /usr/share/licenses/libcurl-gnutls
> 
> How can we ensure that the configure script correctly sees the libcurl-gnutls 
> package?
> 
> I paste below both complete outputs.
> 
> Installed: curl, gnurl
> Not installed: libcurl-gnutls:
> 
> $ ./configure
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking target system type... x86_64-pc-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a race-free mkdir -p... /usr/bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether UID '1000' is supported by ustar format... yes
> checking whether GID '1000' is supported by ustar format... yes
> checking how to create a ustar tar archive... gnutar
> checking whether make supports nested variables... (cached) yes
> checking for gawk... (cached) gawk
> checking for gcc... gcc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether the compiler supports GNU C... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to enable C11 features... none needed
> checking whether gcc understands -c and -o together... yes
> checking whether make supports the include directive... yes (GNU style)
> checking dependency style of gcc... gcc3
> checking whether gcc and cc understand -c and -o together... yes
> checking whether ln -s works... yes
> checking whether make sets $(MAKE)... (cached) yes
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.29.2... yes
> checking how to print strings... printf
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking the maximum length of command line arguments... 1572864
> checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu 
> format... func_convert_file_noop
> checking how to convert x86_64-pc-linux-gnu file names to toolchain format... 
> func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for file... file
> checking for objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for dlltool... no
> checking how to associate runtime and link libraries... printf %s\n
> checking for ar... ar
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for sysroot... no
> checking for a working dd... /usr/bin/dd
> checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
> checking for mt... no
> checking if : is a manifest tool... no
> checking for stdio.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for strings.h... yes
> checking for sys/stat.h... yes
> checking for sys/types.h... 

Re: Help - curl must support CURLINFO_TLS_SESSION

[Schanzenbach, Martin]

Hi,

yes this is an issue with a deprecation in the most recent curl release.
This is fixed in git master, I hope. And in the next release.

BR

> On 3. Sep 2022, at 16:15, Nirvin M  wrote:
> 
> Dear GNUnet developers,
> 
> I tried compiling gnunet on latest stable versions of Fedora and Debian, but 
> keep getting the following error
> 
> checking whether libcurl is usable... no
> checking for curl/curl.h... no
> checking for curl_easy_getinfo in -lcurl-gnutls... no
> configure: error: cURL must have a version >= 7.34.0 and must support 
> CURLINFO_TLS_SESSION
> 
> 
> I have libcurl-7.82.0 (and curl 7.82.0) installed but from the documentation 
> here, it looks like the flag CURLINFO_TLS_SESSION has been removed. How do I 
> compile gnunet now with newer versions of cURL?
> 
> Please help.
> 
> Thank you,
> Nirvin
> 



signature.asc
Description: Message signed with OpenPGP

Re: Help needed with compilation

[Schanzenbach, Martin]

Hi Nirvin,

did you follow the instructions and ran

$ ./bootstrap
and
$ ./configure ...
?

If yes, maybe did they fail? If so, you need to fix the error first.
Possibly by installing missing dependencies.

Br
Martin

> On 1. Sep 2022, at 13:20, Nirvin M  wrote:
> 
> Hello GNUnet developers,
> 
> I would like to contribute to GNUnet with the goal of making the UX easy. I'm 
> trying to compile gnunet with the instructions here
> 
> However, `make` command fails with
> 
> make: *** No targets specified and no makefile found.  Stop.
> 
> Can anyone please help with this?
> 
> 
> Thank you,
> Nirvin
> 



signature.asc
Description: Message signed with OpenPGP

Re: Question about tracking files, and Doxygen updates.

[Schanzenbach, Martin]

Merged.

BR
Martin

> On 29. Aug 2022, at 23:22, Willow Liquorice  wrote:
> 
> Right, well, I've cleaned up dev/willow/doxygen_comments and pushed it. It's 
> in a suitable position to be merged; I can resume work on another
> branch.
> 
> I've opened an issue (https://bugs.gnunet.org/view.php?id=7314) where we can 
> coordinate clearing redundant Doxygen comments. It's lighter work now, but a 
> helping hand wouldn't go amiss.
> 
> Best wishes,
>   Willow
> 
> On 28/08/2022 09:06, Schanzenbach, Martin wrote:
>>> On 28. Aug 2022, at 00:20, Willow Liquorice  wrote:
>>> 
>>> My local dev/willow/doxygen is ahead by 27 commits, which can just be 
>>> cherrypicked onto a new branch if that's what needs to be done, but 
>>> extracting gnunet.tag might be a bit tricky if we want to try that.
>>> 
>> No need for that. Even if gnunet.tag is in intermediate commits, that is 
>> fine.
>>> The tagfile is something internal to doxygen, I think it's what allows it 
>>> to track links. Probably best to leave it untracked.
>>> 
>> yea
>>> Looking at the history, it got tracked inadvertently right at the start of 
>>> /dev/willow/doxygen (98fa6eda7). There's a pair of my local commits that 
>>> modify it, too.
>>> 
>>> I can move the progress to a new branch and safely remove those commits, 
>>> but I don't know about how to deal with 98fa6eda7, as it's bundled with a 
>>> lot of other changes. Dealing with it on origin is probably the way to go, 
>>> then (if necessary) I can just pull the changes down as local master HEAD 
>>> is at 69844eac.
>>> 
>>> How does that sound?
>>> 
>> you can just try to merge it into master as well.
>>> I've also got this weird contrib/build-common/ directory that has been 
>>> sitting around untracked in my local repository. Should it be like that?
>>> 
>> I think build-common was removed a few releases ago. you can remove this 
>> folder.
>> BR
>>> Best wishes,
>>> Willow
>>> 
>>> On 27/08/2022 13:01, Schanzenbach, Martin wrote:
>>>>> On 26. Aug 2022, at 23:41, Willow Liquorice  wrote:
>>>>> 
>>>>> Hello again,
>>>>> 
>>>>> I've put a .gitignore in doc/doxygen on my local dev/willow/doxygen, so 
>>>>> the Doxygen output (along with other autogenerated files) doesn't get 
>>>>> tangled up in the git history. Should .gitignore include gnunet.tag too?
>>>> I'm not sure what that file does. But I guess, yes.
>>>>> 
>>>>> I've got a good workflow for stripping redundant doc comments in Neovim. 
>>>>> I've already put a dent in the number of warnings doxygen spits out in 
>>>>> the day or two since I cracked it. There are notes on that workflow in 
>>>>> contrib/warningfilter.py on my local branch.
>>>>> 
>>>>> I also hacked Makefile.am and the doxyfile to automate updating 
>>>>> PROJECT_NUMBER, so you can look forward to that too once I've tidied up
>>>>> the branch. It's a bit inelegant but it gets the job done.
>>>>> 
>>>> Please keep in mind to work on new branches, i.e. not branches I already 
>>>> merged.
>>>> Because they would require a new rebase and I am not sure atm if you 
>>>> branches currently diverge from what is online.
>>>> Thanks!
>>>> BR
>>>>> Best wishes,
>>>>>   Willow
>>>>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Question about tracking files, and Doxygen updates.

[Schanzenbach, Martin]

> On 26. Aug 2022, at 23:41, Willow Liquorice  wrote:
> 
> Hello again,
> 
> I've put a .gitignore in doc/doxygen on my local dev/willow/doxygen, so the 
> Doxygen output (along with other autogenerated files) doesn't get tangled up 
> in the git history. Should .gitignore include gnunet.tag too?

I'm not sure what that file does. But I guess, yes.

> 
> I've got a good workflow for stripping redundant doc comments in Neovim. I've 
> already put a dent in the number of warnings doxygen spits out in the day or 
> two since I cracked it. There are notes on that workflow in 
> contrib/warningfilter.py on my local branch.
> 
> I also hacked Makefile.am and the doxyfile to automate updating 
> PROJECT_NUMBER, so you can look forward to that too once I've tidied up
> the branch. It's a bit inelegant but it gets the job done.
> 

Please keep in mind to work on new branches, i.e. not branches I already merged.
Because they would require a new rebase and I am not sure atm if you branches 
currently diverge from what is online.

Thanks!

BR

> Best wishes,
>   Willow
> 



signature.asc
Description: Message signed with OpenPGP

Re: Commit messages and rebasing

[Schanzenbach, Martin]

Hi Willow,

thank you. I rebased and merged your branches to master

BR
Martin

> On 21. Aug 2022, at 00:05, Willow Liquorice  wrote:
> 
> Hello again,
> 
> I got to tidying up the commit history on dev/willow/gnunet_temp, those 
> changes should be reflected on the remotes. I've also rebased and pushed my 
> Doxygen work.
> 
>   - Willow
> 



signature.asc
Description: Message signed with OpenPGP

Re: gnunet-go R5N

[Schanzenbach, Martin]

> On 18. Aug 2022, at 15:20, Maxime Devos  wrote:
> 
> On 18-08-2022 15:10, Bernd Fix wrote:
> 
>> A new version (v0.1.32) of gnunet-go is availble at 
>> https://git.gnunet.org/gnunet-go.git that should be ready for integration 
>> tests. Some major and minor bugs have been fixed that have escaped attention 
>> before. A lot of code refactoring happened too...
>> 
>> The new README includes a new section on how to run tests yourself; you 
>> might try that yorself. Any feedback on problems or failures welcome.
>> 
>> Cheers, Bernd.
>> 
>> 
> Looking at the README.md, do I understand correctly that gnunet-go listens at 
> the usual /tmp/gnunet-system-runtime/... and that as such applications 
> written with the C implementation of the services in mind can connect to the 
> Go implementation?

Yes. Afair.


>  If so, I'd like to eventually test gnunet-scheme (a (Guile) Scheme 
> implementation of the client libraries, but not the services) against it.
> 
> Greetings,
> Maxime.
> 



signature.asc
Description: Message signed with OpenPGP

Re: LSD uses Google Fonts

[Schanzenbach, Martin]

Thanks I borrowed this solution from you :)

> On 13. Jul 2022, at 09:00, pukkamustard  wrote:
> 
> 
> Hi GNUnet,
> 
> The LSD documents as published at https://lsd.gnunet.org currently use
> Google Fonts. This is due to the default stylesheet used by the xml2rfc
> tool.
> 
> I think there has been some recent discussion about the legality of
> using Google Fonts in Europe. Besides that, I don't think it fits with
> the spirit of the GNUnet project. I suggest not using Google Fonts.
> 
> One way of disabling usage of Google Fonts is to use a custom
> stylesheet. The xml2rfc tool can be supplied a custom stylesheet with
> the `-css` option. I have done this for the ERIS specification:
> 
> https://codeberg.org/eris/spec/commit/f62d7bc04ce89cc259f385b298a3d97c1ab32173
> 
> For LSD, this requires storing a custom stylesheet in every LSD repository.
> 
> Regards,
> pukkamustard
> 



signature.asc
Description: Message signed with OpenPGP

Re: Attacking the documentation monster

[Schanzenbach, Martin]

Hi,

> On 27. Jul 2022, at 19:35, Willow Liquorice  wrote:
> 
> Hello,
> 
> Yeah, I've done quite a bit of work on that front. I believe I used the 
> pandoc method in the end to translate it all to (rough) reST. The conversion 
> isn't perfect: the heading hierarchy is a bit iffy and it completely breaks 
> the index (a blessing and a curse, Sphinx's indexing is a lot more 
> sophisticated so rewriting the index would be desirable anyway).
> 

Ah great. I started with a blank slate and used markdown. I wanted to

1. Weed out and reorganize the docs (The "Installation" chapter is just wrong 
in all kinds of ways)
2. Use Sphinx and ideally, markdown

Both requires quite a lot of manual work.
So, I guess we need to decided on what to proceed.
But if you say that the pandoc result is workable that is fine with me. I think 
there are rst to markdown converters for sphinx as well.

> I wasn't able to submit any of this because I couldn't find a place to sign 
> on the Copyright Assignment.
> 

I am not sure I understand "place". Do you mean you did not know where to sign 
it on the document? (the answer is anywhere)

> The Doxygen tidy-up I was doing has stalled out too, because I couldn't get 
> the neovim macros I wrote for the task to work reliably. They use neovim's 
> LSP integration to find a symbol in the headers, but they rely on cursor 
> placement to do that, and the cursor sometimes misses the symbol. When they 
> work, everything progresses rather quickly because you don't have to wade 
> through the source code.
> 
> I'm not sure how easy it would be to share those macros, if anyone wants to 
> help me debug them, but I can at least share the Lua functions and LSP 
> configuration they use to perform the navigation. Would anyone like to see 
> them?
> 

Sounds like something that may go somewhere into contrib (the lua script/nvim 
config).
For now, I would like to tackle the handbook first.

BR
Martin

> Best wishes,
>   Willow Liquorice
> 
> On 27/07/2022 18:01, Schanzenbach, Martin wrote:
>> Hi,
>> I was wondering if you had started with sphinx/rtd for the handbook already?
>> If not, I have played around with it today and already have migrated some 
>> text and could commit it to gnunet.git or a new repo.
>> That would allow anyone to play around and add content.
>> But if you are already further, I would stop and not do that :)
>> BR
>> Martin
>>> On 24. May 2022, at 23:19, Willow Liquorice  wrote:
>>> 
>>> Ah, you can do it through pandoc. I'll bear that in mind and see about 
>>> adapting it to our repository.
>>> 
>>> On 24/05/2022 22:16, Nikita Ronja Gillmann wrote:
>>>> Hi,
>>>> qemu did this a while back it seems
>>>> On 5/24/22 22:38, Willow Liquorice wrote:
>>>>> As an aside, *does anyone know of any tools to convert TeXinfo to reST*? 
>>>>> This migration is going to be much smoother if there are.
>>>> https://patchwork.kernel.org/project/qemu-devel/patch/20200226113034.6741-19-pbonz...@redhat.com/
>>>>> - Willow
>>>>> 
>>>>> On 24/05/2022 18:01, Christian Grothoff wrote:
>>>>>> The doxygen configuration file in Git just had an ancient version 
>>>>>> number. I've fixed that now. The rest was up-to-date ;-).
>>>>>> 
>>>>>> -Christian
>>>>>> 
>>>>>> On 5/23/22 16:24, Willow Liquorice wrote:
>>>>>>> Just look at https://docs.gnunet.org/doxygen/html/index.html and you'll
>>>>>>> see what I mean.
>>>>>>> 
>>>>>>> - Willow
>>>>>>> 
>>>>>>> On 23/05/2022 15:23, Christian Grothoff wrote:
>>>>>>>> I cannot even find a version number on https://docs.gnunet.org/, so 
>>>>>>>> that's likely not what you are refering to. So where exactly are you 
>>>>>>>> looking to find documentation for 0.11.x? Likely some code to update 
>>>>>>>> some location is not working (or was never written, and someone put 
>>>>>>>> something out manually...).
>>>>>>>> 
>>>>>>>> -Christian
>>>>>>>> 
>>>>>>>> On 5/23/22 16:16, Willow Liquorice wrote:
>>>>>>>>> Alright, doc/sphinx it is.
>>>>>>>>> 
>>>>>>>>> The handbook is already intended for two wildly different audiences, 
>>>>>>>>> what with being both a user's and developer's manual. H

GNUnet services and GNS

[Schanzenbach, Martin]

Hi,

we now publish (some) GNUnet service IPs in GNS through in zone 
000G0047M3HN599H57MPXZK4VB59SWK4M9NRD68E1JQFY3RWAHDMKAPN30.
This will become a default configuration in the upcoming releases.
For now, you can configure it like this:

$ gnunet-config -s gns -o ".gnunet.org" -V 
"000G0047M3HN599H57MPXZK4VB59SWK4M9NRD68E1JQFY3RWAHDMKAPN30"

And resolve names as usual either directly:

$ gnunet-gns -u www.gnunet.org

or (if you have DNS2GNS or NSS configured) just using your applications.

BR
Martin


signature.asc
Description: Message signed with OpenPGP

Re: Attacking the documentation monster

[Schanzenbach, Martin]

Hi,

I was wondering if you had started with sphinx/rtd for the handbook already?
If not, I have played around with it today and already have migrated some text 
and could commit it to gnunet.git or a new repo.
That would allow anyone to play around and add content.
But if you are already further, I would stop and not do that :)

BR
Martin

> On 24. May 2022, at 23:19, Willow Liquorice  wrote:
> 
> Ah, you can do it through pandoc. I'll bear that in mind and see about 
> adapting it to our repository.
> 
> On 24/05/2022 22:16, Nikita Ronja Gillmann wrote:
>> Hi,
>> qemu did this a while back it seems
>> On 5/24/22 22:38, Willow Liquorice wrote:
>>> As an aside, *does anyone know of any tools to convert TeXinfo to reST*? 
>>> This migration is going to be much smoother if there are.
>> https://patchwork.kernel.org/project/qemu-devel/patch/20200226113034.6741-19-pbonz...@redhat.com/
>>> - Willow
>>> 
>>> On 24/05/2022 18:01, Christian Grothoff wrote:
 The doxygen configuration file in Git just had an ancient version number. 
 I've fixed that now. The rest was up-to-date ;-).
 
 -Christian
 
 On 5/23/22 16:24, Willow Liquorice wrote:
> Just look at https://docs.gnunet.org/doxygen/html/index.html and you'll
> see what I mean.
> 
> - Willow
> 
> On 23/05/2022 15:23, Christian Grothoff wrote:
>> I cannot even find a version number on https://docs.gnunet.org/, so 
>> that's likely not what you are refering to. So where exactly are you 
>> looking to find documentation for 0.11.x? Likely some code to update 
>> some location is not working (or was never written, and someone put 
>> something out manually...).
>> 
>> -Christian
>> 
>> On 5/23/22 16:16, Willow Liquorice wrote:
>>> Alright, doc/sphinx it is.
>>> 
>>> The handbook is already intended for two wildly different audiences, 
>>> what with being both a user's and developer's manual. Having the source 
>>> code documentation in one place (and possibly better organised) might 
>>> make it easier to work with, and help keep the Developer's Manual 
>>> up-to-date.
>>> 
>>> On another note, are the online source docs even up to date? The 
>>> indicated version on them is 0.11.x, which is several years gone at 
>>> this point.
>>> 
>>> Best wishes,
>>>  Willow
>>> 
>>> On 23/05/2022 08:39, Christian Grothoff wrote:
 On 5/23/22 00:57, Willow Liquorice wrote:
> Hello again,
> 
> Thanks for the info, good to hear that I've got most of it. Setting 
> up a branch in my local GNUnet repository, to start experimenting 
> with Sphinx, as I write this. Seeing as there's some experience with 
> the software in the project already, where would be the most sensible 
> place to put the root directory? My thinking is either the repository 
> root or the doc folder.
 
 Definitively doc/, I think doc/sphinx/ would be good.
 
> Would it be sensible to migrate to Sphinx throughout the whole GNUnet 
> repository? Breathe (https://www.breathe-doc.org/) could very well 
> make the transition easy, as I think it would allow us to read the 
> Doxygen comments that are already present in the source code.
 
 I'm not sure importing the Doxygen makes sense, that's very different 
 from the main handbook/tutorial/man-pages both in terms of style and 
 audience.
 
 my 2 cents
 
 Christian
 
> Best wishes,
> 
>  Willow Liquorice
> 
> On 22/05/2022 22:27, Christian Grothoff wrote:
>> Hi Willow,
>> 
>> We've been using RST/Sphinx for the GNU Taler documentation, and it 
>> can generate reasonable TeXinfo. From that experience, I'm not 
>> against converting the existing documentation to RST.
>> 
>> As far as finding the documentation, I think you found most of it, 
>> except maybe the RFC-style specs at https://lsd.gnunet.org/.
>> 
>> The handbook is supposed to cover things in depth, with different 
>> chapters for installation (for the various platforms), users (by 
>> application, explaining what each application can do and how to use 
>> it) and developers (by subsystem, explaining how each subsystem is 
>> supposed to work). The man-pages are supposed to be for the 
>> day-to-day usage when someone wants to quickly look up command-line 
>> options. The doxygen is for function-level documentation for 
>> developers-only.  The tutorial is for newbie-developers, and is a 
>> bit dated. Finally, the LSDs are in-depth protocol descriptions for 
>> those wanting to do interoperable (re)implementations.
>> 
>> I hope that answers your 

Re: Packaging problems

[Schanzenbach, Martin]

> On 3. Jun 2022, at 21:44, Christian Grothoff  wrote:
> 
> Having many packages doesn't usually make it easier for packagers, it just 
> means that now they have to deal with even more sources, and create more 
> package specifications. Moreover, build times go up, as you now need to run 
> configure many times. Worse, you then need to find out in which order to 
> build things, and what are dependencies. It basically makes it worse in all 
> aspects.

Well. I would think this suggests a very badly designed packaging tool.
Even the extremely old RPM format allows to build once and then make packages 
from any subset of the built binaries.
That is how our gnunet rpm in the tree works.

> 
> Another big issue is that right now, I at least notice if I break the build 
> of an application and can fix it. Same if I run analysis tools: they at least 
> get to see the entire codebase, and can warn us if something breaks. If we 
> move those out-of-tree, they'll be even more neglected. What we can (and do 
> do) is mark really badly broken applications as 'experimental' and require 
> --with-experimental to build those. That's IMO better than moving stuff out 
> of tree.
> 

That is the big issue I agree.

BR

> Also, you probably don't want to split things as you proposed: GNS depends on 
> VPN and SETU! SET is supposed to become obsolete, but consensus still needs 
> it until SETU is extended to match the SET capabilities.
> 
> Finally, as for build times, have you even tried 'make -j 16' or something 
> like that? Multicore rules ;-).
> 
> Happy hacking!
> 
> Christian
> 
> 
> On 6/2/22 17:29, Willow Liquorice wrote:
>> Right. Perhaps the onus is on the developers (i.e. us) to make things a bit 
>> easier, then?
>> To be honest, I barely understand how the GNUnet project is put together on 
>> a source code level, let alone how packaging is done. One of the things I'm 
>> going to do with the Sphinx docs is provide a high-level overview of how the 
>> main repo is structured.
>> On the subject of complexity, I attempted to disentangle that awful internal 
>> dependency graph a while ago, to get a better idea of how GNUnet works. I 
>> noticed that it's possible to divide the subsystems up into closely-related 
>> groups:
>> * a "backbone" (CADET, DHT, CORE, and friends),
>> * a VPN suite,
>> * a GNS suite,
>> * and a set operations suite (SET, SETI, SETU).
>> A bunch of smaller "application layer" things (psyc+social+secushare, 
>> conversation, fs, secretsharing+consensus+voting) then rest on top of one or 
>> more of those suites.
>> I seem to recall that breaking up the main repo has been discussed before, 
>> and I think it got nowhere because no agreement was reached on where the 
>> breaks should be made. My position is that those "applications" (which, 
>> IIRC, are in various states of "barely maintained") should be moved to their 
>> own repos, and the main repo be broken up into those four software suites.
>> As Maxime says, GNUnet takes a long time to compile (when it actually does - 
>> I'm having problems with that right now), and presumably quite a while to 
>> test too. The obvious way to reduce those times is to simply *reduce the 
>> amount of code being compiled and tested*. Breaking up the big repo would 
>> achieve that quite nicely.
>> More specifically related to packaging, would it be a good idea to look into 
>> CD (Continuous Delivery) to complement our current CI setup? It could make 
>> things easier on package maintainers. Looks like Debian has a CI system we 
>> might be able to make use of, and all we'd need to do is point out the test 
>> suite in the package that goes to the Debian archive.
> 



signature.asc
Description: Message signed with OpenPGP

Re: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET

[Schanzenbach, Martin]

We could just always move it to UTC+1 (=CET) while we are at it.

> On 26. Apr 2022, at 18:37, hyazin...@emailn.de wrote:
> 
> *sigh* CEST—summer time—of course, not CET.
> Sorry for that. I have put better measures in place for avoiding this mistake 
> in the future.
> 
> --- Ursprüngliche Nachricht ---
> Von: 
> Datum: 26.04.2022 18:10:16
> An: gnunet-developers@gnu.org
> Betreff: GNUnet Monthly Meeting Sunday, 1st May, 8 PM CET
> 
>> Dear all,
>> 
>> quick reminder for our monthly meeting on
>> 
>> Sunday, 1st May, 8 PM CET
>> 
>> on mumble server: gnunet.org
>> 
>> everyone is very invited!
>> 
>> Pad for meeting minutes and possible agenda:
>> 
>> https://pep.pad.foebud.org/GNUnet-jour-fixe
>> 
>> Cheers
>> 
>> Bastian Schmidt
>> 
>> 
>> 
>> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: gnunet-rest-server shutdown issues

[Schanzenbach, Martin]

Did the output "Shutting down..." appear before or after the normal
shutdown trigger (ctrl-c or gnunet-arm -e)?
If it appeared with the normal shutdown, then I really don't know.
According to the pkill log there is another select happening before the SIGKILL,
but I cannot see where this is coming from. The cleanup logic looks ok.

If the log message appears after the SIGKILL then I need to investigate a bit 
further,
but it may be a signal handler issue.

BR

> On 11. Apr 2022, at 13:46, Nikita Ronja Gillmann  wrote:
> 
> Hi,
> 
> Schanzenbach, Martin transcribed 4.0K bytes:
>> You can try stopping the rest service
>> 
>> $ gnunet-arm -k rest
> 
> here it continued running, for whatever reason.
> No return from gnunet-arm -k rest.
> 
>> 
>> and then starting it manually through the server binary.
>> Then try to ctrl-c it.
>> 
>> If that also does not work, maybe look at the output there.
> 
> the output did not provide any useful insights.
> I did a couple of runs, but in both I had to pkill rest-server.
> 
>> If there is not output, I am pretty lost.
>> Should ctrl-c work, then something odd is going on with the signals from arm?
> 
> CTRL-C didn't work.
> Would the two kdump logs I did for this help?
> 
>> 
>> BR
>> 
>>> On 11. Apr 2022, at 09:06, Nikita Ronja Gillmann  wrote:
>>> 
>>> The hang produces no DEBUG infos, all I get for that (when stopping
>>> the user service) is, in addition to what I posted:
>>> 
>>> 2022-04-11T09:04:32.426431+0200 arm-2811 WARNING Service `rest' terminated 
>>> with status signal/9, will restart in 1 ms
>>> 
>>> which is expected as I kill with -9.
>>> 
>>> Nikita Ronja Gillmann transcribed 1.8K bytes:
>>>> Thanks.
>>>> 
>>>> Possibly related, with explanation ahead:
>>>> 
>>>> I'm still debugging the service layout I have.
>>>> /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which
>>>> runs the system service).
>>>> system user logs go into /var/chroot/gnunet/cache,
>>>> hostlist, topology into /var/chroot/gnunet/.config,
>>>> and all the rest into /var/chroot/gnunet/data.
>>>> 
>>>> The service I start for my user (and the user services)
>>>> has no read access to this directory.
>>>> What problems could cause that?
>>>> Should I solve this differently, or is a change like
>>>> a gnunet:gnunetdns as owner for /var/chroot/gnunet
>>>> and adding my user to gnunetdns enough (or no changes
>>>> and just adding to gnunet group) enough?
>>>> 
>>>> $/HOME/.cache/gnunet/gnunet-2022-04-11.log
>>>> 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at 
>>>> sq_result_helper.c:180.
>>>> 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at 
>>>> plugin_namestore_sqlite.c:537.
>>>> 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at 
>>>> gnunet-service-namestore.c:1949.
>>>> 
>>>> looks like there is some issue related to accessing information?
>>>> 
>>>> Schanzenbach, Martin transcribed 1.9K bytes:
>>>>> Hi,
>>>>> 
>>>>> this is not a known bug and it would be very odd if the REST API is not 
>>>>> even used.
>>>>> 
>>>>> So yes, debug logs would be helpful.
>>>>> 
>>>>> BR
>>>>> 
>>>>>> On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> in my system service I have a pill + kill for gnunet-rest-server,
>>>>>> as this process seems to not react to gnunet-arm -e.
>>>>>> 
>>>>>> I am not sure how to debug this. look at loglevel DEBUG logs?
>>>>>> It seems like a bug to me when this prevents a normal shutdown
>>>>>> of gnunet.
>>>>>> 
>>>>>> This is via the user process, not the system process run as the
>>>>>> system user "gnunet".
>>>>>> 
>>>>>> Any clues before I sent in logs? Is this is a known bug?
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: gnunet-rest-server shutdown issues

[Schanzenbach, Martin]

You can try stopping the rest service

$ gnunet-arm -k rest

and then starting it manually through the server binary.
Then try to ctrl-c it.

If that also does not work, maybe look at the output there.
If there is not output, I am pretty lost.
Should ctrl-c work, then something odd is going on with the signals from arm?

BR

> On 11. Apr 2022, at 09:06, Nikita Ronja Gillmann  wrote:
> 
> The hang produces no DEBUG infos, all I get for that (when stopping
> the user service) is, in addition to what I posted:
> 
> 2022-04-11T09:04:32.426431+0200 arm-2811 WARNING Service `rest' terminated 
> with status signal/9, will restart in 1 ms
> 
> which is expected as I kill with -9.
> 
> Nikita Ronja Gillmann transcribed 1.8K bytes:
>> Thanks.
>> 
>> Possibly related, with explanation ahead:
>> 
>> I'm still debugging the service layout I have.
>> /var/chroot/gnunet is the $HOME of the 'gnunet' system user (which
>> runs the system service).
>> system user logs go into /var/chroot/gnunet/cache,
>> hostlist, topology into /var/chroot/gnunet/.config,
>> and all the rest into /var/chroot/gnunet/data.
>> 
>> The service I start for my user (and the user services)
>> has no read access to this directory.
>> What problems could cause that?
>> Should I solve this differently, or is a change like
>> a gnunet:gnunetdns as owner for /var/chroot/gnunet
>> and adding my user to gnunetdns enough (or no changes
>> and just adding to gnunet group) enough?
>> 
>> $/HOME/.cache/gnunet/gnunet-2022-04-11.log
>> 2022-04-11T08:17:11.373925+0200 namestore-656 ERROR Assertion failed at 
>> sq_result_helper.c:180.
>> 2022-04-11T08:17:11.374183+0200 namestore-656 ERROR Assertion failed at 
>> plugin_namestore_sqlite.c:537.
>> 2022-04-11T08:17:11.374232+0200 namestore-656 ERROR Assertion failed at 
>> gnunet-service-namestore.c:1949.
>> 
>> looks like there is some issue related to accessing information?
>> 
>> Schanzenbach, Martin transcribed 1.9K bytes:
>>> Hi,
>>> 
>>> this is not a known bug and it would be very odd if the REST API is not 
>>> even used.
>>> 
>>> So yes, debug logs would be helpful.
>>> 
>>> BR
>>> 
>>>> On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> in my system service I have a pill + kill for gnunet-rest-server,
>>>> as this process seems to not react to gnunet-arm -e.
>>>> 
>>>> I am not sure how to debug this. look at loglevel DEBUG logs?
>>>> It seems like a bug to me when this prevents a normal shutdown
>>>> of gnunet.
>>>> 
>>>> This is via the user process, not the system process run as the
>>>> system user "gnunet".
>>>> 
>>>> Any clues before I sent in logs? Is this is a known bug?
>>>> 
>>> 
>> 
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: GNUnet Name System not working (as expected)

[Schanzenbach, Martin]

> On 11. Apr 2022, at 09:13, Tanguy LE CARROUR  wrote:
> 
> Hi Martin,
> 
> 
> Quoting Schanzenbach, Martin (2022-04-09 10:27:56)
>>> On 8. Apr 2022, at 16:02, Tanguy LE CARROUR  wrote:
>>> Quoting Nikita Ronja Gillmann (2022-04-08 12:29:43)
>>>> Tanguy LE CARROUR transcribed 6.2K bytes:
>>>>> […]
>>>>> 2022-04-07T17:14:01.005084+0200 nat-29505 ERROR UPnP enabled in 
>>>>> configuration, but UPnP client `upnpc` command not found, disabling UPnP
>>>> 
>>>> I assume that you have upnpc(-mini?) as dependency in the guix package.
>>>> When you look at the C code in src/nat/ you'll see 2 files which you
>>>> need to patch for them to work for Guix (same applies for the cases
>>>> where iptables, ip6tables, and ip binaries are used).
>>> 
>>> Correct. `miniupnpc` is an `input`, not a `propagated-input`,
>>> so I will have to patch the files using it. Thanks for pointing out!
>>> 
>>> I'll submit a patch for the package definition.
>>> 
>>> In the meantime, I installed `miniupnpc` to make it available for `gnunet`
>>> to use… unfortunately, I now have the following warning:
>>> 
>>> ```
>>> 2022-04-08T15:50:35.608148+0200 nat-16852 WARNING upnpc failed to create 
>>> port mapping
>>> 2022-04-08T15:50:35.608229+0200 nat-16852 WARNING upnpc failed to create 
>>> port mapping
>>> ```
>>> 
>>> But, I guess, WARNING is better than ERROR! :-)
>> 
>> upnp only works if your router supports it and it is enabled on the router.
>> (you often get a big warning when enabling it on the router)
> 
> Correct (again)! I activated UPNP on my box and the error disappeared.
> But, I cannot do the same on my other computer because I have no control
> over the "box" and cannot forward ports!
> 
> Does this mean that I cannot use GNUnet on this computer?!

It just means that NAT will not work. So, you will be able to connect to other 
peers,
but other peers will not be able to initiate a connection to your peer.
There are other methods to do NAT apart from upnp including a manual 
configuration.
This will improve in the next iteration of NAT and TNG.

> 
> This gets me back to the question: would it be possible to provide a
> public test zone for people testing GNUnet with only one computer?!
> 
> Regards,
> 
> --
> Tanguy



signature.asc
Description: Message signed with OpenPGP

Re: gnunet-rest-server shutdown issues

[Schanzenbach, Martin]

Hi,

this is not a known bug and it would be very odd if the REST API is not even 
used.

So yes, debug logs would be helpful.

BR

> On 10. Apr 2022, at 22:31, Nikita Ronja Gillmann  wrote:
> 
> Hi,
> 
> in my system service I have a pill + kill for gnunet-rest-server,
> as this process seems to not react to gnunet-arm -e.
> 
> I am not sure how to debug this. look at loglevel DEBUG logs?
> It seems like a bug to me when this prevents a normal shutdown
> of gnunet.
> 
> This is via the user process, not the system process run as the
> system user "gnunet".
> 
> Any clues before I sent in logs? Is this is a known bug?
> 



signature.asc
Description: Message signed with OpenPGP

Re: mysql check always fails

[Schanzenbach, Martin]

Hi,

I pushed this fix.

BR


> On 9. Apr 2022, at 11:33, Nikita Ronja Gillmann  wrote:
> 
> Hi,
> 
> for some reason I can't open an account at the bug tracker.
> The issue is a one character problem:
> https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/patches/patch-configure;h=ff56f7067812362ff4f0de0b8276e02119aa5479;hb=HEAD
> 
> where #include 
> should be, configure.ac has
> include 
> 
> So in a packaging environment where you pass
> --with-mysql=/mysql/prefix/ you get a detected
> mysql, but the version check fails. Which leads
> to <= 4.x being assumed, and therefore mysql isn't
> picked up by configure.
> 
> https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob;f=gnunet/options.mk;h=821017177ceb47baaee6f41378b81e8da55ce278;hb=HEAD#l80
> 
> This happens with mysql-client 8.0.24.
> 
> The patch I use fixes the version detection for me.
> 
> Schanzenbach, Martin transcribed 2.6K bytes:
>> Can anyone of you open a bug report for this with a description.
>> From the mails I do not understand the problem beyond "the check does not 
>> work".
>> I can look at it next week.
>> 
>> BR
>> Martin
>> 
>>> On 8. Apr 2022, at 10:04, Nikita Ronja Gillmann  wrote:
>>> 
>>> Daniel Golle transcribed 0.7K bytes:
>>>> Hi Nikita,
>>>> 
>>>> On Fri, Apr 08, 2022 at 09:12:29AM +0200, Nikita Ronja Gillmann wrote:
>>>>> Hi,
>>>>> 
>>>>> I have no time to work on a patch for this, but even with the right 
>>>>> version of mysql(-client) (version => 8.0.24),
>>>>> configure.ac generates a configure file which leads to broken C code for 
>>>>> what applies for my builds (--with-mysql=PRFX).
>>>>> I have attached the files.
>>>> 
>>>> Just to confirm your findings:
>>>> I've also encountered this problem when building recent GNUnet releases
>>>> for OpenWrt and have decided to simply drop the version check (as in
>>>> this case I just know the version is recent enough):
>>> 
>>> thanks. I still think that fixing 1 character would be better.
>>> last time moved/touched in 2021, and I've seen this error for
>>> some versions now as well in pkgsrc:
>>> 20ffa0aa54 (Alessio Vanni2021-11-11 00:56:30 +0100 1032)  
>>> [[include ]],
>>> 
>>>> https://github.com/openwrt/packages/blob/master/net/gnunet/patches/100-remove-mysql-version-check.patch
>>>> 
>>>> 
>>>> Cheers
>>>> 
>>>> 
>>>> Daniel
>> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: mysql check always fails

[Schanzenbach, Martin]

Can anyone of you open a bug report for this with a description.
From the mails I do not understand the problem beyond "the check does not work".
I can look at it next week.

BR
Martin

> On 8. Apr 2022, at 10:04, Nikita Ronja Gillmann  wrote:
> 
> Daniel Golle transcribed 0.7K bytes:
>> Hi Nikita,
>> 
>> On Fri, Apr 08, 2022 at 09:12:29AM +0200, Nikita Ronja Gillmann wrote:
>>> Hi,
>>> 
>>> I have no time to work on a patch for this, but even with the right version 
>>> of mysql(-client) (version => 8.0.24),
>>> configure.ac generates a configure file which leads to broken C code for 
>>> what applies for my builds (--with-mysql=PRFX).
>>> I have attached the files.
>> 
>> Just to confirm your findings:
>> I've also encountered this problem when building recent GNUnet releases
>> for OpenWrt and have decided to simply drop the version check (as in
>> this case I just know the version is recent enough):
> 
> thanks. I still think that fixing 1 character would be better.
> last time moved/touched in 2021, and I've seen this error for
> some versions now as well in pkgsrc:
> 20ffa0aa54 (Alessio Vanni2021-11-11 00:56:30 +0100 1032)  
> [[include ]],
> 
>> https://github.com/openwrt/packages/blob/master/net/gnunet/patches/100-remove-mysql-version-check.patch
>> 
>> 
>> Cheers
>> 
>> 
>> Daniel



signature.asc
Description: Message signed with OpenPGP

Re: GNUnet Name System not working (as expected)

[Schanzenbach, Martin]

> On 8. Apr 2022, at 16:02, Tanguy LE CARROUR  wrote:
> 
> Hi Nikita,
> 
> 
> Quoting Nikita Ronja Gillmann (2022-04-08 12:29:43)
>> Tanguy LE CARROUR transcribed 6.2K bytes:
>>> Hello GNUnet,
>>> 
>>> I'm not reporting this into the bug tracker (yet), because (good) chances
>>> are the problem exists between the chair and keyboard…
>>> 
>>> ```
>>> 2022-04-07T17:14:00.996911+0200 peerstore-sqlite-29500 ERROR Error 
>>> executing SQL query: attempt to write a readonly database
>>>  PRAGMA auto_vacuum=INCREMENTAL
>>> 2022-04-07T17:14:00.997101+0200 peerstore-sqlite-29500 ERROR `sqlite3_step' 
>>> failed at plugin_peerstore_sqlite.c:211 with error: attempt to write a 
>>> readonly database
>> 
>> Where is the $HOME of the gnunet user? Is it writeable for you?
> 
> *ERF* the `sqlite.db` belonged to another user and was created… back
> in 2020!? O_o'

Yes. It is also my impression from the logs that the sqlite database is a 
problem.
It seems to be readonly for whatever reason. Try deleting it?

BR

> 
> 
>>> 2022-04-07T17:14:00.997124+0200 sqlite-29500 ERROR Failed to reset sqlite 
>>> statement with error: attempt to write a readonly database
>>> 2022-04-07T17:14:00.999847+0200 namestore-29495 ERROR Assertion failed at 
>>> sq_result_helper.c:180.
>>> 2022-04-07T17:14:00.999877+0200 namestore-29495 ERROR Assertion failed at 
>>> plugin_namestore_sqlite.c:537.
>>> 2022-04-07T17:14:00.999891+0200 namestore-29495 ERROR Assertion failed at 
>>> gnunet-service-namestore.c:1949.
>>> 2022-04-07T17:14:01.000896+0200 transport-tcp-29503 WARNING Unexpected 
>>> address length: 24 bytes
>>> 2022-04-07T17:14:01.000925+0200 transport-29503 ERROR Assertion failed at 
>>> gnunet-service-transport_validation.c:902.
>>> 2022-04-07T17:14:01.000932+0200 transport-29503 ERROR Address with 24 bytes 
>>> for plugin tcp and peer DSTJ is malformed
>>> 2022-04-07T17:14:01.000938+0200 transport-tcp-29503 WARNING Unexpected 
>>> address length: 12 bytes
>>> 2022-04-07T17:14:01.000942+0200 transport-29503 ERROR Assertion failed at 
>>> gnunet-service-transport_validation.c:902.
>>> 2022-04-07T17:14:01.000947+0200 transport-29503 ERROR Address with 12 bytes 
>>> for plugin tcp and peer DSTJ is malformed
>>> 2022-04-07T17:14:01.001095+0200 transport-tcp-29503 WARNING Unexpected 
>>> address length: 24 bytes
>>> 2022-04-07T17:14:01.001105+0200 transport-29503 ERROR Assertion failed at 
>>> gnunet-service-transport_validation.c:902.
>>> 2022-04-07T17:14:01.001110+0200 transport-29503 ERROR Address with 24 bytes 
>>> for plugin tcp and peer V8XX is malformed
>>> 2022-04-07T17:14:01.001114+0200 transport-tcp-29503 WARNING Unexpected 
>>> address length: 12 bytes
>>> 2022-04-07T17:14:01.001118+0200 transport-29503 ERROR Assertion failed at 
>>> gnunet-service-transport_validation.c:902.
>>> 2022-04-07T17:14:01.001125+0200 transport-29503 ERROR Address with 12 bytes 
>>> for plugin tcp and peer V8XX is malformed
>>> 2022-04-07T17:14:01.005084+0200 nat-29505 ERROR UPnP enabled in 
>>> configuration, but UPnP client `upnpc` command not found, disabling UPnP
>> 
>> I assume that you have upnpc(-mini?) as dependency in the guix package.
>> When you look at the C code in src/nat/ you'll see 2 files which you
>> need to patch for them to work for Guix (same applies for the cases
>> where iptables, ip6tables, and ip binaries are used).
> 
> Correct. `miniupnpc` is an `input`, not a `propagated-input`,
> so I will have to patch the files using it. Thanks for pointing out!
> 
> I'll submit a patch for the package definition.
> 
> In the meantime, I installed `miniupnpc` to make it available for `gnunet`
> to use… unfortunately, I now have the following warning:
> 
> ```
> 2022-04-08T15:50:35.608148+0200 nat-16852 WARNING upnpc failed to create port 
> mapping
> 2022-04-08T15:50:35.608229+0200 nat-16852 WARNING upnpc failed to create port 
> mapping
> ```
> 
> But, I guess, WARNING is better than ERROR! :-)
> 
> Cheers,
> 
> --
> Tanguy
> 



signature.asc
Description: Message signed with OpenPGP

Re: gnurl CVE applicability

[Schanzenbach, Martin]

> On 4. Apr 2022, at 17:35, Mikhail  wrote:
> 
> On Mon, Apr 04, 2022 at 05:14:53PM +0200, Christian Grothoff wrote:
>> On 4/4/22 17:09, Nikita Ronja Gillmann wrote:
>>> 
 
 Regardless, you should be able to build GNUnet against vanilla
 libcurl these days, so that might be a better way to avoid worrying
 about this.
>>> 
>>> In the context of pkgsrc, the problem is that I can not enforce a change
>>> of setting in curl (for example built against gnutls) for the defaults.
>>> Or maybe you can explain how a gnunet built against curl and gnurl would
>>> differ these days in terms of functionality and features.
>> 
>> Ah, I see. Well, yes, non-gnutls curl is likely still going to cause grief
>> for some parts of GNUnet...
> 
> README says that libgnurl is recommended, but I think in OpenBSD I will
> must use libcurl linked to libressl.
> 
> I was thinking about porting libgnurl, but I suppose it won't find any
> support from OpenBSD committers, because this library can be viewed
> as potential new attack surface, and we will need to support security
> incidents for both, libcurl and libgnurl, and libgnurl site says:
> 
>> gnurl/libgnurl is looking for a new maintainer
> 
> which means new versions of libgnurl probably will lag behind libcurl in
> matter of security incidents.
> 
> Does non-gnutls curl brings some disasters to GNUnet?
> 

The GNS proxy does not work with openssl.
It tries to verify certificates through TLSA records when possible.
And this does not work properly with curl openssl.
No gnutls odd behaviour, I think.
Everything else should just work with curl as well including GNS (without the 
proxy).

BR


signature.asc
Description: Message signed with OpenPGP

Re: gnurl CVE applicability

[Schanzenbach, Martin]

> On 4. Apr 2022, at 17:14, Christian Grothoff  wrote:
> 
> On 4/4/22 17:09, Nikita Ronja Gillmann wrote:
>>> 
>>> Regardless, you should be able to build GNUnet against vanilla libcurl 
>>> these days, so that might be a better way to avoid worrying about this.
>> In the context of pkgsrc, the problem is that I can not enforce a change of 
>> setting in curl (for example built against gnutls) for the defaults.
>> Or maybe you can explain how a gnunet built against curl and gnurl would 
>> differ these days in terms of functionality and features.
> 
> Ah, I see. Well, yes, non-gnutls curl is likely still going to cause grief 
> for some parts of GNUnet...
> 

Well afair it only does for the gns proxy. So you may simply not 
install/package that and link against vanilla curl.

BR


signature.asc
Description: Message signed with OpenPGP

Re: openbsd - gnunet warnings in logs

[Schanzenbach, Martin]

Hi,

> On 4. Apr 2022, at 12:32, Mikhail  wrote:
> 
> I've installed latest in git (60e93b8f0) on the OS, I didn't use
> --prefix, so installation has gone to default /usr/local, when I run
> gnunet-peerinfo I see several types of warnings in the logs.
> 
> I'd like to package gnunet for OpenBSD, but first I need to understand
> that the application is working properly and usable for end users, I'll
> be definitely asked by OpenBSD committers about those warnings and if
> they are critical to general availability of the service of gnunet.
> 

If you get core connections (gnunet-core shows at least one connection)
and "gnunet-arm -I" does not show any failed services you are pretty much
good to go (for now).

> Also 'make check' has 1 test failed, I sent email to bug-gnunet@ about
> it.

I tried to reproduce it yesterday, but I did not get gnunet to compile at all 
for some
reason and gave up :(

> 
> Can you prompt me if the warnings are critical, or they can be ignored?
> 
> The type of warnings:
> 
>> WARNING Failed to find plugin `http_client'
>> WARNING Failed to find plugin `https_client'
>> WARNING Failed to find plugin `udp'

Those warnings are FINE. It means that you have found a peer with
an endpoint (e.g. udp) that you have not configured for your peer.
see

$ gnunet-config -s transport -o PLUGINS

The default is that only TCP is loaded.

> but at least http and https plugins are there:
> 
> ec2-user:/usr/local/lib/gnunet:324$ f http_client
> ./libgnunet_plugin_transport_http_client.so
> ./libgnunet_plugin_transport_http_client.la
> ec2-user:/usr/local/lib/gnunet:325$ f https_client
> ./libgnunet_plugin_transport_https_client.so
> ./libgnunet_plugin_transport_https_client.la
> 
> for 'udp' I get something different:
> 
> ec2-user:/usr/local/lib/gnunet:331$ f udp
> ./libexec/gnunet-communicator-udp
> ./libgnunet_test_transport_plugin_cmd_udp_backchannel.so
> ./libgnunet_test_transport_plugin_cmd_udp_backchannel.la
> 
> Also I'm interested in following warning, which I see quiet often:
> 
>> WARNING Processing code for message of type 367 did not call 
>> `GNUNET_SERVICE_client_continue' after 1 m
> 
> The full log:
> 
> 2022-04-04T10:18:19.865427+ nat-19169 ERROR UPnP enabled in 
> configuration, but UPnP client `upnpc` command not found, disabling UPnP
> 2022-04-04T10:18:19.924010+ transport-tcp-91112 WARNING Unexpected 
> address length: 24 bytes
> 2022-04-04T10:18:19.924406+ transport-91112 ERROR Assertion failed at 
> gnunet-service-transport_validation.c:902.
> 2022-04-04T10:18:19.924442+ transport-91112 ERROR Address with 24 bytes 
> for plugin tcp and peer DSTJ is malformed
> 2022-04-04T10:18:19.924467+ transport-tcp-91112 WARNING Unexpected 
> address length: 12 bytes
> 2022-04-04T10:18:19.924488+ transport-91112 ERROR Assertion failed at 
> gnunet-service-transport_validation.c:902.
> 2022-04-04T10:18:19.924508+ transport-91112 ERROR Address with 12 bytes 
> for plugin tcp and peer DSTJ is malformed
> 2022-04-04T10:18:19.925709+ transport-tcp-91112 WARNING Unexpected 
> address length: 24 bytes
> 2022-04-04T10:18:19.925735+ transport-91112 ERROR Assertion failed at 
> gnunet-service-transport_validation.c:902.
> 2022-04-04T10:18:19.925756+ transport-91112 ERROR Address with 24 bytes 
> for plugin tcp and peer V8XX is malformed
> 2022-04-04T10:18:19.925779+ transport-tcp-91112 WARNING Unexpected 
> address length: 12 bytes
> 2022-04-04T10:18:19.925799+ transport-91112 ERROR Assertion failed at 
> gnunet-service-transport_validation.c:902.
> 2022-04-04T10:18:19.925818+ transport-91112 ERROR Address with 12 bytes 
> for plugin tcp and peer V8XX is malformed
> 2022-04-04T10:18:42.864454+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.868543+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.880047+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.880289+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.880337+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.882589+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.882777+ transport-91112 WARNING Failed to find plugin 
> `https_client'
> 2022-04-04T10:18:42.882850+ transport-91112 WARNING Failed to find plugin 
> `https_client'
> 2022-04-04T10:18:42.882890+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.882929+ transport-91112 WARNING Failed to find plugin 
> `http_client'
> 2022-04-04T10:18:42.882973+ transport-tcp-91112 WARNING Unexpected 
> address length: 24 bytes
> 2022-04-04T10:18:42.883019+ transport-tcp-91112 WARNING Unexpected 
> address length: 12 bytes
> 2022-04-04T10:18:42.883167+ transport-91112 WARNING Failed to find plugin 
> `udp'
> 2022-04-04T10:18:42.883207+ 

Re: compiling gnunet 0.16.3 on openbsd

[Schanzenbach, Martin]

Yes. The IP DHT underlay implementation is simply not portable.
I just commited a fix to not built it for openbsd.

BR

> On 1. Apr 2022, at 09:30, Nikita Ronja Gillmann  wrote:
> 
> Hi,
> 
> PK_PKTINFO with a quick search seems to be implemented in NetBSD (turns up on 
> my system, never ran into this issue) and FreeBSD.
> OpenBSD had discussions in 2001, and fast-forward to 2016 it is not 
> implemented according to the Changelog of their usr/sbin/unbound:
> https://github.com/openbsd/src/blob/master/usr.sbin/unbound/doc/Changelog#L4522
> 
> Maybe this also holds a solution on how to solve this for gnunet.
> 
> On 4/1/22 09:05, Mikhail wrote:
>> On Thu, Mar 31, 2022 at 06:58:55PM +, Schanzenbach, Martin wrote:
>>> Hi Mikhail,
>>> 
>>> I just pushed some portability fixes to git master.
>>> I tried in a VM (with gcc, however) and it builds for me now on openbsd.
>>> Can you try again?
>>> It seems to me as if you are missing something in your toolchain.
>>> Maybe libtool? Can you check that you have installed all dependencies?
>> Yes, latest git started to build fine (clang 13), no 'srcdir' configure
>> hack is needed, but it failed to compile because of IP_PKTINFO being not
>> implemented.
>> 
>> I'm not sure what 'dhtu' module is doing, googling gives no answer - is
>> it possible to disable it?
>> 
>> 
>> Making all in dhtu
>>   CC   testing_dhtu_cmd_send.lo
>>   CCLD libgnunettestingdhtu.la
>>   CC   plugin_dhtu_gnunet.lo
>>   CCLD libgnunet_plugin_dhtu_gnunet.la
>>   CC   plugin_dhtu_ip.lo
>> plugin_dhtu_ip.c:857:37: error: use of undeclared identifier 'IP_PKTINFO'
>> (cmsg->cmsg_type == IP_PKTINFO),
>> ^
>> plugin_dhtu_ip.c:860:30: error: use of undeclared identifier 'IP_PKTINFO'
>>  (cmsg->cmsg_type == IP_PKTINFO) )
>>  ^
>> plugin_dhtu_ip.c:862:21: error: invalid application of 'sizeof' to an 
>> incomplete type 'struct in_pktinfo'
>>   if (CMSG_LEN (sizeof (struct in_pktinfo)) ==
>> ^  ~~~
>> /usr/include/sys/socket.h:546:58: note: expanded from macro 'CMSG_LEN'
>> #define CMSG_LEN(len)   (_ALIGN(sizeof(struct cmsghdr)) + (len))
>>^~~
>> plugin_dhtu_ip.c:862:36: note: forward declaration of 'struct in_pktinfo'
>>   if (CMSG_LEN (sizeof (struct in_pktinfo)) ==
>>^
>> plugin_dhtu_ip.c:865:27: error: variable has incomplete type 'struct 
>> in_pktinfo'
>> struct in_pktinfo pi;
>>   ^
>> plugin_dhtu_ip.c:862:36: note: forward declaration of 'struct in_pktinfo'
>>   if (CMSG_LEN (sizeof (struct in_pktinfo)) ==
>>^
>> plugin_dhtu_ip.c:1033:23: error: use of undeclared identifier 'IP_PKTINFO'
>>   IP_PKTINFO,
>>   ^
>> 5 errors generated.
>> *** Error 1 in src/dhtu (Makefile:896 'plugin_dhtu_ip.lo': @echo "  CC  
>> " plugin_dhtu_ip.lo;/bin/sh ../../libtool --silent --tag=CC-...)
>> *** Error 1 in src (Makefile:569 'all-recursive': @fail=;  if 
>> (target_option=k; case ${target_option-} in  ?) ;;  *) echo 
>> "am__make_running_...)
>> *** Error 1 in . (Makefile:651 'all-recursive': @fail=;  if 
>> (target_option=k; case ${target_option-} in  ?) ;;  *) echo 
>> "am__make_running_wi...)
>> *** Error 2 in /home/misha/work/gnunet (Makefile:516 'all')
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: compiling gnunet 0.16.3 on openbsd

[Schanzenbach, Martin]

Hi Mikhail,

I just pushed some portability fixes to git master.
I tried in a VM (with gcc, however) and it builds for me now on openbsd.
Can you try again?
It seems to me as if you are missing something in your toolchain.
Maybe libtool? Can you check that you have installed all dependencies?

BR
Martin

> On 31. Mar 2022, at 18:29, Mikhail  wrote:
> 
> On Wed, Mar 30, 2022 at 10:17:32PM +0300, Mikhail wrote:
>> On Wed, Mar 30, 2022 at 05:40:53PM +0000, Schanzenbach, Martin wrote:
>>> Interesting. I think this hit us: 
>>> https://bugs.freedesktop.org/show_bug.cgi?id=76856
>> 
>> Excellent find.
>> 
>>> Can you modify configure.ac and remove any occurrences of "-no-undefined" 
>>> and run
>>> 
>>> $ ./bootstrap
>>> $ ./configure  && make
>>> 
>>> again?
>>> 
>>> If that fixes it I can push that upstream. Atm I do not have a usable 
>>> openbsd installation.
>> 
>> I tried to build from git, but it has failed too (some comments after
>> bootstrap log, marked with ===), I'm not sure how to proceed with the
>> errors.
> 
> I managed to "fix" ./configure issue after ./bootstrap with adding
> "srcdir=." around the check for aux files.
> 
> The diff for configure.ac:
> 
> diff --git a/configure.ac b/configure.ac
> index c2296f004..ce6eb82f6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1159,8 +1159,8 @@ AC_CHECK_FUNCS([atoll stat64 strnlen mremap getrlimit 
> setrlimit sysconf initgrou
> 
> GN_INTLINCL=""
> GN_LIBINTL="$LTLIBINTL"
> -GN_LIB_LDFLAGS="-export-dynamic -no-undefined"
> -GN_PLUGIN_LDFLAGS="-export-dynamic -avoid-version -module -no-undefined"
> +GN_LIB_LDFLAGS="-export-dynamic "
> +GN_PLUGIN_LDFLAGS="-export-dynamic -avoid-version -module "
> 
> AC_SUBST([GN_LIB_LDFLAGS])
> AC_SUBST([GN_PLUGIN_LDFLAGS])
> diff --git a/contrib/gana b/contrib/gana
> index 0958add54..e12bcee06 16
> --- a/contrib/gana
> +++ b/contrib/gana
> @@ -1 +1 @@
> -Subproject commit 0958add542378a6ca9c411e2dc19527834e9f645
> +Subproject commit e12bcee063df61ed4b9acbe819443672364eb4d8
> diff --git a/po/POTFILES.in b/po/POTFILES.in
> index 5c1152e7c..b7e7684c6 100644
> --- a/po/POTFILES.in
> +++ b/po/POTFILES.in
> @@ -530,6 +530,7 @@ src/util/crypto_ecc.c
> src/util/crypto_ecc_dlog.c
> src/util/crypto_ecc_gnsrecord.c
> src/util/crypto_ecc_setup.c
> +src/util/crypto_edx25519.c
> src/util/crypto_hash.c
> src/util/crypto_hash_file.c
> src/util/crypto_hkdf.c
> 
> 
> Unfortunately this approach didn't give any result:
> 
> ./configure --with-microhttpd=/usr/local/ LDFLAGS="$LDFLAGS -L/usr/lib"
> [...]
> make V=1
> [...]
> make  all-recursive
> Making all in m4
> Making all in bin
> Making all in src
> Making all in include
> Making all in .
> Making all in util
> /bin/sh ../../libtool  --tag=CC--mode=link cc   -fPIC -g -O2 
> -fno-strict-aliasing -Wno-address-of-packed-member 
> -Wno-tautological-constant-out-of-range-compare -I/usr/local/include 
> -export-dynamic   -version-info 15:0:0 -L/usr/lib 
> -Wl,--unresolved-symbols=report-all -Wl -lc  -o libgnunetutil.la -rpath 
> /usr/local/lib bandwidth.lo  bio.lo  buffer.lo child_management.lo client.lo 
> common_allocation.lo  common_endian.lo common_logging.lo configuration.lo  
> configuration_helper.lo consttime_memcmp.lo  container_bloomfilter.lo 
> container_heap.lo  container_meta_data.lo container_multihashmap.lo  
> container_multishortmap.lo container_multiuuidmap.lo  
> container_multipeermap.lo container_multihashmap32.lo crypto_symmetric.lo 
> crypto_crc.lo crypto_cs.lo crypto_ecc.lo  crypto_ecc_gnsrecord.lo 
> crypto_ecc_dlog.lo crypto_ecc_setup.lo  crypto_edx25519.lo crypto_hash.lo 
> crypto_hash_file.lo  crypto_hkdf.lo crypto_kdf.lo crypto_mpi.lo 
> crypto_paillier.lo crypto_pow.lo crypto_random.lo crypto_rsa.lo disk.lo  
> dnsparser.lo dnsstub.lo getopt.lo getopt_helpers.lo helper.lo  load.lo mst.lo 
> mq.lo nc.lo network.lo op.lo os_installation.lo  os_network.lo os_priority.lo 
> peer.lo plugin.lo program.lo  regex.lo resolver_api.lo scheduler.lo 
> service.lo signal.lo  strings.lo time.lo tun.lo uri.lo speedup.lo 
> proc_compat.lo-latomic  -L/usr/local/lib -lgcrypt -lgpg-error  
> -L/usr/local/lib -liconv -R/usr/local/lib  -L/usr/local/lib -lintl 
> -L/usr/local/lib -liconv -R/usr/local/lib  -lltdl   -lidn2  -lz  -lunistring  
> -lsodium -lm
> libtool: link: cc -shared  -fPIC -DPIC -o .libs/libgnunetutil.so.15.0  
> .libs/bandwidth.o .libs/bio.o .libs/buffer.o .libs/child_management.o 
> .libs/client.o .libs/common_allocation.o .lib

Re: compiling gnunet 0.16.3 on openbsd

[Schanzenbach, Martin]

Interesting. I think this hit us: 
https://bugs.freedesktop.org/show_bug.cgi?id=76856

Can you modify configure.ac and remove any occurrences of "-no-undefined" and 
run

$ ./bootstrap
$ ./configure  && make

again?

If that fixes it I can push that upstream. Atm I do not have a usable openbsd 
installation.

BR

> On 30. Mar 2022, at 19:26, Mikhail  wrote:
> 
> On Wed, Mar 30, 2022 at 05:16:59PM +, Schanzenbach, Martin wrote:
>> Hi,
>> 
>> your configure output does not indicate that LDFLAGS is correctly set
>> of your system libraries are found in /usr/lib Can you try:
>> 
>> $ ./configure <..your options> LDFLAGS="$LDFLAGS -L/usr/lib"
>> 
>> and see if that works?
> 
> Thanks for the fast reply. I tried your line and still have the same
> errors (make V=1 included at the end):



signature.asc
Description: Message signed with OpenPGP

Re: compiling gnunet 0.16.3 on openbsd

[Schanzenbach, Martin]

Hi,

your configure output does not indicate that LDFLAGS is correctly set of your 
system libraries are found in /usr/lib
Can you try:

$ ./configure <..your options> LDFLAGS="$LDFLAGS -L/usr/lib"

and see if that works?

BR

> On 30. Mar 2022, at 19:01, Mikhail  wrote:
> 
> Hello, I'm interested in gnunet and currently run latest openbsd
> snapshot:
> 
> $ uname -a
> OpenBSD edge.lab.local 7.1 GENERIC.MP#448 amd64
> 
> $ clang -v
> OpenBSD clang version 13.0.0
> Target: amd64-unknown-openbsd7.1
> Thread model: posix
> InstalledDir: /usr/bin
> 
> But during linkage I've faced issues with not finding libc's functions
> like memcpy, etc, full log is inlined, also 'make V=1' is included at
> the end.
> 
> I tried to pass LDFLAGS="-L/usr/lib", but it gave no result.
> 
> Does anyone have a clue to what can be done with it?
> 
> $ ./configure --with-microhttpd=/usr/local
> 
> checking build system type... x86_64-unknown-openbsd7.1
> checking host system type... x86_64-unknown-openbsd7.1
> checking target system type... x86_64-unknown-openbsd7.1
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether UID '1000' is supported by ustar format... yes
> checking whether GID '1000' is supported by ustar format... yes
> checking how to create a ustar tar archive... gnutar
> checking whether make supports nested variables... (cached) yes
> checking for gawk... (cached) awk
> checking for gcc... no
> checking for cc... cc
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether cc accepts -g... yes
> checking for cc option to accept ISO C89... none needed
> checking whether cc understands -c and -o together... yes
> checking whether make supports the include directive... yes (GNU style)
> checking dependency style of cc... gcc3
> checking whether cc understands -c and -o together... yes
> checking whether ln -s works... yes
> checking whether make sets $(MAKE)... (cached) yes
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.29.2... yes
> checking how to print strings... print -r
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by cc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking the maximum length of command line arguments... 393216
> checking how to convert x86_64-unknown-openbsd7.1 file names to 
> x86_64-unknown-openbsd7.1 format... func_convert_file_noop
> checking how to convert x86_64-unknown-openbsd7.1 file names to toolchain 
> format... func_convert_file_noop
> checking for /usr/bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... match_pattern 
> /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$
> checking for dlltool... no
> checking how to associate runtime and link libraries... print -r --
> checking for ar... ar
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm -B output from cc object... ok
> checking for sysroot... no
> checking for a working dd... /bin/dd
> checking how to truncate binary pipes... /bin/dd bs=4096 count=1
> checking for mt... mt
> checking if mt is a manifest tool... no
> checking how to run the C preprocessor... cc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if cc supports -fno-rtti -fno-exceptions... yes
> checking for cc option to produce PIC... -fPIC -DPIC
> checking if cc PIC flag -fPIC -DPIC works... yes
> checking if cc static flag -static works... yes
> checking if cc supports -c -o file.o... yes
> checking if cc supports -c -o file.o... (cached) yes
> checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes
> checking whether -lc should be 

GNUnet 0.16.3 released

[Schanzenbach, Martin]

Hi,

we just released a bugfix release for GNUnet 0.16.2: 
https://www.gnunet.org/en/news/2022-03-0.16.3.html 


Best
Martin


signature.asc
Description: Message signed with OpenPGP

GNUnet 0.16.2 released

[Schanzenbach, Martin]

Hi,

we just released a bugfix release for GNUnet 0.16.1: 
https://www.gnunet.org/en/news/2022-03-0.16.2.html

Best
Martin


signature.asc
Description: Message signed with OpenPGP

GNUnet 0.16.1 released

[Schanzenbach, Martin]

Hi,

we just released a bugfix release for GNUnet 0.16.1: 
https://www.gnunet.org/en/news/2022-03-0.16.1.html

Best
Martin


signature.asc
Description: Message signed with OpenPGP

Re: Reducing the number of executables to one

[Schanzenbach, Martin]

> On 3. Mar 2022, at 01:51, madmurphy  wrote:
> 
> Hi Christian,
> 
> As I said, it is more of a long term planning. The main argument in favor is 
> that (hopefully!) the number of “gnunet-XXX” utilities is only destined to 
> grow, so eventually at some point it will be needed anyway. I can try to be 
> the devil's advocate and answer point by point…
> 
> It just makes it less obvious how to run the binaries under valgrind/gdb, 
> adds just another process as overhead
> It will always be possible to run the binaries directly. They will still 
> exist, they will only be outside /usr/bin. Already now GNUnet does something 
> similar with /usr/lib/gnunet/libexec.
> 
> may require re-writing documentation.
> That yes, will be required. But can be done slowly. If people see in the 
> documentation gnunet-peerinfo instead of gnunet peerinfo they are going to 
> understand anyway. It could even become an opportunity to do a very much 
> needed documentation review.
> 
> It also removes the ability to get a list of possible invocations via 'tab' 
> easily (right now, you can type "gnunet-" and get a list of all 
> available gnunet-commands).
> That no, it is not a problem. It is possible to add command completion to the 
> gnunet script/program (depending on whether we decide that it is a script or 
> a C program), so that a user can type gnunet  and get the list of 
> commands available – the same way as you can currently type make  and 
> get the list of make targets available…

I am relatively unpassionate about this but: Isn't this kind of completion 
shell-specific?
As in, wouldn't you have to provide different shell scripts for different 
shells?

BR

> 
> --madmurphy
> 
> 
> On Wed, Mar 2, 2022 at 11:01 PM Christian Grothoff  
> wrote:
> Personally, I'm not a fan of this style. It just makes it less obvious
> how to run the binaries under valgrind/gdb, adds just another process as
> overhead, and may require re-writing documentation. It also removes the
> ability to get a list of possible invocations via 'tab' easily (right
> now, you can type "gnunet-" and get a list of all available
> gnunet-commands).
> 
> So overall, the "benefit" of being able to remove the hyphen seems,
> well, questionable. But I'm aware that it is the current fashion. But I
> personally don't get that fashion.
> 
> On 2/27/22 11:20 AM, madmurphy wrote:
> > This is more like a long term plan and nothing really important…
> >
> > I saw that the amount of command line utilities that GNUnet ships is
> > quite sizeable and is probably only destined to grow (I have counted 70
> > executables in |/usr/bin|); so I was thinking that GNUnet could follow
> > git's approach, that of having one single executable in |/usr/bin|, and
> > do something like |gnunet COMMAND OPTIONS ARGUMENTS|.
> >
> > As all the executables are named |gnunet-SOMETHING|, this would
> > basically only remove the hyphen. For example, |gnunet-search 'commons'|
> > would become |gnunet search 'commons'|.
> >
> > It can be done with a shell script as simple as:
> >
> > #!/bin/sh
> > #
> > # /usr/bin/gnunet
> > #
> >
> > _GNUNET_UTIL_DIR_='/foo/bar'
> >
> > if [[ -f "${_GNUNET_UTIL_DIR_}/gnunet-${1}" ]]; then
> >   "${_GNUNET_UTIL_DIR_}/gnunet-${1}" "${@:2}"
> > else
> >   echo "Unknown command \"${1}\"."
> > fi
> >
> > (where |/foo/bar| is the directory where the executables are actually
> > installed.)
> >
> > What do you think?
> >
> > --madmurphy
> >
> 



signature.asc
Description: Message signed with OpenPGP

GNUnet 0.16.0 released

[Schanzenbach, Martin]

We are pleased to announce the release of GNUnet 0.16.0.
This is a new major release. It breaks protocol compatibility with the 0.15.x 
versions. Please be aware that Git master is thus henceforth (and has been for 
a while) INCOMPATIBLE with the 0.15.x GNUnet network, and interactions between 
old and new peers will result in issues. 0.15.x peers will be able to 
communicate with Git master or 0.16.x peers, but some services - in particular 
GNS - will not be compatible.
In terms of usability, users should be aware that there are still a number of 
known open issues in particular with respect to ease of use, but also some 
critical privacy issues especially for mobile users. Also, the nascent network 
is tiny and thus unlikely to provide good anonymity or extensive amounts of 
interesting information. As a result, the 0.16.0 release is still only suitable 
for early adopters with some reasonable pain tolerance.


Download links:

http://ftpmirror.gnu.org/gnunet/gnunet-0.16.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-0.16.0.tar.gz.sig
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.16.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.16.0.tar.gz.sig
http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.16.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.16.0.tar.gz.sig

The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

Note that due to mirror synchronization, not all links may be functional
early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/

Noteworthy changes in 0.16.0 (since 0.15.3):
GNS:
  - New record flag: CRITICAL. For records that must be processed otherwise 
resolution must fail. #7169
  - Deletion of records and reduction of expiration times is now properly 
handled with respect to monotonically increasing expiratin times. #7170
  - VPN tunnel establishment is moved out of the GNS resolver to be handled by 
applications (such as the DNS2GNS service). #7171
  - Introduces new record type REDIRECT which replaces the previous (ab)use of 
CNAME records. #7172
  - The specification has been updated to reflect the changes. 
https://lsd.gnunet.org/lsd0001
DHT:
  - Routes can now be signed. #4164
  - Changed distance metric to a more traditional XOR. #7136
  - The specification has been updated to reflect the changes. 
https://lsd.gnunet.org/lsd0004
RECLAIM: Added some preliminary support for Decentralized Identifier (DID) and 
Verifiable Credentials (VCs).
UTIL: Add Clause-Schnorr blind signatures. For use in Taler 
(https://taler.net/en/news/2022-02.html).
BUILD: Building from git now requires recutils. The bootstrap will generate 
up-to-date header files from https://gana.gnunet.org/.

A detailed list of changes can be found in the ChangeLog and the 0.16.0
bugtracker at https://bugs.gnunet.org/changelog_page.php?project_id=13.

Thanks:
This release was the work of many people. The following people contributed code 
and were thus easily identified: Christian Grothoff, Tristan Schwieren, Alessio 
Vanni, Florian Dold, Thien-Thi Nguyen, t3sserakt, Lucien Heuzeveldt, Gian 
Demarmels, madmurphy, TheJackiMonster and Martin Schanzenbach.


signature.asc
Description: Message signed with OpenPGP

Re: Tutorial - Git repo

[Schanzenbach, Martin]

> On 17. Feb 2022, at 13:02, Gavin Henry  wrote:
> 
> No problem Martin.
> 
> Just looking through all the Peer Discovery code and NAT busting
> things for adding the P2P bits to SentryPeer vs what Zyre can do with
> OpenDHT. I need to figure out how a peer node can be reached and pop
> that into the DHT, but looks like GNUNet does all that and way more.
> So I don't need to put in STUN/pmp/discovery etc.
> 
> Thanks.

This is actually something we are currently working on as well.
We are in the process of improving and specifying the DHT 
(https://lsd.gnunet.org/lsd0004/)
which includes HELLO handling (I guess this is what you mean by how a peer node 
can be reached).
Further, t3sserakt is currently working on our redesign of the transport 
subsystem which will
hopefully improve connectivity (including NAT traversal): 
https://docs.gnunet.org/handbook/gnunet.html#TRANSPORT_002dNG-Subsystem

Any feedback is always welcome here.

BR
Martin



signature.asc
Description: Message signed with OpenPGP

Re: Tutorial - Git repo

[Schanzenbach, Martin]

Thanks Gavin,

fixed, should be deployed soonish.

BR
Martin

> On 17. Feb 2022, at 12:13, Gavin Henry  wrote:
> 
> Hi all,
> 
> The docs here 
> https://docs.gnunet.org/tutorial/tutorial.html#Obtaining-the-latest-version-from-Git
> state:
> 
>$ git clone https://git.gnunet.org/gnunet
> 
> so should/would this be:
> 
>$ git clone https://git.gnunet.org/gnunet.git/
> 
> as there are a lot of repos on that page.
> 
> Thanks.
> 
> --
> Kind Regards,
> 
> Gavin Henry.
> https://sentrypeer.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: LSD0001 review

[Schanzenbach, Martin]

> On 10. Feb 2022, at 23:26, Maxime Devos  wrote:
> 
> Schanzenbach, Martin schreef op ma 07-02-2022 om 19:02 [+]:
>>>> LEGACY HOSTNAME
>>>> A UTF-8 string (which is not 0-terminated) representing the
>>>> legacy hostname.
>>> 
>>> What happens if it contaings \0, or ends with two dots, does that
>> mean
>>> the LEHO record is invalid and must be rejected?  If it is in
>> punycode,
>>> why say ‘A UTF-8 string’ instead of ’an ASCII string’?
>> 
>> It is not in punycode. It is just a UTF-8 string.
>> Why is it not 0-terminated? TBH I am not sure, probably to save a
>> byte :)
> 
> Some context on this question about nul characters.
> 
> Consider a C application that is asked to contact http://i.hate.c,
> a website about the use of "\0" in C software.  i.hate.c has a LEHO
> record with value "foo\0bar.com" (and some VPN or  record).
> 
> Perhaps the HTTP spec disallows \0 in the "Host" header,
> and the C application hence gives some kind of error message
> about not being able to contact i.hate.c.  No problem in this case.
> 
> Perhaps the C applications assumes that GNS will only return ‘proper’
> hostnames, add a \0 to the end of the record, and
> use strlen("foo\0bar.com") (= 3) to determine how large a buffer needs
> to be calculated, and copy "foo\0bar.com" (the whole thing of size 12
> (including terminating\0)) into the buffer that's only of size 3,
> resulting in a buffer overflow.
> 
> (Variants of) the second scenario seems plausible to me.
> 
> As such, I would recommend forbidding \0 bytes in GNS,
> or mentioning problems involving \0 in a section ‘Security
> considerations’.

While I understand the problem GNS defines strings to be UTF-8 (notwithstanding 
punycode exceptions).
You can't have UTF-8 strings with a zero terminator without having it mean 
exactly that: A string termination.

Yes, you can say "but what if it is not a UTF-8 string", but that is not really 
the problem of the GNS spec.
It normatively defines it as such and the implementation must comply (with 
UTF-8).
See also https://en.wikipedia.org/wiki/Null-terminated_string section in 
"Character encoding".

BR

> 
> Greetings,
> Maxime.



signature.asc
Description: Message signed with OpenPGP

Re: LSD0001 review

[Schanzenbach, Martin]

> On 10. Feb 2022, at 23:02, Maxime Devos  wrote:
> 
> Schanzenbach, Martin schreef op ma 07-02-2022 om 19:02 [+]:
>>>> NICKNAME
>>>> 
>>>>A UTF-8 string (which is not 0-terminated) representing the
>>>> preferred label of the zone. This string MUST NOT include a "."
>>>> character.
>>> 
>>> Can I have a nickname "SOME-ZTLD"
>> 
>> Yes.
>> 
>>> , "@"
>> 
>> Ah good catch. Yes. But nobody will accept it.
>> [...]
>>> , "foobar"
>> Yes.
>> [...]
>>> or "" (zero-length string)?.
>> 
>> Yes
>> 
>> You can do whatever you like with your string.
>> You cannot expect it to be used :)
> 
> You say that nobody will accept the "@".
> Possibly you also mean that "foobar" won't be accepted
> (because many C assume the nul character is only for termination).
> 
> However, I don't see anything in the spec telling people not to accept
> this @ and .  Does this ‘don't accept this’ need to be
> included in the spec somewhere?

What I mean is that you would not look at a nick like that and think
"I am going to add this to my zone".
The use of a NICK is not defined in a normative way.
There is no action associated with it that is qualified with a MUST or SHOULD.
So users may consider the NICK record to when adding new PKEY delegations.
They may choose not to.

Let's look at "@":
If you really see a NICK, and decide "hey lets add a delegation to this zone
under the label @" it will not work because it is not allowed to add
delegations under the empty label:

https://lsd.gnunet.org/lsd0001/#section-5.1:
"Zone delegation records MUST NOT be stored and published under the apex label."

Let's look at "foobar":
I do not really see a way that a user will not see this as simply "foo".
The string is terminated there and the user will be displayed "foo".
If the user decides to add a delegation under "foo", he can do so no problem.
Yes, it will not be "foobar", but that is not really relevant in any 
way.
The user may also decide to put the delegation under "notfoo". The NICK
is just a suggestion.
If the suggestion is ambiguous (or cannot be complied with), it is just that:
A bad suggestion by the zone owner.

BR
Martin

> 
> Greetings,
> Maxime.

Re: LSD0001 review

[Schanzenbach, Martin]

> On 7. Feb 2022, at 20:02, Schanzenbach, Martin  
> wrote:
> 
> 
> 
>> On 7. Feb 2022, at 12:37, Maxime Devos  wrote:
>> 
>> Hi,
>> 
>>> Name
>>>   A name in GNS is a domain name as defined in [RFC8499] as an
>>> ordered list of labels. The labels in a name are separated using the
>>> character "." (dot). Names, like labels, are encoded in UTF-8.
>> 
>> Does that mean, no punycode, unlike DNS?  Does GNUnet's GNS<->DNS code
>> handle punycode conversion?
>> 
> 
> Yes. It MUST handle conversion when DNS gets involved. The spec should state 
> that
> on the respective sections.
> 
>>> GNS TLDs are typically part of the configuration of the local
>>> resolver (see Section 7.1), and may thus not be globally unique
>> 
>> This reads to me as ’it is forbidden for them to be unique’,
>> whereas I assume it was meant ‘and thus are not necessarily
>> globally unique’ -- if I name a TLD, say, maximed-943438-foobar, then
>> it's probably globally unique.
>> 
>> It's clear from context though, and this sentence can be read
>> in the latter way as well.
>> 
> 
> Ah interesting you read it in this way. What it actually means is that even if
> I have a TLD configuration for maximed-943438-foobar, it does not necessarily
> delegate to the same zone as your configuration.
> Hence names (with delegation) are may not be unique even if the names
> are equal (0 == strcmp (name1, name2))
> 
>>> In order to further increase tolerance for failures in character
>>> recognition, the letter "U" MUST be decoded to the same Base32 value
>>> as the letter "V".
>> 
>> Does this mean that, if I point a browser at a zTLD with a 'U',
>> then the browser should change it to a 'V' (if the browser has GNS
>> integration)?  How does this interact with the domain name in TLS and
>> HTTP?  If the server expects a certain (subdomain of a) zTLD, does it
>> need to recognise equivalent encodings?
>> 
>> Likewise for 1IiLl, Aa, Bb, ...
> 
> Reading this again, I think the table is wrong.
> I think the "U" (and "u") should ne next to "V v" in the decode symbol column.
> Then, the _encoded_ string should always be a "V".
> Should the browser or the application make a "V" out of a U when it 
> encounters it?
> That is a good question. I think maybe the encoding may need to be 
> "normalized"
> in such a case to "V".
> 
>> 
>>> TIMESTAMP
>>>   denotes the absolute 64-bit date when the revocation was
>>> computed. In microseconds since midnight (0 hour), January 1, 1970
>>> in network byte order
>> 
>> Do leap seconds count? What timezone is this?
> 
> UTC. I guess we should add a posix reference here.
> 
>> 
>>> DNS NAME
>>>  The name to continue with in DNS. The value is UTF-8 encoded and >
>> 0-terminated.
>>> DNS SERVER NAME
>>>  The DNS server to use. May be an IPv4 address in dotted-decimal
>>> form or an IPv6 address in colon-hexadecimal form or a DNS name.
>> 
>> How is using a DNS name for the DNS server supposed to work, how are
>> we supposed to resolve the name of the DNS server without a pre-
>> existing DNS server?  This seems rather cyclic.
>> 
>> Perhaps the ‘standard’ DNS root servers need to be contacted
>> (indirectly, via the ISP's DNS servers)?
> 
> Yes. The system stub resolver should be used.
> 
>> 
>> If the peer doesn't have DNS set up, or it does have DNS set up
>> by redirecting it to GNS, what is supposed to happen?
> 
> See section 7.3.2
> 
>> 
>> Can I use localhost or loopback as IP address?
>> If I can use localhost or loopback here, how is that interpreted?
>> The peer that initiated the GNS query?  The peer that contacts the DHT
>> system?  The peer that created the GNS record?
> 
> If the zone owner that created this record put the loopback in there then
> it will point your resolver to YOUR local host, of course.
> So: Yes, you can use it. Maybe there a use case for it actually where
> you have a special DNS server running locally to resolve special DNS names 
> (without the ICANN root, for example).
> 
>> 
>>> It
>>> may also be a relative GNS name ending with a "+" as the rightmost
>>> label. The implementation MUST check the string syntactically for an
>>> IP address in the respective notation before checking for a relative
>>> GNS name. If all three checks fail, the name MUST be treated as a 

Re: LSD0001 review

[Schanzenbach, Martin]

> On 7. Feb 2022, at 20:12, Maxime Devos  wrote:
> 
> Schanzenbach, Martin schreef op ma 07-02-2022 om 19:02 [+]:
>>>> LEGACY HOSTNAME
>>>> A UTF-8 string (which is not 0-terminated) representing the
>>>> legacy hostname.
>>> 
>>> What happens if it contaings \0, or ends with two dots, does that
>> mean
>>> the LEHO record is invalid and must be rejected?  If it is in
>> punycode,
>>> why say ‘A UTF-8 string’ instead of ’an ASCII string’?
>> 
>> It is not in punycode. It is just a UTF-8 string.
>> Why is it not 0-terminated? TBH I am not sure, probably to save a
>> byte :)
> 
> A follow-up question: LEGACY HOSTNAME can be an UTF-8 string, not in
> punycode.  But can it be in punycode, even though that is not
> necessary?  Should punycode be forbidden here, in favour of UTF-8?

Well punycode is ASCII. And any ASCII string is (AFAIK) is also a valid uncode 
string.
So yes, you can put punycode in there.

BR

> 
> Greetings,
> Maxime.



signature.asc
Description: Message signed with OpenPGP

Re: LSD0001 review

[Schanzenbach, Martin]

> On 7. Feb 2022, at 12:37, Maxime Devos  wrote:
> 
> Hi,
> 
>> Name
>>A name in GNS is a domain name as defined in [RFC8499] as an
>> ordered list of labels. The labels in a name are separated using the
>> character "." (dot). Names, like labels, are encoded in UTF-8.
> 
> Does that mean, no punycode, unlike DNS?  Does GNUnet's GNS<->DNS code
> handle punycode conversion?
> 

Yes. It MUST handle conversion when DNS gets involved. The spec should state 
that
on the respective sections.

>> GNS TLDs are typically part of the configuration of the local
>> resolver (see Section 7.1), and may thus not be globally unique
> 
> This reads to me as ’it is forbidden for them to be unique’,
> whereas I assume it was meant ‘and thus are not necessarily
> globally unique’ -- if I name a TLD, say, maximed-943438-foobar, then
> it's probably globally unique.
> 
> It's clear from context though, and this sentence can be read
> in the latter way as well.
> 

Ah interesting you read it in this way. What it actually means is that even if
I have a TLD configuration for maximed-943438-foobar, it does not necessarily
delegate to the same zone as your configuration.
Hence names (with delegation) are may not be unique even if the names
are equal (0 == strcmp (name1, name2))

>> In order to further increase tolerance for failures in character
>> recognition, the letter "U" MUST be decoded to the same Base32 value
>> as the letter "V".
> 
> Does this mean that, if I point a browser at a zTLD with a 'U',
> then the browser should change it to a 'V' (if the browser has GNS
> integration)?  How does this interact with the domain name in TLS and
> HTTP?  If the server expects a certain (subdomain of a) zTLD, does it
> need to recognise equivalent encodings?
> 
> Likewise for 1IiLl, Aa, Bb, ...

Reading this again, I think the table is wrong.
I think the "U" (and "u") should ne next to "V v" in the decode symbol column.
Then, the _encoded_ string should always be a "V".
Should the browser or the application make a "V" out of a U when it encounters 
it?
That is a good question. I think maybe the encoding may need to be "normalized"
in such a case to "V".

> 
>> TIMESTAMP
>>denotes the absolute 64-bit date when the revocation was
>> computed. In microseconds since midnight (0 hour), January 1, 1970
>> in network byte order
> 
> Do leap seconds count? What timezone is this?

UTC. I guess we should add a posix reference here.

> 
>> DNS NAME
>>   The name to continue with in DNS. The value is UTF-8 encoded and >
> 0-terminated.
>> DNS SERVER NAME
>>   The DNS server to use. May be an IPv4 address in dotted-decimal
>> form or an IPv6 address in colon-hexadecimal form or a DNS name.
> 
> How is using a DNS name for the DNS server supposed to work, how are
> we supposed to resolve the name of the DNS server without a pre-
> existing DNS server?  This seems rather cyclic.
> 
> Perhaps the ‘standard’ DNS root servers need to be contacted
> (indirectly, via the ISP's DNS servers)?

Yes. The system stub resolver should be used.

> 
> If the peer doesn't have DNS set up, or it does have DNS set up
> by redirecting it to GNS, what is supposed to happen?

See section 7.3.2

> 
> Can I use localhost or loopback as IP address?
> If I can use localhost or loopback here, how is that interpreted?
> The peer that initiated the GNS query?  The peer that contacts the DHT
> system?  The peer that created the GNS record?

If the zone owner that created this record put the loopback in there then
it will point your resolver to YOUR local host, of course.
So: Yes, you can use it. Maybe there a use case for it actually where
you have a special DNS server running locally to resolve special DNS names 
(without the ICANN root, for example).

> 
>> It
>> may also be a relative GNS name ending with a "+" as the rightmost
>> label. The implementation MUST check the string syntactically for an
>> IP address in the respective notation before checking for a relative
>> GNS name. If all three checks fail, the name MUST be treated as a DNS
>> name. The value is UTF-8 encoded and 0-terminated.
>> 
>> NOTE: If an application uses DNS names obtained from GNS2DNS records
> in a DNS request they must first be converted to a punycode
> representation [RFC5890].
> 
> I'm not sure what this note means exactly.  Does this mean that DNS
> NAME and DNS SERVER NAME must be in punycode?  Or do they not need
> to be in punycode, instead the name in the record should be converted
> into punycode before contacting the DNS server?

No they are in UTF-8 as it is stated. But when you resolve this record and want 
to USE it
for anything related to DNS, you need to convert it to punycode.
A resolver MUST of course also convert to punycode when continuing with DNS, 
for example.
Now that I write this, this information is missing from section 7.3.2 :)

> 
> Are IPv6 addresses with surrounding [] or without?

Without. Only colon-hexadecimal form.
[] is only really used for URLs, I think 

Re: LSD0004 call for reviews

[Schanzenbach, Martin]

Thank you very much Maxime. I will look into the feedback this week.

Just a side note: LSD0004 (the DHT) ist still in a very early, rough state.
LSD0001 (GNS) is what is currently in the final stages and needs some fresh 
eyes before
submission, if you are interested. :)

Anyway. As soon as I have the time I will address the feedback below.

Thanks!
Martin

> On 7. Feb 2022, at 10:39, Maxime Devos  wrote:
> 
>> Block Storage
>>The Block Storage component is used to persist and manage data by
>> nodes. It includes logic for quotas, caching stragegies and data
>> validation.
> 
> stagegies -> strategies
> 
>> Responsible Peer:
>>The peer N that is responsible for a specific resource K, as
>> defined by the SelectClosestNode(K, N) algorithm (see Section 7.
> 
> missing closing parenthesis
> 
>> In order to achieve O(log n) routing performance
> 
>> 0: Demultiplex-Everywhere
>indicates that each node along the way should process the request.
> 
> What's the advantage of not doing this by default?  And what is
> Demultiplex-Everywhere useful for?
> 
>> 3-15: Reserved
>>For future use.
> 
> What should a peer do when it encounters one of these?
> Set it to zero? Ignore the unknown flags? Drop the message?
> Disconnect from the peer that sent it?
> 
>> EXPIRATION
>>denotes the absolute 64-bit expiration date of the content. The
>> value specified is microseconds since midnight (0 hour), January 1,
>> 1970, but must be a multiple of one million (so that it can be
>> represented in seconds in a HELLO URL). Stored in network byte order.
> 
> What should a peer do when the expiration isn't a multiple of one
> million?  Round it, drop it?  What's the problem with not exactly
> being representable in a HELLO URL when it's not exactly a multiple
> of one million, wouldn't an approximation do?
> 
>> ADDRESSES
>>A sequence of exactly URL_CTR 0-terminated URIs in UTF-8 encoding
>> representing addresses of this peer. Each URI must begin with a non-
>> empty URI schema terminated by "://" and followed by some non-empty
>> Underlay-specific address encoding.
> 
> If I have two addresses FOO and BAR, do they need to be encoded as
> FOO<0 byte>BAR or FOO<0 byte>BAR<0 byte>?  What should the peer do
> if it encounters superfluous 0 bytes: FOO<0 byte><0 byte>?  Is a
> sequence of zero URLs acceptable?  If a sequence of zero URLs is
> acceptable, does it need to be encoded as <0 byte> or ?
> 
> What should happen if the field is bogus?  Why zero-encoding and not
> length-prefixed?  Length-prefixed is IMHO easier to parse, with less
> chance of going out-of-bounds.
> 
>> PATH_LEN
>>   is a 16-bit number indicating the length of the PUT path recorded
>>   in PUTPATH. As PUTPATH is optional, this value may be zero. In
>>   network byte order.
> 
> Is this optional even when Record-Route is specified?  Is this 'length'
> the number of path elements, or the byte size of all the path elements?
> 
>> HOPCOUNT
>>is a 16-bit number indicating how many hops this message has
>> traversed to far. In network byte order.
> 
> Wouldn't PATH_LEN = HOPCOUNT when Record-Route is requested?  What's
> the difference?
> 
>> EXPIRATION
>>denotes the absolute 64-bit expiration date of the content. In
>> microseconds since midnight (0 hour), January 1, 1970 in network
>> byte order.
> 
> Do leap seconds count? How about time zones?
> 
>> REPL_LVL
>>is a 16-bit number indicating the desired replication level of
>> the data. In network byte order.
> 
> What about its bounds?  The GNUnet DHT service imposes some bounds,
> e.g. it requires it to be >0 and <=10 IIRC.
> 
> 
>> BLOCK
>>the variable-length block payload. The contents are determined by
>> the BTYPE field.
> 
> How do I know the length of this payload?
> 
>> The EXPIRATION field is evaluated. If the message is expired, it
>> MUST be discarded.
> 
> How can I know if a message is expired, when clocks aren't perfect?
> Will an approximation be sufficient?
> 
>> If the local node is the closest node (cf. IsClosestNode(N, Key)) or
>> the DemultiplexEverywhere options flag ist set, the message MUST be
>> stored locally in the block storage.
> 
> ist set --> is set
> 
>> The implementation MAY forward to fewer or no peers in order to
>> handle resource constraints such as bandwidth
> 
> So if REPL_LEVEL is 65535, the peer doesn't actually have to forward it
> to thousands of peers?  Peers are responsible for stopping
> amplification attacks?
> 
> Also, wouldn't the number of peers grow exponentially as the message
> passes through the network?  The first peers passes it to k other
> peers, each peer passes it to another k peers ..., then at step n,
> ∑(i=1..n)k^i = ϴ(k^n) have been contacted (assuming no duplicate
> peers).
> 
>> XQUERYthe variable-length extended query. Optional.
> 
> How do I now if this is present?  Is it absent whenever XQ_SIZE=0?
> 
>> RESULT_BF
>>the variable-length result bloomfilter
> 
> How do I know its length?
> 
>> OPTIONS

Re: printf-like output for gnunet-search

[Schanzenbach, Martin]

Hi!

If there is a use case for this kind of functionality this lgtm.
Altough, I do wonder what specifically triggered this. Is there anything wrong 
with the default output?

BR
Martin

> On 5. Feb 2022, at 09:09, madmurphy  wrote:
> 
> Okay, after thinking about it I did not like that the --verbose argument was 
> ignored when a format was specified. But since, as it turns out, the 
> --verbose argument was just a way to print all the metadata, I have added an 
> argument for formatting the metadata too. So now we are even. In the 
> meanwhile I have also renamed the new arguments and the format specifiers.
> 
> Again, the help page will explain the new situation:
> 
> $ gnunet-search --help
> 
> gnunet-search [OPTIONS] KEYWORD
> Search GNUnet for files that were published on GNUnet
> Arguments mandatory for long options are also mandatory for short options.
>   -a, --anonymity=LEVEL  set the desired LEVEL of receiver-anonymity
>   -c, --config=FILENAME  use configuration file FILENAME
>   -F, --dir-printf=FORMATwrite the search results for directories
>according to FORMAT, where %f is the
>directory's name, %u is the directory's URI, %m
>is the directory's mime type (always equal to
>`application/gnunet-directory`), %n is the
>search result number and %a is the complete
>list of all the printable metadata available,
>in which each field is displayed according to
>the --prop-printf argument; if missing defaults
>to the --printf argument; if the latter is
>missing too defaults to `#%n:\ngnunet-download
>-o "%f" -R %u\n\n`
>   -f, --printf=FORMATwrite the search results according to FORMAT,
>where %f is the file's name, %u is the file's
>URI, %m is the file's mime type, %n is the
>search result number and %a is the complete
>list of all the printable metadata available,
>in which each field is displayed according to
>the --prop-printf argument; if missing defaults
>to `#%n:\ngnunet-download -o "%f" %u\n\n`
>   -h, --help print this help
>   -L, --log=LOGLEVEL configure logging to use LOGLEVEL
>   -l, --logfile=FILENAME configure logging to write logs to FILENAME
>   -N, --results=VALUEautomatically terminate search after VALUE
>results are found
>   -n, --no-network   only search the local peer (no P2P network
>search)
>   -o, --output=PREFIXwrite search results to file starting with PREFIX
>   -p, --prop-printf=FORMAT   when the %a format specifier appears in --printf
>or --dir-printf, list each property according
>to FORMAT, where %p is the property's content,
>%l is the property's length in bytes, %t is the
>property type, %i is the property type's unique
>identifier and %w is the name of the plugin
>that provided the information; if missing
>defaults to `\t%t: %p\n`
>   -t, --timeout=DELAYautomatically terminate search after DELAY
>   -V, --verbose  be verbose
>   -v, --version  print the version number
> Report bugs to
> gnunet-developers@gnu.org
> .
> Home page:
> http://www.gnu.org/s/gnunet/
> 
> General help using GNU software:
> http://www.gnu.org/gethelp/
> Now, besides the obvious question “Do you like the idea?”, I would like also 
> to ask a few other questions too:
> 
>   • What do you think about the fact that I have named the new arguments 
> --printf, --dir-printf and --prop-printf? Do you think that alternative names 
> would be better?
>   • What do you think about the fact that the format specifiers for 
> --printf and --dir-printf use these letters? Do you think that other letters 
> would be more obvious?
>   • %f – the file's name
>   • %u – the file's URI
>   • %m – the file's mime type
>   • %n – the search result number
>   • %a – the complete list of all the printable metadata available
>   • What do you think about the fact that the format specifiers for 
> --prop-printf use these other letters?
>   • %p – the property's content
>   • %l – the property's length in bytes
>   • %t – the property type
>   • %i – 

Re: Post-quantum secure hierachical deterministic key derivation

[Schanzenbach, Martin]

There is a (kind of) new paper which is shows how to do the blinding (we do not 
really need a full blown HDKD scheme) for
current PQ signature schemes: https://eprint.iacr.org/2021/963.pdf
They also have (C-based) implementations, which is nice.

BR

> On 23. Dec 2020, at 14:20, Jeff Burdges  wrote:
> 
> 
> 
>> On 23 Dec 2020, at 12:30, Martin Schanzenbach  
>> wrote:
>>> You only need the commutative diagram of compatible public and
>>> private derivation paths if you give someone else the power to derive
>>> your new public key for you, and then you later derive its secret
>>> key.  This means the randomness cannot be trusted, well unless you
>>> use fancy zk proofs like MuSig-DN does.
>> 
>> But they do. See also 4.3 last paragraph for more details on how a
>> counter could be used for hot wallets.
> 
> There are no known nice lattice-based VRFs, much less “verifiably produce a 
> secret scalar" like what MuSig-DN does.  All elliptic curve protocols like 
> MuSig-DN need general purpose NIZKs with thousands of constraints, so all 
> require pairing-based SNARK with a trusted setup, or very large proofs 
> (bulletproofs).
> 
> I have not looked closely at 4.2 but it seemingly talks about the usual 
> lattice based distribution issues.  This is not remotely the same problem.  
> The adversary can sample according to any rules they like but do so 
> repeatedly until they find something they like.
> 
> As I said, they assume honest randomness, but soft key derivations have no 
> honest randomness.
> 
> Jeff
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Issue re: the website (and others)

[Schanzenbach, Martin]

Hi,

thanks for the report.
When you go to https://bugs.gnunet.org/my_view_page.php on the top right next 
to your username you can select the project.
The website is "gnunet-www".
Ideally open an issue there, please.

Regarding the messenger-gtk: We can create one if needed. Until then, filing it 
under GNUnet is fine as well.
I added a "messenger service" component there. For now, filing gtk bugs there 
is fine I guess.

BR

> On 7. Jan 2022, at 14:12, Marcos Marado  wrote:
> 
> Hi there,
> 
> I was going to report this on mantis, but I don't see a section
> regarding the website there, so I'm sending this e-mail instead, I
> hope that's alright.
> 
> According to Tobias in
> https://gitlab.com/gnunet-messenger/cadet-gtk/-/issues/10#note_781937121
> , "cadet-gtk will be replaced as GNUnet messaging application by
> messenger-gtk (or other applications based on libgnunetchat maybe). It
> is essentially a reference implementation of the capabilities from
> libgnunetchat using GTK." That being the case, I would suggest the
> website is updated so that https://www.gnunet.org/en/applications.html
> points to messenger-gtk instead of Cadet-GTK.
> 
> Running the risk of mixing different issues in the same e-mail...:
> * It would also be nice to have a link on the "Conversation
> (Pre-Alpha)" section, even if just to point out to its
> documentation/man page;
> * What is the supposed way to open issues regarding the website? And
> messenger-gtk? If it is on mantis, can those sections be created? If
> not, can we have the answer document somewhere, somehow (assuming it
> isn't yet)?;
> * Is there a messenger-gtk roadmap? Is 'integration with Conversation'
> planned to eventually end up there?
> 
> Happy Hacking,
> --
> ~marado
> 



signature.asc
Description: Message signed with OpenPGP

Re: Next Mumble meeting

[Schanzenbach, Martin]

Hi Luis,

I think we cancelled the meeting on 1.1.
The next meeting will be on 2.2.2022 :)
But, there will probably be an announcement before that.

BR
Martin

> On 3. Jan 2022, at 03:30, Luis  wrote:
> 
> Hello
> 
> When will be the next Mumble Meeting? Or did I miss the January one?
> 
> []s,
> Luís
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

LSD0001: The GNU Name System update

[Schanzenbach, Martin]

Hi,

we have recently as part of the IETF ISE review significantly revised the GNS 
specification [1].
In case any of you are interested or have too much time on their hands, reviews 
are very welcome :)

Best
Martin

[1] https://lsd.gnunet.org/lsd0001


signature.asc
Description: Message signed with OpenPGP

Re: ReclaimID and MediaGoblin OpenID Plugin

[Schanzenbach, Martin]

Hi Tobias,

the screenshot under [3] shows both a link for the reclaimID login as well as a 
manual entry.
I am not sure if both can be used. My assumption is that the text entry is 
actually used in combination with OpenID Connect Discovery.
OIDC Discovery uses Webfinger to discover the OpenID Connect server from (e.g.) 
your email address.

reclaimID does (atm) not support discovery. But that should not be an issue as 
discovery is usually optional.

Now, if you can actually configure the OpenID Endpoints in the GMG plugin,
you should use the endpoints as defined in [1]. However, not all OpenID Connect 
plugins support
manual entry of endpoints. We used this in WooCommerce with the WordPress 
OpenID plugin before, where this is possible:
See 
https://git.taler.net/woocommerce-taler.git/tree/server-build/QEMU-autobuild/buildReclaim.sh#n152
 ff

Note that in general the URL https://api.reclaim/openid/authorize is a bit 
hacky, as api.reclaim is not a real DNS name (it is intercepted by the 
webextension).
So the GMG server likely will not accept this domain for the token and userinfo 
endpoints (and this is also the reason the discovery fails hard).
We are currently working on different ways to define the authorization request, 
possibly through https://openid.net/specs/openid-connect-self-issued-v2-1_0.html

What you essentially need is for the GMG plugin to generate a button which 
redirects your browser to
https://api.reclaim/openid/authorize?client_id=="some 
scopes"

If you can point me to the OpenID configuration documentation for GMG, or to a 
sample configuration, I may be able to provide more.

BR
Martin

> On 7. Dec 2021, at 19:01, Tobias Platen  wrote:
> 
> Hello, I want to use ReclaimID with the MediaGoblins OpenID Plugin and
> I was able to get the OpenID plugin working as well as GNUnet and the
> Firefox extension. If I enter ui:reclaim in the browser, I can create
> Identities, but in GMG there is no way to use those identites. The
> GNUnet documentation at [1] seems to be unclear for me, it does not
> state how to integrate with websites. I have screenshots of my
> experiment at [3] and [4].
> 
> [1] https://docs.gnunet.org/handbook/gnunet.html#OpenID-Connect
> [2] http://platen-software.de/tobias/tmp/mediagoblin.png
> [3] http://platen-software.de/tobias/tmp/reclaimid.png
> 
> Tobias Platen (they/them)
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: From gnunet-bcd to configure.ac

[Schanzenbach, Martin]

> On 22. Nov 2021, at 21:48, Alessio Vanni  wrote:
> 
> "Schanzenbach, Martin"  writes:
> 
>> 1. The uncrustify detection is now verbose. configure outputs the
>> output of "uncrustify". Can we prevent that? It looks like an error.
> 
> You are right, there was an error in the check. I'm not sure what
> happened, but AC_CHECK_PROG became AC_CHECK_PROGS (with the final S)
> which has different semantics.
> 

Actually, I wonder why we have a check for uncrustify there at all... it is not 
a build or runtime dep...


>> 2. Configure does not find my microhttpd anymore. I am not using a
>> --with-* flag and it works fine in master.
> 
> I don't know why it happens. In my tests it would always find it without
> the --with flag. Does it at least work with the flag on? That would help
> pinpointing the issue.  As it is, the check is offloaded to pkg-config,
> but maybe there's something amiss that I failed to notice.  I'll look
> into it during the week.
> 
>> Comments:
>> 1. A thing I was wondering is if this autotools version is already
>> "standard" (i.e. sufficiently widespread; looking at you debian stable
>> users).
> 
> As far as I recall, Autoconf 2.71 did not introduce anything new, but
> mostly removed or deprecated some macros.  Using this configure.ac with
> 2.69 (which is available even on very old Debian versions, unless we go
> back to when 2.69 was first released) should, at best, not be able to
> detect if the C compiler supports C99, as 2.71 deprecated (and thus
> emits a warning) when standard revision-specific macros are used.  The
> normal AC_PROG_CC macro on 2.69 and earlier provides a C89 compiler.
> While this might be an issue, it's also true that by the time Autconf
> 2.69 was around, the majority of compilers supported C99 out of the box,
> so unless a peculiar system is targeted, where the user most likely know
> what they are doing, the "average user", even on Debian stable, should
> be able to compile GNUnet just fine.  It's not the best, I agree, but
> it's not as bad as it looks either.
> 
>> We may want to stick with "old" macros if it breaks with a significant
>> number of users' toolchain(s).
> 
> Most macros currently used on master have been around way before 2.69
> and I used pretty much only those. If anything, the main incompatibility
> might be with Automake (which I forgot to mention in my first mail,
> sorry) as it was bumped from 1.9 to 1.11 to remove a couple of
> compatibility shims from configure.ac.  Automake 1.11 should be old
> enough to be supported even by Debian users, to continue from the point
> above.  As such, it shouldn't break too easily under a "traditional"
> setup.
> 
>> 2. The "pdflatex detection is reasonable, but unfortunately not
>> sufficient which is probably why we didnt do it at all: The latex
>> plugins required are not checked.  Maybe the check should actually try
>> to compile a latex file as required by gnunet-bcd?
> 
> Right, I forgot to mention this too. Unfortunately I don't know what's
> the best way to check for a LaTeX package, so all I could do was to
> check for pdflatex and hope the user installed a sufficiently complete
> LaTeX system package from their package manager of choice.  I'll try
> adding a compilation test at least for the TikZ and qrcode packages, as
> those are the ones being used by gnunet-bcd.
> 
> Thanks,
> A.V.
> 



signature.asc
Description: Message signed with OpenPGP

Re: From gnunet-bcd to configure.ac

[Schanzenbach, Martin]

> On 22. Nov 2021, at 21:48, Alessio Vanni  wrote:
> 
> "Schanzenbach, Martin"  writes:
> 
>> 1. The uncrustify detection is now verbose. configure outputs the
>> output of "uncrustify". Can we prevent that? It looks like an error.
> 
> You are right, there was an error in the check. I'm not sure what
> happened, but AC_CHECK_PROG became AC_CHECK_PROGS (with the final S)
> which has different semantics.
> 
>> 2. Configure does not find my microhttpd anymore. I am not using a
>> --with-* flag and it works fine in master.
> 
> I don't know why it happens. In my tests it would always find it without
> the --with flag. Does it at least work with the flag on? That would help
> pinpointing the issue.  As it is, the check is offloaded to pkg-config,
> but maybe there's something amiss that I failed to notice.  I'll look
> into it during the week.

Yes, it works with --with-microhttpd. Maybe it is a problem with my system and
there may be some side effects when switching branches.
My mhd is also in an odd location.

> 
>> Comments:
>> 1. A thing I was wondering is if this autotools version is already
>> "standard" (i.e. sufficiently widespread; looking at you debian stable
>> users).
> 
> As far as I recall, Autoconf 2.71 did not introduce anything new, but
> mostly removed or deprecated some macros.  Using this configure.ac with
> 2.69 (which is available even on very old Debian versions, unless we go
> back to when 2.69 was first released) should, at best, not be able to
> detect if the C compiler supports C99, as 2.71 deprecated (and thus
> emits a warning) when standard revision-specific macros are used.  The
> normal AC_PROG_CC macro on 2.69 and earlier provides a C89 compiler.
> While this might be an issue, it's also true that by the time Autconf
> 2.69 was around, the majority of compilers supported C99 out of the box,
> so unless a peculiar system is targeted, where the user most likely know
> what they are doing, the "average user", even on Debian stable, should
> be able to compile GNUnet just fine.  It's not the best, I agree, but
> it's not as bad as it looks either.
> 
>> We may want to stick with "old" macros if it breaks with a significant
>> number of users' toolchain(s).
> 
> Most macros currently used on master have been around way before 2.69
> and I used pretty much only those. If anything, the main incompatibility
> might be with Automake (which I forgot to mention in my first mail,
> sorry) as it was bumped from 1.9 to 1.11 to remove a couple of
> compatibility shims from configure.ac.  Automake 1.11 should be old
> enough to be supported even by Debian users, to continue from the point
> above.  As such, it shouldn't break too easily under a "traditional"
> setup.

Sounds good to me, then! The faster we get it into master, the better then.

> 
>> 2. The "pdflatex detection is reasonable, but unfortunately not
>> sufficient which is probably why we didnt do it at all: The latex
>> plugins required are not checked.  Maybe the check should actually try
>> to compile a latex file as required by gnunet-bcd?
> 
> Right, I forgot to mention this too. Unfortunately I don't know what's
> the best way to check for a LaTeX package, so all I could do was to
> check for pdflatex and hope the user installed a sufficiently complete
> LaTeX system package from their package manager of choice.  I'll try
> adding a compilation test at least for the TikZ and qrcode packages, as
> those are the ones being used by gnunet-bcd.

Yeah that would be great. OTOH, I am also not sure of this is a must have
feature.

Anyway, the rest LGTM, so feel free to rebase+merge into master whenever.

BR
Martin

> 
> Thanks,
> A.V.
> 



signature.asc
Description: Message signed with OpenPGP

Re: From gnunet-bcd to configure.ac

[Schanzenbach, Martin]

Thanks for the work!

I reviewed the patch/branch and I am having two issues and two comments:

1. The uncrustify detection is now verbose. configure outputs the output of 
"uncrustify". Can we prevent that? It looks like an error.
2. Configure does not find my microhttpd anymore. I am not using a --with-* 
flag and it works fine in master.

Comments:
1. A thing I was wondering is if this autotools version is already "standard" 
(i.e. sufficiently widespread; looking at you debian stable users).
We may want to stick with "old" macros if it breaks with a significant number 
of users' toolchain(s).
2. The "pdflatex detection is reasonable, but unfortunately not sufficient 
which is probably why we didnt do it at all: The latex plugins required are not 
checked.
Maybe the check should actually try to compile a latex file as required by 
gnunet-bcd?

BR

> On 21. Nov 2021, at 20:10, Alessio Vanni  wrote:
> 
> Hello,
> 
> these past few weeks I've been working on a few things summarized by the
> subject of this mail.
> 
> Initially I simply wanted to replace a vector image, but I ended up
> changing a lot more stuff, including doing some major work on the
> configure.ac file.
> 
> It all started when I thought I'd try bringing the cards generated by
> gnunet-bcd more up-to-date with current GNUnet, by changing the old "gnu
> in front of a spiderweb" logo with the new "gnu made by interconnected
> points" logo.
> 
> Before I had started working on that, I had run a test to see how the
> old cards looked like, but I discovered that pdflatex would always abort
> the document generation with some rather obscure errors.  Eventually, I
> discovered that those errors were caused by an incompatibility between
> TikZ 3 and pstricks which, from what I could gather, can't be worked
> around using the methods outlined in the pstricks web page.
> 
> Due to that, other than working on adding the new logo I also had to
> rewrite the TeX files to not depend on pstricks.  Other than generating
> the old logo, it was used to create the QR code with the given GNS URI,
> so I had to search for another package for that task.  It seems the
> "qrcode" package is normally available in a "full" installation of TeX
> as distributed by major GNU/Linux distribution.
> 
> The full details will be listed later in this mail, but eventually I
> managed to rewrite the card-generating TeX file to compile with current
> TikZ and to also have the new logo.
> 
> Since I had changed the whole TeX file, I thought I might as well do the
> rest of gnunet-bcd, in a similar fashion to what I did for the FCFS
> service.
> 
> This resulted in a fairly complete overhaul of gnunet-bcd, which also
> brought a new feature to create a PNG picture of just the QR code, with
> the purpose of letting people easily embed it in other media, instead of
> having to deal with a full-fledged PDF (for example, it can be displayed
> in-line in an e-mail signature.)  Right now it provides only the QR
> code, but since it's a program that come with GNUnet and that can
> connect with GNUnet's services, it can add to the generated PNG as many
> informations as needed.
> 
> Since I had added this feature to generate a PNG, I thought it would be
> nice if gnunet-qr could read the images generated by gnunet-bcd through
> this new feature.  After a bit of work, if GNUnet's configure script
> detects that libpng is available, gnunet-qr will have a new '-f' flag
> which allows the tool to natively read a PNG file and import the scanned
> QR code, if any.
> 
> Incidentally, these changes to gnunet-qr made me discover a bug with
> gnunet-namestore, explained later.
> 
> Lastly, because I had to change configure.ac and since during a system
> update I ended up with Autoconf 2.71 installed, which generated a number
> of warnings when recompiling the configure script, I started working on
> the whole file to not only bring it up to date with the new Autoconf,
> but also to simplify it when possible and correct a few things I have
> always found strange.
> 
> Shortly after writing this mail (it's quite long!), I'm going to push a
> new branch with the following changes:
> 
> - gnunet-bcd
> The new GNUnet logo is now used. This logo is generated through a TikZ
> picture defined in the file itself.
> 
> gnunet-bcd can now generate three different files: the first is simply a
> rework of the file that is already generated; the second is a simplified
> version of that file, in which only the most basic informations, like
> the full name and a few contact addresses, are requested.  The purpose
> of this simplified version is to allow people to generate a "GNUnet
> business card" even when they can't fill most of the fields requested by
> the "full" version.  The last type of file is a PNG-encoded picture of
> the QR code for embedding.
> 
> The web UI has been reworked. It doesn't include the entire Bootstrap 4
> CSS, but contains only the necessary directives, adapted from Boostrap
> 5, to 

Re: From gnunet-bcd to configure.ac

[Schanzenbach, Martin]

> On 21. Nov 2021, at 23:26, Christian Grothoff  wrote:
> 
> Dear Alessio,
> 
> Wow, that read like a ton of great work was done that should be merged
> 'soon' ;-). I have one comment:
> 
> On 11/21/21 8:10 PM, Alessio Vanni wrote:
>> - gnunet-namestore
>> The '-u' option was broken. I forgot in which version this change was
>> made, but now public keys for egos are "stringified" by prepending a
>> readable representation of the string length before the actual key.
>> gnunet-namestore was trying to read the old format, which is six
>> characters shorter.
> 
> I'm a bit confused by this, I don't recall making this change or
> discussing something like this with anyone. What I do recall is that we
> added the cipher type sometime in the past. However, prefixing by a
> readable representation of the string length!?!? Why would we do that?
> I'm confused. If anyone could clarify this, I'd much appreciate it!
> 

Pretty sure this is just a best guess by Alessio on what those 6 characters 
mean.
This is certainly related to the key type which we added for cipher agility in 
GNS.

BR

> Happy hacking!
> 
> Christian
> 

Re: Remove me from the buildbot mailing list

[Schanzenbach, Martin]

The recent mail are probably due to the addition of nightly builds and the ARM 
worker.
As those builds failed initially until setup correctly, all commit were 
considered the "culprits".
But this should be ok now.

What we could do is let buildbot only send reports to a mailing list instead of 
the commiters directly.

> On 22. Oct 2021, at 23:19, Christian Grothoff  wrote:
> 
> Dear Yujiri,
> 
> I am very sorry for this, the big problem is that somehow the buildbot
> tries to figure out who made changes to the Git for the notification
> based on the commits --- and (often/sometimes/always?) gets this totally
> wrong.
> 
> So far, we have been unable to teach it how to correctly identify the
> 'blame list'. That's only a partial excuse, the other one is that I was
> not aware it was badly spamming even casual/history contributors (I
> thought it was just not "narrow enough", not "bothers contributors that
> contributed a long time ago").
> 
> As this is not a regular mailinglist (we didn't explicitly subscribe you
> -- Buildbot by default (badly) scrapes the Git history), we cannot
> simply "unsubscribe" you either. Hence, the only option I see right now
> is to simply disable the notification feature entirely --- or at least
> until someone can figure out how to fix it...
> 
> Again, sorry for the bother, and I'll look into this _next_.
> 
> Happy hacking!
> 
> Christian
> 
> On 10/22/21 11:14 PM, Yujiri wrote:
>> Buildbot has been spamming me with build failure emails ever since the 
>> documentation-only patch I submitted weeks ago. The content of the emails 
>> doesn't suggest any way to unsubscribe. I don't want to block sender because 
>> this is a project whose goals I adore and I hope to contribute more in the 
>> future, but I need these unsolicited irrelevant emails to stop, and it 
>> reflects poorly on the project that I was added to this list automatically 
>> with no obvious way to unsubscribe.
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: [PATCH] Improve bswap portability

[Schanzenbach, Martin]

> On 19. Sep 2021, at 19:41, Malte Voos  wrote:
> 
> Hi!
> 
> Thanks for the explanation. This may be a stupid question, but why not
> just use the bswap_* definitions from the libc?

I do not know why it is/was done in this way, possibly because there are 
platforms that use gcc but not glibc.
Maybe historically for win32 support.

> In glibc's case, bswap_*
> becomes __bswap_* (which is still not a compiler builtin, but a glibc
> internal name), which in turn becomes __builtin_bswap* if the GCC is
> recent enough. [1] In bionic's case, bswap_* always becomes
> __builtin_bswap* [2] [3]. Only musl doesn't use the builtins [4]. In my
> view, we have three options here:
> 
> * Use the bswap_* definitions provided by the libc and accept that some
>  might not use compiler builtins
> * Use __builtin_bswap*, which is supported by both non-ancient GCC [5]
>  and Clang [6]
> * Keep rolling our own bswap compatibility layer to support obscure
>  compilers. In this case, I'd suggest that we check if __builtin_bswap*
>  is available, and if not, use the manual implementations we already
>  have.
> 
> I don't think sticking with __bswap* is a good idea, since it is
> basically an implementation detail of glibc and musl, not a compiler
> builtin.

I changed it to this for now: 
https://git.gnunet.org/gnunet.git/commit/?id=83c0efff026598098addfabdf72698d5d13b7b48
May break *BSDs and obscure byteswap.h.
It uses and libc/OS bytesswap.h now if present, otherwise the fallback 
implementation.

BR

> 
> -malvo
> 
> [1] 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=string/byteswap.h;h=e9da7a4f68a095866966fafcaf09456910f40018;hb=HEAD
> [2] 
> https://android.googlesource.com/platform/bionic/+/master/libc/include/byteswap.h
> [3] 
> https://android.googlesource.com/platform/bionic/+/824f914/libc/include/sys/endian.h
> [4] https://git.musl-libc.org/cgit/musl/tree/include/byteswap.h
> [5] https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
> [6] 
> https://github.com/llvm/llvm-project/blob/2ca637c9769ff50e94ace3083075a97b50d147f0/clang/include/clang/Basic/Builtins.def#L514



signature.asc
Description: Message signed with OpenPGP

Re: [PATCH] Improve bswap portability

[Schanzenbach, Martin]

Hi,

thanks for noticing.

bswap_* and the builtin __bswap_* are not the same.
The former is a function sometimes provided by the libc, see gnulib [1].
The builtin is provided by compilers (maybe only gcc actually).
I cannot find documentation, but it seems this is sometimes also called 
__builtin_bswap*.

So the patch below does not really address the issue properly and my recent 
patch should not be a relevant regression [2].
I do not know where __bswap_* comes from, but the commit did not really 
introduce that.

I invite you to open a bug report for detailed discussions on android/bionic.
My assumption is that a suitable function needs to be detected in configure.

BR

[1] https://www.gnu.org/software/gnulib/manual/html_node/bswap_005f32.html
[2] 
https://git.gnunet.org/gnunet.git/commit/?id=3ae831780b5681764a7d0505fa94f3fdaa43e1d8

> On 19. Sep 2021, at 10:34, Malte Voos  wrote:
> 
> The official function names are bswap_*, not __bswap_*. The latter won't
> compile with Android's bionic libc.
> ---
> src/include/gnunet_common.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/src/include/gnunet_common.h b/src/include/gnunet_common.h
> index ca3ddceaa..b09fef93f 100644
> --- a/src/include/gnunet_common.h
> +++ b/src/include/gnunet_common.h
> @@ -152,9 +152,9 @@ enum GNUNET_GenericReturnValue
> 
> #if __BYTE_ORDER == __LITTLE_ENDIAN
> #if defined(__linux__)
> -#define BYTE_SWAP_16(x) __bswap_16 (x)
> -#define BYTE_SWAP_32(x) __bswap_32 (x)
> -#define BYTE_SWAP_64(x) __bswap_64 (x)
> +#define BYTE_SWAP_16(x) bswap_16 (x)
> +#define BYTE_SWAP_32(x) bswap_32 (x)
> +#define BYTE_SWAP_64(x) bswap_64 (x)
> #else
> #define BYTE_SWAP_16(x) x) & 0x00ff) << 8) | (((x) & 0xff00) >> 8))
> 
> -- 
> 2.32.0
> 
> 

Re: Pre-announcement of partial Scheme port of client libraries

[Schanzenbach, Martin]

Hi Maxime,

> On 15. Sep 2021, at 12:57, Maxime Devos  wrote:
> 
> Hi,
> 
> I've been porting parts of the client libraries of GNUnet to Guile (*) and
> changing a few things.  It now has sufficient functionality for a v0.1
> POC release (**), but I have a few questions to ask before I announce it.
> 
> (*) See ‘4. Relation to gnunet-guile’ for differences with
>  and
> ;.
> (**) It can talk with the NSE service.
> 
> 1. Name
> 
>   I've been calling the port ‘Scheme-GNUnet’.  Would this be acceptable,
>   or do I have to remove GNUnet from the name?
> 

You can call it however you want, most other libraries/bindings start with 
"gnunet-".
Personally, I would prefer to have it follow this scheme, but I do not really 
mind.

> 2. Infrastructure
> 
>   As it is library for interacting with GNUnet services, I thought
>   the pre-existing gnunet-developers@gnu.org, help-gnu...@gnu.org and
>   info-gnu...@gnu.org mailing lists might be appropriate.  Can I direct
>   people help-gnunet@ for help about Scheme-GNUnet and gnunet-developers@
>   for sending patches for Scheme-GNUnet?  And can I send release announcements
>   at info-gnunet@?

You may use our infrastructure (esp, git.gnunet.org) under the terms of the 
project and especially under the terms of the copyright assignment.
I would assume that given the limited traffic your mailing lists have at this 
time, using them is not a problem.
Should the situation change, we can figure something out then.

> 
> 3. Copyright assignment
> 
>   I noticed most source code of GNUnet, with some exceptions, only lists
>   ‘GNUnet e.V.’ under the copyright notices.  Would it be possible for
>   contributors to Scheme-GNUnet to (if they want to) assign the copyright
>   to GNUnet e.V.?  And would this be desirable?
> 

If you use git.gnunet.org, the CA covers this piece of "software" as well.
Please refer to the CA for details.
Note that the CA automatically applies to all the software under git.gnunet.org 
and the copyright must be assigned in order to get commit rights.
I would assume that for all gnunet software (especially bindings) yes, this 
would be desirable.

> 4. Relation to gnunet-guile (not a question).
> 
> Some may be wondering why I didn't use the
>  or
>  Guile bindings instead of writing
> my own ;.  The answer is that:
> 
>   (1) I didn't write Guile->C bindings, I ported parts of GNUnet from C to
>   Guile
>   (2) A few parts of the Guile bindings are reused in the Guile port
>   (3) there were some crashes with the Guile bindings (things like
>   NULL-pointer exceptions)
>   (4) I couldn't figure out the issue
>   (5) I would like to use GNUnet from within guile-fibers, but didn't succeed
>   in letting the C event loop cooperate with guile-fibers' scheduling
>   (6) I find Scheme easier to hack on than C.

In general this is a valid (but also potentially tedious) approach.
bfix is doing the same in Go: https://github.com/bfix/gnunet-go

We should think about how to handle the confusion with the other repos.
I am not familiar with gnunet-guile(2), but from what you are writing it 
appears as if we may want to consider deprecating and archiving those repos.
Maybe it makes sense to rename gnunet-guile2 to gnunet-bindings-guile and 
calling yours gnunet-guile or something like that.

@grothoff wdyt?

BR
Martin

> 
> For the interested, I have included a copy of the manual.
> 
> Greetings,
> Maxime.
> 



signature.asc
Description: Message signed with OpenPGP

Re: Gettext macros (and a couple other ones)

[Schanzenbach, Martin]

I don't think this is necessary for macOS, and keeping it would be questionable 
at best anyway ;)

Removed in 279533005..3da9cbd62

> On 5. Sep 2021, at 19:01, Christian Grothoff  wrote:
> 
> Hi Alessio,
> 
> I checked, and this was done (a long time ago) to support OS X builds.
> There doesn't seem a pressing reason to keep it, I doubt anyone has
> build GNUnet on OS X for a while, and there might be a much better
> solution today for OS X anyway.
> 
> My 2 cents
> 
> Christian
> 
> On 8/29/21 7:15 PM, Alessio Vanni wrote:
>> Christian Grothoff  writes:
>> 
>>> Good point, but that's a specific issue with that macro, which I agree
>>> should not use "_" but dgettext(). I've fixed this (and a few related)
>>> instance(s) in Git master just now.
>> 
>> Hello,
>> 
>> thanks for the fix.
>> 
>> Related to this issue: since those macros explicitly use `dgettext' I
>> thought I'd try to place the "gettext.h" header directly inside
>> "gnunet_common.h", so that `dgettext' is always defined, but I
>> discovered that "platform.h" contains this snippet:
>> 
>> #include 
>> #ifndef FRAMEWORK_BUILD
>> #include "gettext.h"
>> /**
>> * GNU gettext support macro.
>> */
>> #define _(String) dgettext (PACKAGE, String)
>> #define LIBEXTRACTOR_GETTEXT_DOMAIN "libextractor"
>> #else
>> #include "libintlemu.h"
>> #define _(String) dgettext ("org.gnunet.gnunet", String)
>> #define LIBEXTRACTOR_GETTEXT_DOMAIN "org.gnunet.libextractor"
>> #endif
>> 
>> It appears that FRAMEWORK_BUILD is never defined anywhere, even though
>> it's part of `gnunet_config.h.in'.  Is it safe to remove it?
>> 
>> In case it can be removed, then "gettext.h" can be simply included by
>> "gnunet_common.h" too since multiple inclusions are guarded by the
>> preprocessor, meaning that GNUnet will keep using the `_' macro defined
>> by "platform.h" while other applications don't have to explicitly add
>> "#include " before including the "gnunet_util_lib.h"
>> header.
>> 
>> If it can't be removed, things are going to be a bit inconsistent, since
>> "gettext.h" would be included even when it shouldn't. The #ifndef check
>> can't be reliably performed inside "gnunet_common.h" for the same
>> reasons why GNUNET_AGPL_URL can give an incorrect value, i.e. it's a
>> public header which can get values from anything included before it,
>> like a "config.h" generated by Autoconf and thus FRAMEWORK_BUILD might
>> be defined for unrelated reasons, making things break unexpectedly.
>> 
>> Thanks,
>> A.V.
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Mantis git integration

[Schanzenbach, Martin]

Dear devs,

you can now use git commit messages to reference mantis issues.
In order to mention an issue, use "Issue #" anywhere in your commit 
message.
Instead of "Issue", "Bug" and "Report" as well as plurals also work.

If you want to automatically resolve the issue, use "Fixes #".

An example is here: https://bugs.gnunet.org/view.php?id=7009

BR
Martin


signature.asc
Description: Message signed with OpenPGP

Re: Git server migration

[Schanzenbach, Martin]

Hi,

there were long discussions on this topic. The biggest issue is that it would 
either require a migration of
issues from mantis or a cut (Feel free to browse the ML archives).
Also, the current gitolite setup can be administered completely via config 
files in git, which is something gitlab is way too bloated for.
In general, I would also prefer separate, lean services over a single behemoth.
But I also see the easy of use and shininess of gitlab.

In general, I have most issues with mantis (which are mostly that is feels like 
a tool form 1999) and I like buildbot and gitolite.

BR

> On 1. Sep 2021, at 19:55, madmurphy  wrote:
> 
> Any plans to install GitLab FOSS on the GNUnet git server (i.e., a fork of 
> GitLab with all proprietary code removed)?
> 
> On Wed, Sep 1, 2021 at 6:21 PM Schanzenbach, Martin  
> wrote:
> Hi,
> 
> along with some other services, we are moving the gitolite service to another 
> server.
> Unfortunately, we cannot move the gnunet.org domain just yet, so you may have 
> to change your
> repository urls from g...@gnunet.org/repo to g...@git.gnunet.org/repo
> ( you need to add a "git." in front of gnunet.org)
> 
> In case this should not already work for you, please contact me.
> The cgit web UI is still under construction.
> 
> Sorry for the inconvenience.
> 
> Martin



signature.asc
Description: Message signed with OpenPGP

Git server migration

[Schanzenbach, Martin]

Hi,

along with some other services, we are moving the gitolite service to another 
server.
Unfortunately, we cannot move the gnunet.org domain just yet, so you may have 
to change your
repository urls from g...@gnunet.org/repo to g...@git.gnunet.org/repo
( you need to add a "git." in front of gnunet.org)

In case this should not already work for you, please contact me.
The cgit web UI is still under construction.

Sorry for the inconvenience.

Martin


signature.asc
Description: Message signed with OpenPGP

GNUnet 0.15.0 released

[Schanzenbach, Martin]

We are pleased to announce the release of GNUnet 0.15.0.
This is a new major release. It breaks protocol compatibility with the 0.14.x 
versions. Please be aware that Git master is thus henceforth INCOMPATIBLE with 
the 0.14.x GNUnet network, and interactions between old and new peers will 
result in issues. 0.14.x peers will be able to communicate with Git master or 
0.14.x peers, but some services - in particular GNS - will not be compatible.
The MESSENGER service goes out of experimental to be used by libraries and 
applications as dependency. It handles decentralized messaging in flexible 
groups by using the CADET service and messages can be signed with your ego from 
the IDENTITY service. The service is still in an early stage, so its protocol 
(currently version 0.1) will likely adapt or change in future releases to some 
degree.
In terms of usability, users should be aware that there are still a number of 
known open issues in particular with respect to ease of use, but also some 
critical privacy issues especially for mobile users. Also, the nascent network 
is tiny and thus unlikely to provide good anonymity or extensive amounts of 
interesting information. As a result, the 0.15.0 release is still only suitable 
for early adopters with some reasonable pain tolerance.

Download links:

http://ftpmirror.gnu.org/gnunet/gnunet-0.15.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-0.15.0.tar.gz.sig
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.15.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.15.0.tar.gz.sig
http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.15.0.tar.gz
http://ftpmirror.gnu.org/gnunet/gnunet-fuse-0.15.0.tar.gz.sig

The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

Note that due to mirror synchronization, not all links may be functional
early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/

Noteworthy changes in 0.15.0 (since 0.14.1):

GNS:
 - First-come-first-served GNUnet top-level domain ".pin" zone key and website 
updated a. Register here. #6832
 - New EDKEY zone keys.
SCALARPRODUCT: Crypto ported to libsodium improving performance. #6818
RECLAIM: Added support for BBS+ blind signature credentials for selective 
disclosure.
UTIL:
 - Swap gnunet-config's default behaviour for the rewrite flag.
 - Config file is not not always written
 - Introduced new TIME helper functions
SETU: Implemented set union subsystem along with technical specification 
LSD0003.
MESSENGER: New messenger component moved out of experimental.

A detailed list of changes can be found in the ChangeLog and the 0.15.0
bugtracker at https://bugs.gnunet.org/changelog_page.php?project_id=13.

Thanks:
This release was the work of many people. The following people contributed code 
and were thus easily identified:
Christian Grothoff, Daniel Golle, Alessio Vanni, Thien-Thi Nguyen, Elias 
Summermatter, t3sserakt, TheJackiMonster and Martin Schanzenbach.


signature.asc
Description: Message signed with OpenPGP

Re: gnunet-config and build informations (bug #5708)

[Schanzenbach, Martin]

IDK this does not sound like a good feature to me.
I understand that it is possible, but it does not really make sense.

Any application/project using gnunet(util) should provide its own *-config.
Having gnunet-config be able to dynamically load different configurations is 
asking for trouble.

I would rather have taler provide its own binary and functionality. After all, 
it does have its own sources.
It also may have its own requirements for the -config tool at which point not 
only do we possibly have a very oddly behaving gnunet-config
as it depends on the LD_PRELOAD, but taler also cannot really add 
taler-specific flags to it.

BR

> On 25. Jul 2021, at 08:18, Christian Grothoff  wrote:
> 
> hi Alessio,
> 
> Two points:
> - good autoconf macro would indeed be appreciated
> - gnunet-config patch looks good, except for some funky requirement:
> 
> GNU Taler has taler-config, which recycles gnunet-config in a funky way
> using LD_PRELOAD:
> 
> https://git.taler.net/exchange.git/tree/src/util/taler-config.in
> 
> This works, because there is:
> https://git.taler.net/exchange.git/tree/src/util/os_installation.c
> 
> which overrides gnunet-config settings to turn it into taler-config!
> 
> So _ideally_, we would use the GNUNET_OS_ProjectData instead of directly
> using hard-coded values for the output of the new flags. That way, we
> could modify GNU Taler so that taler-config will not return the GNUnet
> flags, but the Taler flags (again using preload, without copying the
> source!)
> 
> My 2 cents
> 
> Christian
> 
> On 24.07.21 22:51, Alessio Vanni wrote:
>> Hello,
>> 
>> I made an attempt at implementing what was discussed in bug #5708 [0],
>> that is, additional flags for `gnunet-config' to print various
>> informations similar to what other `*-config' tools do
>> (e.g. `nss-config'.)
>> 
>> After sending this mail I'm going to push a branch called
>> 'dev/vanni/build-info'; it's a separate branch because even though the
>> changes are very simple (even including the documentation), I'd like to
>> get some feedback first, especially if more flags are requested.
>> 
>> The following is a bit off-topic, but since it's something that might
>> leverage the new gnunet-config flags, I'm going to ask here regardless.
>> 
>> Would it be possible to provide with the core GNUnet installation an
>> Autoconf macro to detect GNUnet properly?  I'm using Autoconf to manage
>> the GNUnet-based applications I'm writing, but detecting GNUnet is a bit
>> of a mess.
>> 
>> Of course with the new gnunet-config I can just rely on it, but if I had
>> a macro provided by GNUnet itself, much like other programs like for
>> example Guile Scheme do [1], it'd be better.
>> 
>> This is especially true as getting a third-party GNUnet-based
>> application to compile has surprising caveats: a very noticeable one is
>> that, apparently, the `netinet/in.h' header is required when neither
>> `gnunet_config.h' nor `platform.h' are `#include'd (which is what
>> happens with third-party applications, at least those built using
>> Autoconf.)
>> 
>> This is something that can be noticed only when the program is actually
>> compiled, but with a GNUnet-specific macro the check for the necessary
>> headers (and all that it entails) can be done implicitly by the macro
>> itself.
>> 
>> I've made an attempt locally which first uses pkg-config and then falls
>> back to the new gnunet-config, but before pushing it to the remote
>> repository I'd like, once again, to hear some feedback on the matter, be
>> it to pay attention to certain configurations or even be just a matter
>> of following certain conventions.
>> 
>> Thank you,
>> A.V.
>> 
>> ---
>> 
>> [0] https://bugs.gnunet.org/view.php?id=5708
>> [1] 
>> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=meta/guile.m4;h=48642f027f7b002d40658511fe3bb831e83ebdfc;hb=HEAD
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: gnunet-config and build informations (bug #5708)

[Schanzenbach, Martin]

Hello Alessio,

thanks for the work!

I personally have never written an autoconf macro, but I would assume that it
makes sense to have it.

Regarding your patch: Lgtm, it addresses the first (basic) feature how I would 
expect it to happen.
Which is allowing the caller to retrieve cflags or ldflags.
This is what most *-config programs _also_ do and what our *.pc files should 
provide as well through pkg-config.

But what the OP in the report also and possibly primarily thinks is missing is 
a way to get the build information
which is output on configure at the end which is useful for users to understand 
what kind of build configuration their gnunet installation is in.
E.g. the things listed at
https://git.gnunet.org/gnunet.git/tree/configure.ac#n2199 and following.

Similar to, for example:
$ libgcrypt-config --algorithms

I would assume something like

$ gnunet-config --transports
or
$ gnunet-config --experimental
or
$ gnunet-config --http-client-backend
etc

is what is expected.
So I think it makes sense to keep the bug open, but I think we can still get 
this in for 0.15.0.

Thanks again and BR
Martin

On 24. Jul 2021, at 22:51, Alessio Vanni  wrote:
> 
> Hello,
> 
> I made an attempt at implementing what was discussed in bug #5708 [0],
> that is, additional flags for `gnunet-config' to print various
> informations similar to what other `*-config' tools do
> (e.g. `nss-config'.)
> 
> After sending this mail I'm going to push a branch called
> 'dev/vanni/build-info'; it's a separate branch because even though the
> changes are very simple (even including the documentation), I'd like to
> get some feedback first, especially if more flags are requested.
> 
> The following is a bit off-topic, but since it's something that might
> leverage the new gnunet-config flags, I'm going to ask here regardless.
> 
> Would it be possible to provide with the core GNUnet installation an
> Autoconf macro to detect GNUnet properly?  I'm using Autoconf to manage
> the GNUnet-based applications I'm writing, but detecting GNUnet is a bit
> of a mess.
> 
> Of course with the new gnunet-config I can just rely on it, but if I had
> a macro provided by GNUnet itself, much like other programs like for
> example Guile Scheme do [1], it'd be better.
> 
> This is especially true as getting a third-party GNUnet-based
> application to compile has surprising caveats: a very noticeable one is
> that, apparently, the `netinet/in.h' header is required when neither
> `gnunet_config.h' nor `platform.h' are `#include'd (which is what
> happens with third-party applications, at least those built using
> Autoconf.)
> 
> This is something that can be noticed only when the program is actually
> compiled, but with a GNUnet-specific macro the check for the necessary
> headers (and all that it entails) can be done implicitly by the macro
> itself.
> 
> I've made an attempt locally which first uses pkg-config and then falls
> back to the new gnunet-config, but before pushing it to the remote
> repository I'd like, once again, to hear some feedback on the matter, be
> it to pay attention to certain configurations or even be just a matter
> of following certain conventions.
> 
> Thank you,
> A.V.
> 
> ---
> 
> [0] https://bugs.gnunet.org/view.php?id=5708
> [1] 
> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob;f=meta/guile.m4;h=48642f027f7b002d40658511fe3bb831e83ebdfc;hb=HEAD
> 



signature.asc
Description: Message signed with OpenPGP

Re: Compiling in OpenBSD: cannot find libsodium

[Schanzenbach, Martin]

Hi anoduck,

I think we did not include --with-sodium switches.
Can you try setting
$ export CFLAGS="$CFLAGS -I/usr/local/include"

and

$ export LDFLAGS="$LDFLAGS -L/usr/local/lib"
$ ./configure --prefix=...

to see if that at least fixes your build?

BR
Martin

> On 26. Jun 2021, at 04:25, anoduck  wrote:
> 
> During the `/configure --prefix=$GNUNET_PREFIX/..` command, configure cannot 
> not locate libsodium. Libsodium is located in 
> `/usr/local/lib/libsodium.so.24.0` which is the same as the gnunet prefix. I 
> tried using `--with-libsodium=/usr/local/lib` which didn't work, then I tried 
> using the `--ldflags` which didn't work, and I also tried using `-L` that 
> didn't work. I cannot remember how I should reference the location of the 
> sodium library to successfully achieve setup for compilation.
> 
> Thanks,
> anoduck
> 
> Sent with ProtonMail Secure Email.
> 



signature.asc
Description: Message signed with OpenPGP

Re: CADET API: Obtaining the CADET channel closure?

[Schanzenbach, Martin]

Hi Alessio,

> On 1. Jun 2021, at 21:23, Alessio Vanni  wrote:
> 
> Christian Grothoff  writes:
> 
>> Hi Alessio,
>> 
>> You should store a copy of the 'cls' together with your channel handle.
>> Typically, the 'cls' would actually point to the struct in which you
>> store your channel handle. So if you do this in any reasonable way, you
>> should not need an API to lookup the 'cls' from the handle.
>> 
>> If you can point me to your code and where you need the 'cls', I might
>> be able to suggest how to do this...
> 
> Apologies for the late reply, I had some personal troubles I had to take
> care of and it took a few days.
> 
> Getting the code out of context is a bit hard, but essentially currently
> it does this, at a very high level:
> 
> - on demand, open a channel to some place
> - stash the channel somewhere until it's requested again or closed
> - when appropriate, operate on the channel (sending or receiving)
> - close the channel on demand or after some heuristics decide to
> 
> Those actions in themselves are not issues conceptually, but as it is
> I've found myself that in some places I have only the channel but I also
> need e.g. some informations about the place it was stored in, and those
> informations are not available "externally", at least for now, thus the
> attempt at extracting the closure.
> 
> I'm trying to redesign the thing so that it doesn't depend on that, but
> so far it's been a bit difficult, which is why I asked if it was
> possible to get the closure somehow.
> 
> This was mostly a question about style or best practices, I guess, more
> than something technical.  If it's really "not the right thing" to do,
> I'll try to depend less on the closure on the channel and see if I can
> use some other data type somehow.
> 

As Christian said it is quite common to "wrap" the "bare" handle into a struct 
which
has a reference to the closure data.
So in this case, the "struct GNUNET_CADET_Channel" is the "bare" handle, so 
when you
create it using "GNUNET_CADET_channel_create" (where you also provide the 
closure)
instead of "storing" the handle, you create a new helper struct instance. For 
example:

struct MyChannelHandle
{
  struct GNUNET_CADET_Channel *handle;
  void *cls; // This does not have to be void. its your context data/closure
};

So, in your application/service context, the handle to a CADET channel is not 
only the bare
handle. At least if you plan to use a closure. It is the handle AND the 
closure. So you need
such a helper struct.
In fact, it is very likely that you need such a struct anyway in order to 
"cleanup" if your
process is shut down: You must have a way to iterate and destroy all handles.
So often, the helper struct actually looks like this:

struct MyChannelHandle
{
  struct MyChannelHandle *prev; // DLL
  struct MyChannelHandle *next; // DLL
  struct GNUNET_CADET_Channel *handle;
  void *cls; // This does not have to be void
};

This allows you to use the struct as a DLL (gnunet_container_lib.h).
When you "manually" handle a CADET connection in your code, you should always
handle a MyChannelHandle.

Now one trick you can do is to use the MyChannelHandle as the closure to the 
CADET API itself.
This way, you do not need to iterate over the DLL when being called with the
closure only. (helpful for cleanup)

BR
Martin


> Thanks,
> A.V.
> 



signature.asc
Description: Message signed with OpenPGP

Re: Improving FCFS daemon

[Schanzenbach, Martin]

I am not sure of the NULL is a requirement of va_arg.
The examples do not indicate that. And as I said the issue only arises when
the argument is coming from gettext.
So the issue lies somewhere else, but I do not know where.
Maybe this is a general gettext/va_arg incompatibility.

BR

> On 16. May 2021, at 23:13, Alessio Vanni  wrote:
> 
> Alessio Vanni  writes:
> 
>> Huh, that's strange. Admittedly, I didn't properly test successful
>> insertions, but I didn't get any crash on errors.
>> I'll check it out.
> 
> I pushed a fix for this.
> It was indeed because I had forgotten to put terminating NULL values in
> the `make_json' function calls.
> 
>> I'll add a section in the handbook after fixing the crash.
> 
> I also pushed a draft of a section dedicated to FCFSD.
> It was placed under GNS, as it's probably more appropriate.
> 
> I tried to be as informative as possible; please do provide feedback.
> 
> Thanks,
> A.V.
> 



signature.asc
Description: Message signed with OpenPGP

Re: Improving FCFS daemon

[Schanzenbach, Martin]

Ah nevermind. It is because your make_json checks for that.
Looks good to me. The crash is fixed.
Can be merged from my point of view.
The only thing left is probably a link from the gns section on the homepage
to the fcfs service.

Thanks
BR
Martin

> On 17. May 2021, at 13:36, Schanzenbach, Martin  
> wrote:
> 
> I am not sure of the NULL is a requirement of va_arg.
> The examples do not indicate that. And as I said the issue only arises when
> the argument is coming from gettext.
> So the issue lies somewhere else, but I do not know where.
> Maybe this is a general gettext/va_arg incompatibility.
> 
> BR
> 
>> On 16. May 2021, at 23:13, Alessio Vanni  wrote:
>> 
>> Alessio Vanni  writes:
>> 
>>> Huh, that's strange. Admittedly, I didn't properly test successful
>>> insertions, but I didn't get any crash on errors.
>>> I'll check it out.
>> 
>> I pushed a fix for this.
>> It was indeed because I had forgotten to put terminating NULL values in
>> the `make_json' function calls.
>> 
>>> I'll add a section in the handbook after fixing the crash.
>> 
>> I also pushed a draft of a section dedicated to FCFSD.
>> It was placed under GNS, as it's probably more appropriate.
>> 
>> I tried to be as informative as possible; please do provide feedback.
>> 
>> Thanks,
>> A.V.
>> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Improving FCFS daemon

[Schanzenbach, Martin]

> On 16. May 2021, at 13:53, Christian Grothoff  wrote:
> 
> FCFS is just a software that allows anyone to run a
> first-come-first-served registry. That's not something for GANA.
> 

Yes, but the policy for "pin" may be.

> We early on made the decision that the ".pin" zone would be public and
> free of charge, but of course extensions adding an option in the FCFS
> implementation to realize a non-public registry, or one where
> registration must be paid (say with GNU Taler?) are welcome. But those
> should then not be ".pin" but something else.

Hmm a Taler-based registry would be a nice little project. But the more I think
about it the less it makes sense to "extend" fcfsd.

> 
> What we could do is create a registry of default GNS top-level zones in
> GANA, and there we'd then put the public key of '.pin', together with
> other such registries. The tricky bit here is that we will need a policy
> that defines the process for adding and removing such entries. I think
> initially something simple would do, like "convince the GNUnet
> maintainers to add your zone". We can then decide on a case-by-case
> basis how high the bribe needs to be. ;-)

Yes, we should draft that.

BR
Martin

> 
> On 5/16/21 11:26 AM, Schanzenbach, Martin wrote:
>> We may also think about if the FCFS service falls under the authority of 
>> GANA.
>> Alessio made a good point wrt hidden names which would mean that we do not
>> want to put all registered names in GANA anyway, but the handling of FCFS and
>> its policy could be defined there.
>> 
>> BR
>> 
>>> On 16. May 2021, at 10:00, Christian Grothoff  wrote:
>>> 
>>> On 5/15/21 10:19 PM, Alessio Vanni wrote:
>>>> I'll add a section in the handbook after fixing the crash.
>>>> Should it be added as a subsection of NAMESTORE? I'm not really sure
>>>> where it would be more appropriate, but since at a source level it's in
>>>> the same directory, that seems to be a possible candidate.
>>> 
>>> I'd have put it under GNU Name System into a separate section. But,
>>> NAMESTORE is also not wrong.
>>> 
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Improving FCFS daemon

[Schanzenbach, Martin]

We may also think about if the FCFS service falls under the authority of GANA.
Alessio made a good point wrt hidden names which would mean that we do not
want to put all registered names in GANA anyway, but the handling of FCFS and
its policy could be defined there.

BR

> On 16. May 2021, at 10:00, Christian Grothoff  wrote:
> 
> On 5/15/21 10:19 PM, Alessio Vanni wrote:
>> I'll add a section in the handbook after fixing the crash.
>> Should it be added as a subsection of NAMESTORE? I'm not really sure
>> where it would be more appropriate, but since at a source level it's in
>> the same directory, that seems to be a possible candidate.
> 
> I'd have put it under GNU Name System into a separate section. But,
> NAMESTORE is also not wrong.
> 



signature.asc
Description: Message signed with OpenPGP

Re: Improving FCFS daemon

[Schanzenbach, Martin]

Oh and thanks for the very verbose commit message detailing the changes.
I suggest directly putting this information as a handbook section into the repo.

The commit message itself can be much more succinct then.

BR

> On 15. May 2021, at 16:17, Alessio Vanni  wrote:
> 
> Hello,
> 
> I was looking at the list of bugs on Mantis and through [1] I discovered
> the FCFS daemon (the namestore is not a component I've checked in
> details.)
> 
> I think it's a useful tool, so I tried improving it.
> 
> I pushed a branch called "/dev/vanni/fcfsd" and the (currently only)
> commit adding the changes explains the choices I took.
> 
> Feedback is appreciated.
> 
> Thanks,
> A.V.
> 
> P.S.: for reasons I haven't really fully understood, GPG would refuse to
> sign my commit when I was trying to push the branch these past days.
> Eventually, I managed to fix it, but I had to scrap my whole
> configuration and start adding back things incrementally.
> 
> Hopefully, nothing bad happened, especially as I'm afraid to touch the
> configuration again as I fear it will break again.
> 
> [1] https://bugs.gnunet.org/view.php?id=6832
> 



signature.asc
Description: Message signed with OpenPGP