Re: Testing of non-exposed functions

[Christian Grothoff]

On 6/5/24 11:57, Julius Bünger wrote:

Hi all,

I have a question of secondary importance:

I recently asked the question whether we do unit tests in gnunet. Looking
at the examples pointed to in reply, I realize that I probably didn't
ask for what I meant. What I meant was:

Do we write tests for functions that are not exposed via API? And if so:
How do we?


We so far never do, we only write unit tests against the exposed API. 
This has so far usually been more than enough, but also see below...



The example at hand:
I think the pattern matching function of GNUNET_DISK_glob() has a bug
and I would like to test the pattern matching function without actually
interacting with the file system, without calling GNUNET_DISK_glob().

If there's no proper way, I'll simply go ahead and expand the
test_disk.c to cover GNUNET_DISK_glob() via the exposed API call.


Well, one thing you could do in this case is to expose the pattern 
matching function as part of the API, after all, the pattern matching 
logic itself could be useful to others as well.


My 2 cents

Christian

Re: [PATCH gnunet-handbook] add evans thesis to users docs

[Christian Grothoff]

Applied, thanks! -christian

On 6/2/24 11:06, Nikolaos Chatzikonstantinou wrote:

Hello,

This patch is for gnunet-handbook

First time small contribution here, see attachment.

Regards,
Nikolaos Chatzikonstantinou

Re: Fedora Packaging: gethostbyname

[Christian Grothoff]

Dear Benson,

If you look closely, getaddrinfo is used by the code by default, with 
fallbacks (!) to gethostbyname if getaddrinfo doesn't work. I don't 
think we want to accept a patch that removes the fallbacks, as that 
wouldn't do anything on modern platforms and only hurt portability.


Happy hacking!

Christian

On 5/16/24 06:46, Benson Muite wrote:

Hi,

Would like to make GNUnet available in Fedora based on the spec file
available at:
https://git.gnunet.org/gnunet-rpm.git/tree/rpmbuild/SPECS/gnunet.spec

One of the warnings I get from the automated review helper tool is that
gethostbyname is used:
https://download.copr.fedorainfracloud.org/results/fed500/gnunet/fedora-rawhide-x86_64/07448019-gnunet/fedora-review/review.txt

See
src/lib/util/resolver_api.c:host = gethostbyname2 (hostname,
src/lib/util/resolver_api.c:  host = gethostbyname2 (hostname,
src/lib/util/resolver_api.c:host = gethostbyname (hostname);
src/service/util/test_resolver_api.c:  rootserver = gethostbyname
(rootserver_name);

src/service/arm/test_gnunet_service_arm.c:host = gethostbyname2
(hostname, AF_INET);
src/service/arm/test_gnunet_service_arm.c:  host = gethostbyname2
(hostname, AF_INET6);
src/service/arm/test_gnunet_service_arm.c:host = gethostbyname
(hostname);

As gethostbyname has been deprecated, would a patch to use getaddrinfo
instead be considered?

Benson

Re: Get togethers?

[Christian Grothoff]

On 4/26/24 8:21 AM, George wrote:

Hi Christian,

Thanks for the list!


Sure.


I found the details for most of the events, but not all.




Open Forum Digital Euro is in Vienna June 25th

https://openforumeurope.org/

I cannot find any events for June on their webpage. Have I got the wrong 
organisation?


I doubt there is already a Web site, but this is the 2023 event:

https://www.oenb.at/Termine/2023/2023-06-26-open-forum-digitaler-euro.html




Swiss PG day is in Rapperswill June 27th

https://www.pgday.ch/2024/
"This conference is all about PostgreSQL - the world's most advanced open source 
database. Take the opportunity to meet with other people interested in PostgreSQL in 
Switzerland."


cosin.ch is in Biel June 28-30th

https://cosin.ch/de/
"CoSin is short for Chaos Singularity. We are not quite sure what that means, but we 
do know, what we want with it: We hope to provide a chance for geeks, nerds, hackers, 
discordians, chaots and other interested or curious people, to meet, learn, chat, have 
fun and relax. During three days, we’d like to offer the opportunity to investigate 
technology, think about its effects on society, or just chat with other participants in a 
relaxed atmosphere."

https://cosin.ch/en/fahrplan/
Schedule 2024
Schedule of this year's CoSin will be online in early June.



PointZeroForum.ch is in Zurich July 1-3, with an innovation stop tour at NGI 
TALER at BFH in Biel on July 1st

https://www.pointzeroforum.com/
"This Annual Forum convenes 2,000 central bankers, regulators, policymakers, 
industry leaders, technologists and investors to address the latest developments in 
financial technology and the future of finance."

Payment related talks look interesting.




Just to clarify. The only GNUnet related event during this period is the NGI 
Taler tour @ BFH?


Well, indeed none are *directly* GNUnet-related, but some might be 
interesting to some GNUnet hackers. And as hackers we are often, eh, 
broadly interested ;-).



And it's unlikely there would be a GNUnet event at decentrale.ch (Mont-Soleil) 
as you are busy. Is that correct?


Not exactly: if it is not a hard conflict with these events and somebody 
*else* is _organizing_ some GNUnet event, I might be game... And even if 
it is conflicting, well, there can be GNUnet meetings without me, too.


-Christian

Re: Get togethers?

[Christian Grothoff]

Hi George,

Thansk for reminding us that it might be a good idea to meet in person 
sometimes ;-).  While we've not done the end of June meetings recently, 
that will be a fun time this year:


Open Forum Digital Euro is in Vienna June 25th
Swiss PG day is in Rapperswill June 27th
cosin.ch is in Biel June 28-30th
PointZeroForum.ch is in Zurich July 1-3, with an innovation stop
  tour at NGI TALER at BFH in Biel on July 1st

Plus these are the exam weeks at my university ;-).  So on the one hand, 
already a rather stressful period, OTOH plenty of reasons for people to 
go to Switzerland.


Right now, I would personally be able to go to decentrale.ch 
(Mont-Soleil) only July 4-8 and *maybe* June 22-25 (but there is a 
potential for a hard conflict those days). But, regardless, I don't 
think I'll have the capacity to properly *organize* such an event, even 
though I think it would be a good idea!


Cheers!

Christian


On 4/25/24 08:35, George via Mailinglist for GNUnet developers wrote:

Hi,

I've been playing around with gnunet for a while and love the philosophy 
behind GNUnet.


Hopefully, I'll be traveling through EU May/June/July this year and 
wanted to attend a GNUnet meeting / gathering.


On the engage page (https://www.gnunet.org/en/engage.html 
) there is a list of regular 
face-to-face gatherings. Looks like the only option for me is:


"GNUnet Hackweek in Mont-Soleil (CH), usually by the end of June"

Is this happening this year?

Are there any solid plans for meetings / gatherings in Germany / 
Switzerland / EU around May/June/July? I'd be keen to attend.


Much appreciate your efforts.

Cheers,
GK2

Sent with Proton Mail  secure email.

Re: Registering a new target type for payto URI

[Christian Grothoff]

Dear Stephen,

Yes, this (or ta...@gnu.org) is the right place. If you have a web page 
documenting the syntax, that'd be ideal so we can reference it from the 
registry.


Beyond that, happy to add it to the registry!

Happy hacking!

Christian

On 3/19/24 18:24, Stephen Paul Weber wrote:
As per rfc8905 it seems that GNUnet/GANA are the official registry for 
payto target types. Is this list the right place to discuss registering 
a new one?


I would like to register one for Interac e-Transfer which is a popular 
instant payment system in canada.  Would look something like:


payto://interac-etransfer/u...@example.com

Or since phone numbers can also be targets:

payto://interac-etransfer/+15551234567

Re: unsuitable protocols and standards that block innovation

[Christian Grothoff]

Secure multiparty computation scalar product. See
   https://grothoff.org/christian/bfh2017.pdf
(implemented as the 'scalarproduct' service)

On 3/13/24 15:47, Runa Loki Schmidt wrote:

Talking about twitter like uses, I am really curious how a content curating 
algorithm would be implemented on a decentralised multicast network.

These kind of algorithms have been a major point of attraction to that kind of 
platform (twitter, instagram, tiktok), as people want content that is broader 
than their ‘peer group’ but still filtered to their personal preferences.

On 11 March 2024 17:19:06 CET, carlo von lynX  
wrote:



This implements (1) from what I can see, and thus only reduces the amount
of data distributed a bit, but not the challenge of distributing
stuff to millions of recipients in a Twitter-like use case.


- The multicasting part looks very interesting. Can you expand on how that
would work in a distributed network like gnunet? Because it specifically
mentions a server solution which we cannot afford here:


In PSYC , by contrast, the server will contact

a set of servers, which will forward the news to another set of servers
each, until all the recipients receive the news


A multicast routing layer has been in the plans for GNUnet since before
we first came asking, which was around 2009. Research has been made on
how to do this, but there is no implementation as yet.

In GNUnet, nodes would efficiently set up distribution trees to get all
data to everyone who needs it. If done properly it can handle Twitter-
and even television-like use cases with millions watching the same video
stream. The current status quo is that these distribution trees are
implemented within the cloud, thus you only get to enjoy their strengths
if you surrender your cookies to them and join the cloud hegemoths.

Re: Regarding fixing warning

[Christian Grothoff]

On 3/4/24 05:38, Gotam Gorabh wrote:

Hi Martin,

While executing *./src/setup/gnunet-setup*, It gives the following
warning.

(gnunet-setup:16450): Gtk-CRITICAL **: 14:52:11.677: gtk_widget_hide:
  assertion 'GTK_IS_WIDGET (widget)' failed


I guess this is due to this code
> . This 
GNUNET_setup_gns_hijack_checkbutton object is not present in
.glade file or somewhere else.

Wdyt? Should I remove it or fix it?


I've now removed it from gnunet-gtk in main.  Thanks for reporting!

-Christian

Re: GSoC 2024: gnunet-gtk gtk4 upgrade

[Christian Grothoff]

GNUnet applications are not expected to run well without 'make install'. 
Moreover, I'm not sure gnunet-gtk works at all if being install into a 
different prefix than the underlying GNUnet installation ...


On 2/28/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

[Christian Grothoff]

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/

 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: NSE service PoW

[Christian Grothoff]

Well, the NSE service *only* gives you an estimate of the size of the 
network that is somewhat expensive for a Sybil attacker to inflate. It 
is used by the DHT to "safely" tune certain internal parameters. I do 
not know if it would be useful for Sybil mitigations beyond the DHT.


Also, please do not CC help-gnunet on these questions, just the 
developer mailing list should be more than enough!


On 2/23/24 23:15, Andrei Ușurelu wrote:

Good evening, is it recommended to connect to the NSE service if I
want to mitigate a Sybil type attack?

Re: Plugin integration

[Christian Grothoff]

The DHT will find your plugin automatically if it is installed in the 
right directory and has a suitable file name following the naming 
conventions. Your plugin must expose the right symbols with the correct 
API, and then the DHT will basically 'ask' your plugin what block types 
it is responsible for, and for those then ask your plugin to evaluate 
queries and replies.


Depending on what your blocks look like, you may be able to re-use the 
logic from the FS block plugin, or write new logic, hard to say, depends 
on what you are storing ;-).


DHTU works a bit differently, in that here you need to explicitly 
configure the plugin (the underlay plugins are not automatically 
'discovered' and used). DHTU is really just there to allow a DHT node to 
communicate with *neighbours*, it doesn't make routing decisions. Thus I 
don't think it is suitable to 'guide' each message, but maybe you mean 
something else by 'guide'. DHTU is for *transmitting* messages.


On 2/12/24 12:42, Big Boy wrote:
Good day! How exactly does a plugin of a service link up to the main 
service? I looked in the C tutorial's subsection regarding DHT and the 
need to provide a block plugin in order to validate requests/replies and 
it's not quite clear to me how exactly does the service use it in its 
inner processes. On a sidenote, would it be an issue to use the same 
block validation logic in the FS block plugin?
Another question is about the DHTU, does it also work as a plugin and 
would it allow me to customize the underlay in order to guide each 
message in the network?


Thank you in advance!
Andrei Usurelu

Re: Info about PEERSTORE service

[Christian Grothoff]

On 2/7/24 13:32, Big Boy wrote:
Good day! My apologies for writing again about the PEERSTORE service, 
but I have some more questions. Firstly, the store operation will store 
the keys-value pair in the client's device, while the iterate operation 
will look for the record locally? 


Yes.

Secondly, if I provide a peer id to 
the store operation, will it act as signing a value i.e not letting a 
different peer to add more values/replace the value? 


Only the local peer can store data in the PEERSTORE, and other peers 
cannot see values the local peer stored into its PEERSTORE. Signatures 
are unnecessary.


Third question, is 
there a way to generate a peer identity by providing a hash key pair? 


I'm not sure what you mean by 'hash key pair', and there are different 
answers to this; but right now, each peer generates its peer identity at 
random, and there is no way to 'generate' it in any other way in the 
current implementation.

 > I
want my users to be able to connect from multiple devices with some 
credentials and access stored data. Thank you in advance!


Then PEERSTORE is the wrong solution, you need the DHT or FS or 
something else, but not PEERSTORE.


În joi, 1 feb. 2024 la 23:43, Christian Grothoff <mailto:groth...@gnunet.org>> a scris:


Hi BB,

Peerstore is just a local database for information a peer keeps about
other peers (by their PeerIds, and yes, that's what you get as the CORE
ID and via the connect callbacks), it is *not* a DHT. The DHT is a
separate subsystem.

As it is the local (trusted) code storing information locally, the
expiration time is whatever the local code wants it to be.

I *think* the current implementation _may_ have a value size limit
around 64k, but in principle that could be fixed if desired.

I hope this answers your questions!

Happy hacking!

Christian

On 2/1/24 21:29, Big Boy wrote:
 > Good day, I looked at the current documentation of GNUnet and I have
 > some questions regarding the PEERSTORE service:
 > - how is the PEERSTORE supposed to work? Is it like a DHT, where
some
 > info is kept on each peer? Is it a reference of the said information
 > kept locally on each peer? I looked at the bibliography available
and I
 > haven't yet seen a reference regarding how the peerstore service is
 > supposed to work.
 > - what is the maximum size of the stored data in a key? And is
there a
 > TTL similar to DHT for stored data?
 > - what PeerIdentity can I use in order to store data as signed? I
would
 > imagine that the CORE identity that's created during the connects()
 > method could work, but does it remain the same for each peer or
is it
 > changing constantly?
 >
 > Thank you in advance!

Re: GNUnet 0.20.0 released / test_resolver_api.nc failing

[Christian Grothoff]

'access' failed suggests that the binary may not be set to executable 
(at least not for the user running 'make check'). Also, did you actually 
run 'make install' before 'make check' and does the binary exist in the 
location given in the error message? This is exactly the place where I'd 
expect a failure if 'make install' had not been run yet and the service 
binary only existed in the src/lib/util/ folder and not yet in /usr...


My 2 cents

Christian

On 12/29/23 20:01, xrs wrote:

Dear all,

I'm trying to package version 0.20.0 for Alpine Linux.

53 of 55 tests are successful, one is skipped and another fails. The
test for test_resolver_api.nc is failing on my system saying something
like

   2023-12-29T19:07:29.608763+0100 util-os-installation-18555 WARNING
   `access' failed on file `/usr/gnunet/libexec/gnunet-service-resolver'
   at os_installation.c:793 with error: No such file or directory

The binary "gnunet-service-resolver" has been successfully built.
Do you have an idea how this could have happened?

See the attached build and test logs for further information.

Best,
xrs

On Mon, 25 Sep 2023 17:11:17 -
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






--
GPG-Key: https://keys.openpgp.org/vks/v1/by-keyid/3E1C76778215233B
GPG-Fpr: 06C2 0E71 4C71 D336 A233  A0B6 3E1C 7677 8215 233B

Re: based GNUnet decentralized IP address, Abolish ipv4 and ipv6

[Christian Grothoff]

Dear aiss,

GNUnet already uses public keys for addressing and routing in the 
CORE/DHT/CADET layers (and above), effectively replacing IP addresses 
that are created in a decentralized way. Only the transport layer which 
adapts the protocol to run over existing Internet connections we have IP 
addresses. However, it is possible to write communicators for the 
transport layer that do not use IP at all, for example by directly using 
Ethernet/WLAN and bypassing TCP/IP entirely.


Happy hacking!

Christian

On 12/11/23 16:04, aiss wrote:

THE IDEAL PATH
What if we replace the controlled and surveilled IP addresses with new 
internet addresses that are based on GNUnet? These addresses will 
inherit all GNUnet’s features, i.e., they will be purely decentralized, 
secure, future-proof, robust, anonymous, unhackable, controlled by no 
single authority and many more.


Is it just a dream? For now. If this could be true we would be changing 
the internet as we know it.


* GNUnet address + GNUnet DNS, access to GNUnet domain

win10 network adapters : Enter the GNUnet address
Wi-Fi DHCP Static : Enter the GNUnet address


---
IPv4 and IPv6 are centralized. They are controlled by national 
companies, etc.

![](https://www.apnic.net/wp-content/uploads/policy-environment_obsolete/images/ipv4_hierarchy.png)

Try to Google “Who controls IP addresses?” You’ll promptly get “IANA: 
the Internet Assigned Numbers Authority.” IANA is the top authority 
behind IP address allocation and assignment. There are five different 
regional internet registries (RIR) with jurisdiction under the IANA.


As a matter of fact, as an individual or a normal internet user you 
cannot request IP addresses directly from IANA or one of the five RIRs, 
but only from internet service providers, such as the services offered 
by mobile or telecom operators.



* True decentralization, no official singular Foundation, Committee, 
Corporation, or entities in permanent unitary control of the protocol.

Re: GNUnet Name System Questions

[Christian Grothoff]

I am also not sure about the question, but I would say this: you should 
probably consider using DANE [1] records to enable users to secure TLS 
connections to your GNS-resolved sites. GNUnet's GNS-enabled socks proxy 
validates TLS server certificates against DANE records in GNS, and 
gnunet-namestore-gtk can help you create DANE records.


[1] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

On 12/3/23 22:04, Schanzenbach, Martin wrote:
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

RFC 9498: The GNU Name System

[Christian Grothoff]

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


GNS addresses long-standing security and privacy issues in the 
ubiquitous Domain Name System (DNS). Previous attempts to secure DNS 
(DNSSEC) fail to address critical security issues 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 to be used by alternative 
name resolution systems and have established the GANA registry for ".alt".


GNS is implemented according to RFC 9598 in GNUnet 0.20.0. It is also 
implemented as part of GNUnet-Go.


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 and 
NGI DISCOVERY 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 R5N DHT and BFT Set Reconciliation which are 
underlying building blocks of GNS in GNUnet and not covered by RFC 9498.

Re: GNUnet 0.20.0 released

[Christian Grothoff]

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: Unindex bug

[Christian Grothoff]

Hi Wes,

-c must be followed by the *configuration* file, and usually passing 
"-c" is not necessary as there is a default.  Have you tried running

simply:

$ gnunet-unindex gnutest6

?

-Christian

On 6/12/23 03:55, WalB wrote:

Hi,

I published a file from a subdirectory but cannot unindex it. I ran 
unindex on it and on several other files but unindex doesn't work. I 
have followed the instructions in the manual. See output below. All I 
want to do is delete the filenames and keywords of published files no 
longer wanted. Please tell me the correct command as a clear example or 
fix the bug.


Cheers,

Wes


user:/usr/share/gnunet$ cd ~/

user:~$ ls

certifs.pem  Documents  gnuin   Music     Public  Templates

Desktop      Downloads  gnuout  Pictures  snap    Videos

user:~$ cd gnuout/

user:~/gnuout$ ls

gnutest6

user:~/gnuout$ sudo gnunet-arm -s

[sudo] password for wes7:

user:~/gnuout$ sudo gnunet-core

Mon Jun 12 11:04:33 2023: connection established         KW7V (timeout 
in  299 s)


Mon Jun 12 11:04:33 2023: connection established         Y924 (timeout 
in  299 s)


user:~/gnuout$ sudo gnunet-unindex -c gnutest6

Jun 12 11:07:22-813088 util-4531 WARNING Syntax error while 
deserializing in line 1


Jun 12 11:07:22-813181 gnunet-unindex-4531 ERROR Failed to parse 
configuration file `/home/wes7/gnuout/gnutest6'


Jun 12 11:07:22-813215 util-4531 WARNING Failed to load configuration 
from file '/home/wes7/gnuout/gnutest6'


Jun 12 11:07:22-813244 gnunet-unindex-4531 ERROR Unreadable or malformed 
configuration file `/home/wes7/gnuout/gnutest6', exit ...


user:~/gnuout$ sudo gnunet-unindex -c gnutest6 
--config=~/.gnunet/gnunet.conf


Jun 12 11:09:03-824146 gnunet-unindex-4573 ERROR Unreadable or malformed 
configuration file `/root/.gnunet/gnunet.conf', exit ...


user:~/gnuout$ sudo gnunet-unindex gnutest6 --config=~/.gnunet/gnunet.conf

Jun 12 11:11:30-367995 gnunet-unindex-4577 ERROR Unreadable or malformed 
configuration file `/root/.gnunet/gnunet.conf', exit ...


user:~/gnuout$ sudo gnunet-unindex --config=~/.gnunet/gnunet.conf gnutest6

Jun 12 11:13:30-529263 gnunet-unindex-4583 ERROR Unreadable or malformed 
configuration file `/root/.gnunet/gnunet.conf', exit ...


user:~/gnuout$ sudo gnunet-unindex -config=~/.gnunet/gnunet.conf gnutest6

Jun 12 11:13:53-065694 gnunet-unindex-4586 ERROR Unreadable or malformed 
configuration file `/home/wes7/gnuout/onfig=~/.gnunet/gnunet.conf', exit ...


user:~/gnuout$ gnunet-search gnutest6

^Cuser:~/gnuout$ sudo gnunet-search gnutest6

#1:

gnunet-download -o "gnutest6" 
gnunet://fs/chk/ZX8JQ7BYVFFANSNV1BENWPG5Z4YHAFSQJ6XREX444KTNJVAS8N5XNXNFA9JZMXTTBG38204B9STF7CNQBGDVGR16HGD5ME53EHYP0J8.SET3DZN8SGG2XQHKNZY6CW9H0MWWCVT2JWH6Q3A9X0GDPSN5FX4ZJ66YNC9Q1NCA3KRWAV1KZ8SNSWCDYSFZS7RR7F3EZESSNPK2X70.31


^Cuser:~/gnuout$

user:~/gnuout$ sudo gnunet-search donkey

#1:

gnunet-download -o "gnutest6" 
gnunet://fs/chk/ZX8JQ7BYVFFANSNV1BENWPG5Z4YHAFSQJ6XREX444KTNJVAS8N5XNXNFA9JZMXTTBG38204B9STF7CNQBGDVGR16HGD5ME53EHYP0J8.SET3DZN8SGG2XQHKNZY6CW9H0MWWCVT2JWH6Q3A9X0GDPSN5FX4ZJ66YNC9Q1NCA3KRWAV1KZ8SNSWCDYSFZS7RR7F3EZESSNPK2X70.31


^Cuser:~/gnuout$

Re: GNUnet TNG QUIC Communicator

[Christian Grothoff]

Dear Marshall,

Welcome to the team! While I expect t3ss to be the most suitable mentor, 
please do not hesitate to ping me (or the list) if you have any 
questions or issues!


Happy hacking!

Christian

On 5/10/23 17:17, Marshall Stone wrote:

Hi everyone, I wanted to introduce myself and the project I am working on with 
GSoC (Google Summer of Code). My name is Marshall and I am a university student 
from the United States.

This summer I am going to be working on the QUIC communicator as a new feature 
to the transport layer. I’m very enthusiastic to begin working on this and I 
hope to have it working by the beginning of August.

Thanks!

Re: GNUnet Project GSOC 2023 Contributor

[Christian Grothoff]

On 3/17/23 16:28, hyazin...@emailn.de wrote:

We do have a monthly meeting on the first Sunday of the month 20:00
(Berlin/Rome) through mumble on gnunet.org.
If you want you can join us next time.

Best
Martin


Sure about the time for future meetings?
To my knowledge its still 10 A.M.


Correct, and it should stay at 10am for April. It'll change back to 
20:00 Berlin/Rome for May.


-Christian

Re: gnunet

[Christian Grothoff]

Nope, we just moved repo. The correct Git clone step would be:

$ git clone --depth 1 https://git.gnunet.org/gnunet.git



On 3/8/23 03:51, dhotrum--- via Mailinglist for GNUnet developers wrote:

Hi,
I tried to install gnunet from: 
https://github.com/royneary/painless-gnunet/blob/master/tutorial_ubuntu18.04.md

But it stopped at git clone. Is all this gone? Is Gnunet no longer worked on?

Dave









.

Re: ECDSA attack

[Christian Grothoff]

Hi Bernd,

I don't quite see that the attack applies, as our nonces are 
high-entropy *and* never attacker-controlled.


So my (brief) reading of the paper doesn't suggest that this kills 
GNS-ECDSA.


My 2 cents

Christian

On 3/7/23 11:29, Bernd Fix wrote:

Hi,

reading a recent paper (https://eprint.iacr.org/2023/305) I wonder if 
this has any impact on GNUnet - especially GNS, which uses ECDSA 
signatures for PKEY-signed payloads. Do we need to phase out PKEYs and 
replace them with EDKEYs in the future?


Cheers, Bernd.

Re: gnunet mysql errors

[Christian Grothoff]

Git master (still) works on all of my systems, so patch LGTM. -Christian

On 2/1/23 10:59, Martin Schanzenbach wrote:

Please try with
https://git.gnunet.org/gnunet.git/commit/?id=ac40efdae723f850bfff62c0cddad130a37f425e
on whatever system this failed for you.

Br

Re: gnunet mysql errors

[Christian Grothoff]

Well, I touched it because it didn't build on my system(s), and with my 
fix it did. But of course, I didn't test all the various mysql versions...


Maybe we should introduce a configure-level check for 'my_bool' instead 
of relying on the MySQL version? Just reverting the code is sure to then 
simply cause a similar FTBFS on one of my systems.


On 2/1/23 01:19, Martin Schanzenbach wrote:


This is a regression introduced by Christian recently:
https://git.gnunet.org/gnunet.git/commit/?id=b73a7c5da48e09bd39c1d7c1dabec269dbacd1c8

I think the check before this commit was correct (and the comment
wrong).

Br
Martin

Nikita Ronja Gillmann  writes:


mysql is correctly detected (version: mysql-client-8.0.31nb1).

yet I run into this. any idea if this is on your side or mine?

gmake[3]: Entering directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql'
CC   mysql.lo
In file included from mysql.c:28:
mysql.c: In function 'iopen':
../../src/include/gnunet_mysql_compat.h:48:20: error: 'my_bool' undeclared 
(first use in this function); did you mean 'bool'?
 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this
|^~~
mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL'
224 |   MYSQL_BOOL reconnect;
|   ^~
../../src/include/gnunet_mysql_compat.h:48:20: note: each undeclared identifier 
is reported only once for each function it appears in
 48 | #define MYSQL_BOOL my_bool; //MySQL < 8 wants this
|^~~
mysql.c:224:3: note: in expansion of macro 'MYSQL_BOOL'
224 |   MYSQL_BOOL reconnect;
|   ^~
mysql.c:224:14: error: 'reconnect' undeclared (first use in this function); did 
you mean 'connect'?
224 |   MYSQL_BOOL reconnect;
|  ^
|  connect
gmake[3]: *** [Makefile:560: mysql.lo] Error 1
gmake[3]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src/mysql'
gmake[2]: *** [Makefile:548: all-recursive] Error 1
gmake[2]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2/src'
gmake[1]: *** [Makefile:599: all-recursive] Error 1
gmake[1]: Leaving directory '/usr/work/net/gnunet/work/gnunet-0.19.2'
gmake: *** [Makefile:510: all] Error 2
*** Error code 2

Stop.
make[1]: stopped in /usr/pkgsrc/net/gnunet
*** Error code 1

Re: [PATCH] Fix git detection when cloned as submodule

[Christian Grothoff]

Thanks, patch applied to Git. -Christian

On 1/9/23 21:00, Dan Church wrote:

Hi GNUNet devs!

I found an issue where VERSION and PACKAGE_VERSION would always be set 
to 'unknown' if gnunet was cloned as a git submodule.


Steps to repro:

mkdir superproject
cd superproject
git init
git submodule addhttps://git.gnunet.org/gnunet.git
cd gnunet
contrib/get_version.sh

At this point, 'unknown' will print if this is still an issue.

With the attached fix, '0.19.2-6-gbe0ba43d7' will print.

Re: Reminder: Official invitation to GNUnet e.V. GA needs to be sent out today, 20th November

[Christian Grothoff]

Martin did already send the invitation to the members.

-Christian

On 11/20/22 15:03, hyazin...@emailn.de wrote:

Dear all,


quick reminder for sending the official invitation to GNUnet e.V. GA in time:
GNUnet e.V. GA takes place on 4th December and needs to be officially announced
two weeks before with explanation that Satzung is changed (and what is changed).
That is right now, today, 20th November.


Cheers,
Bastian Schmidt

Re: shutdown task not triggered on gnunet-arm -e

[Christian Grothoff]

You should never add your own signal handler, GNUNET_PROGRAM_run() does 
that already, by adding your own you remove the GNUnet signal handler 
and thus break the shutdown logic.


-Christian

On 10/26/22 10:15, accounts-gnu...@holbrook.no wrote:

When running the service with gnunet-arm -i svc, the function added with
GNUNET_SCHEDULER_add_shutdown is not being run when issuing gnunet-arm -k
svc

If I add a sigterm handler and do GNUNET_SCHEDULER_shutdown there, it
hangs and I have to sigint (and it doesnt halt).

If I run the service directly (without gnunet-arm) the shutdown task
gets triggered.

Is this expected behavior?

Is there a recommended way to add teardown code when using gnunet-arm?

I'm on 1567c9472b917a097cace08a7b08fc724e14f381

thanks,
l

Re: git repo status change

[Christian Grothoff]

I've now updated the gnunet-ext build system, the example had not been 
reasonably maintained in 10 years and was quite outdated in various 
style points...


-Christian

On 10/24/22 03:05, Martin Schanzenbach wrote:

Yeah I assume that, like gnunet.git, you'd want a .gitignore in m4/
containing

libtool.m4
ltoptions.m4
ltsugar.m4
ltversion.m4
lt~obsolete.m4
wchar_t.m4


BR
Martin

On 22.10.22 16:59, accounts-gnu...@holbrook.no wrote:


When I make changes to the gnunet-ext repo .h and .c files and build, the .m4
files also get part of the git delta.

Is it supposed to be like this?

--

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
 modified:   m4/libtool.m4
 modified:   m4/ltoptions.m4
 modified:   m4/ltsugar.m4
 modified:   m4/ltversion.m4
 modified:   m4/lt~obsolete.m4
 modified:   src/ext/gnunet-ext.c
 modified:   src/ext/gnunet-service-ext.c
 modified:   src/ext/test_ext_api.c
 modified:   src/include/gnunet_ext_service.h
 modified:   src/include/gnunet_protocols_ext.h

Re: Website 'gnunet.org' producing weird output currently

[Christian Grothoff]

The problem was that we had a listen:80 rule for IPv4 but not for IPv6 
in the configuration for gnunet.org on firefly. Fixed now.


On 10/22/22 12:17, Martin Schanzenbach wrote:

I think christian changed the IP for gnunet.org. Maybe that is causing
problems right now?

On 21.10.22 14:54, hyazin...@emailn.de wrote:

Hello,

visiting 'gnunet.org' with TOR browser currently is prompting a warning because 
of an invalid certificate.
Clicking the 'accept and continue' button is leading to the GNUnet paper 
bibliography - a plain 'html'-website, instead of the usual 
'gnunet.org'-website. Excerpt:

"Selected Papers in Meshnetworking

The GNUnet Bibliography | Selected Papers in Meshnetworking

By topic | By date | By author
Topics:

 Architecture CADET Communication Computer Science - Cryptography and 
Security DHT DNS DNSSEC Decentralisation Future Internet GNU Name System GNUnet 
Identity and Access Management Internet Linux MORECOWBELL NAMECOIN Name 
resolution P2P PKI POSIX Panic Privacy preserving R5N ReclaimID Self-sovereign 
identity Social networking TLS Taler Technology and society Unsorted User 
Attributes X-vine abuse anomaly anonymity auctions blind signatures byzantine 
consensus byzantine fault tolerance censorship consensus cooperative cryogenic 
decentralization detection distributed hash table economics encoding encryption 
event-driven flow control home router incentives intrusion detection 
measurement memory erasure messaging multicast network architecture obsolete 
database payments peer-to-peer performance performance analysis physical access 
power privacy private information retrieval publish-subscribe
pubsub reputation resilience resource allocation routing secure multi-party 
computation secure multiparty computation self-organization set reconciliation 
social interaction static analysis testbed voting web

Publications by topic
Architecture

Zur Idee herrschaftsfreier kooperativer Internetdienste (PDF)
by Christian Ricardo Kühne.
In FIfF-Kommunikation, 2016. (BibTeX entry) (Download bibtex record)
(direct link) (website)"


Greetings,
Bastian Schmidt

Re: Website 'gnunet.org' producing weird output currently

[Christian Grothoff]

We just changed some DNS settings in the last 24h and had to renew 
certs. Nothing special ;-). -Christian


On 10/21/22 14:54, hyazin...@emailn.de wrote:

Hello,

visiting 'gnunet.org' with TOR browser currently is prompting a warning because 
of an invalid certificate.
Clicking the 'accept and continue' button is leading to the GNUnet paper 
bibliography - a plain 'html'-website, instead of the usual 
'gnunet.org'-website. Excerpt:

"Selected Papers in Meshnetworking

The GNUnet Bibliography | Selected Papers in Meshnetworking

By topic | By date | By author
Topics:

 Architecture CADET Communication Computer Science - Cryptography and 
Security DHT DNS DNSSEC Decentralisation Future Internet GNU Name System GNUnet 
Identity and Access Management Internet Linux MORECOWBELL NAMECOIN Name 
resolution P2P PKI POSIX Panic Privacy preserving R5N ReclaimID Self-sovereign 
identity Social networking TLS Taler Technology and society Unsorted User 
Attributes X-vine abuse anomaly anonymity auctions blind signatures byzantine 
consensus byzantine fault tolerance censorship consensus cooperative cryogenic 
decentralization detection distributed hash table economics encoding encryption 
event-driven flow control home router incentives intrusion detection 
measurement memory erasure messaging multicast network architecture obsolete 
database payments peer-to-peer performance performance analysis physical access 
power privacy private information retrieval publish-subscribe
pubsub reputation resilience resource allocation routing secure multi-party 
computation secure multiparty computation self-organization set reconciliation 
social interaction static analysis testbed voting web

Publications by topic
Architecture

Zur Idee herrschaftsfreier kooperativer Internetdienste (PDF)
by Christian Ricardo Kühne.
In FIfF-Kommunikation, 2016. (BibTeX entry) (Download bibtex record)
(direct link) (website)"


Greetings,
Bastian Schmidt

Re: FS as user or not

[Christian Grothoff]

Hmm. Is your $USER in the 'gnunet' group?

On 10/6/22 08:54, madmurphy wrote:
> After one of the last commits, if I launch
> 
> gnunet-search commons
> 
> I get only one file that I am sharing, while if I launch
> 
> sudo -u gnunet gnunet-search commons
> 
> I get more than 40 results.
> 
> For a second I thought that this commit from Jacki
> 
> was the reason, but it happens also if I restore the configuration
> before Jacki's commit. So I have no idea what happened.
> 
> Anyone getting the same behavior?
> 
> --madmurphy
> 

Re: GNUnet Monthly Meeting Sunday, 2nd October, 8 PM Paris/Berlin/Rome

[Christian Grothoff]

Dear all,

Small correction, we'll do this one at 10am (and also for the rest of 
the year) as we need to accommodate someone in JST ;-).


Cheers!

Christian

On 9/27/22 18:11, hyazin...@emailn.de wrote:

Dear all,


quick reminder for our monthly meeting on

Sunday, 2nd October, 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

Open PhD position at FU Berlin

[Christian Grothoff]

Dear all,

I'm happy to announce that there is an open PhD position for someone to 
work on a GNU Taler wallet for embedded systems.  Key points:


* Your PhD advisor would be Prof. Matthias Wählisch [MW], co-founder of
  RiotOS [Riot]. I'm officially a co-advisor on the project.
  The working language of the group is English.
* The position is in Berlin, you will be expected to relocate there;
  the initial contract will be for 3 years, however, a typical PhD
  in Germany is expected to take 5 years (so plan for ~5 years).
  The earliest possible start-date would be November 1st 2022.
* You need to have a Master's degree in computer science or a related
  field (mathematics, embedded systems). Our ideal candidate would have
  a background in embedded / micro-controller programming, and
  networking (TCP/IP).
* Your salary will be 100% TVL-13 [TVL-13]; the exact amount depends on
  years of experience and family status (and includes contributions to
  health insurance and retirement [Salary]). See [Summary] for a
  "simple" calculation by experience.
* You will write Free Software only, and help the GNU Taler project.

The main project goal is to create a Taler wallet that can run on an 
"embedded" system (so not a smart phone or a browser) by eliminating the 
current wallet's dependency on NodeJS/JavaScript and allowing it to run 
on platforms like RiotOS [Riot]. This should then (1) improve the 
security of the wallet (by reducing complexity), (2) allow citizens to 
use Taler without a smartphone (by buying some ideally much cheaper 
hardware), and (3) possibly set the stage to enable Taler to be used 
offline [Offline].


If you are interested in the position, please contact us off-list 
(ideally with a CV).



Happy hacking!

Christian
--
https://grothoff.org/christian/


[MW] https://www.mi.fu-berlin.de/en/inf/groups/ilab/members/waehlisch.html
[Riot] https://www.riot-os.org/
[TVL-13] https://oeffentlicher-dienst.info/tv-l/allg/
[Salary] 
https://oeffentlicher-dienst.info/c/t/rechner/tv-l/allg?id=tv-l=E_13=1=VBL=100==4===15.5%25

[Summary] https://www.jobs-beim-staat.de/tarif/tv-l_e13
[Offline] https://docs.taler.net/design-documents/030-offline-payments.html

Re: AEADs

[Christian Grothoff]

On 9/21/22 11:56, Jeff Burdges wrote:
> 
> I've a friend using ERIS https://inqlab.net/projects/eris/ which is
> based on https://grothoff.org/christian/ecrs.pdf and someone audited.
> 
> It does some signature check instead of using an AEAD, which maybe fine,
> and maybe better for encryption-at-rest, about which they seemingly
> care, but maybe also leaks something via side channels if done wrong,
> like maybe if decryption occurs first.

Eh, I don't quite find much about signatures in the ERIS spec using a
casual read. As far as ECRS is concerned, the only signatures it uses
would be the ones from the (optional) use of signatures with namespaces,
which is _exactly_ the same cryptography we use in GNS and in fact the
plan for about the last decade has been to eventually transition to
using GNS records instead of the same cryptographic ideas but without
interoperability for no good reason (other than history...).

For the data, ECRS only uses hashing and symmetric cryptography, so the
only place where we have (GNS-like) signatures is when users 'sign' that
they (pseudonymsly) published files in their namespace.

> Can anyone give me some background on what this stuff is really for? 
> Why the encryption-at-rest appears?

The encryption-at-rest is mostly for caching (including partial caching)
of data by nodes that don't have the decryption key. Historically, it
was also intended to avoid having to re-encrypt, but these days that
itself would be a silly reason given the speed of symmetric encryption.

> And:  Why does it not use an AEAD like chacha20-poly1305?

For ECRS: because it predates Salsa20 by about 5 years. Also, AES seems
to work just fine for this, and AFAIK still has more widely available HW
support. But beyond legacy and maybe a bit performance, I don't see a
technical reason. Oh, and ECRS doesn't need an AEAD as the convergent
encryption inherently provides for the integrity check. So with
convergent encryption, an authentication tag would just bloat the
transmission size. In non-convergent mode, that'd be another story.

> I know less than I should about encryption-at-rest, just that it's
> historically fucked up as much as other things, but less studied than 
> networking.
> 
> Jeff
> 
> 

Re: Hello from the libp2p project

[Christian Grothoff]

Hi Max,

Thanks also from me for reaching out.  I'm glad you found our LSDs 
useful, that validates our work there. After all, P2P projects like 
yours are exactly the intended audience!


I also won't be able to make it to Lisbon. But do join our monthly Mumble!

Happy hacking!

Christian

On 9/16/22 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: gnunet-rest-server shutdown issues

[Christian Grothoff]

On 9/16/22 12:52, Nikita Ronja Gillmann wrote:

Hi,

so the issue still exists, but I didn't have the time to send more information,
busy last months.
I'll try to get back to you soon.

As an aside: I haven't followed gnunet development that much recently,
but as I have started to add invocations for a couple of BSDs to
gnunet-dns-helper (a long time ago and ran out of time as well), I was
wondering if those firewall parts would eventually become obsolete in
the rewrites you are doing right now, long-term?


I don't think so. Naturally, the DNS-helper might not be the most common 
way to use GNS in the future, but I don't see that we'd fundamentally 
get rid of it. And as of today, I also don't know a better way to do 
this. The major ongoing changes to GNUnet are all lower in the stack.

Re: mantis sets no real domain to filter emails from

[Christian Grothoff]

Fixed now. I suspect this happened when Martin last updated Mantis. 
Thanks for letting us know! -Christian


On 9/13/22 21:10, Nikita Ronja Gillmann wrote:

Mantis used to set nore...@gnunet.org, now it sets the example.com address for 
everything.
This makes it rather hard to filter when you are still on some bug tickets.

Can you please fix that to conform to point to gnunet.org?

Thanks.

Re: Doxygen Cleanup: NAT nomenclature

[Christian Grothoff]

On 9/13/22 00:02, Willow Liquorice wrote:

Hello,

I've completed a first pass through the Doxygen comments and cleaned up 
a lot of it. Those tasks aren't done (yet, I'll bring it up on Mantis), 
but I've resumed organising the Doxygen groups. I'm a little confused 
about the group with the internal name "nat", long name "NAT testing 
library" or "NAT library".


The headers that define it are "gnunet_nat_service.h" and 
"gnunet_nat_auto_service.h", which seems to contradict the two group 
names. Is NAT a service or a library?


We have both, a NAT service, and a NAT library. With the ongoing 
transport (TNG) rewrite, we may want to eventually revise some of this.


I'm not sure which of the two long names is more fitting, as the call 
graphs and description don't imply that it is simply for testing. Which 
long name is more appropriate?


Right, the 'auto' part is also for 'automatic' configuration, so the 
'testing' part is about testing (in the sense of probing!) the 
host/network, not about software testing.  I suggest we can just use 
"NAT", or maybe better: "NAT Traversal", as that's what it is ultimately 
really about.


My 2 cents

Christian

Re: About GNUrl and cURL

[Christian Grothoff]

On 9/6/22 14:43, madmurphy wrote:

Just out of curiosity, why do I get

gstreamer:  no


You need also certain related gstreamer libraries 
(gstreamer-plugins-base or something like that) before gstreamer is 
considered "complete enough" to work for GNUnet.


-Christian

Re: About GNUrl and cURL

[Christian Grothoff]

Did you happen to have both libcurl-gnutls and libcurl-openssl
installed, and maybe configure found the wrong one?

On 9/5/22 18:56, madmurphy wrote:
> Mmm I just checked better, and the |configure| script now says:
> 
> ...
> HTTP Client:curl-openssl
> ...
> 
> That is not a good sign, right?
> 
> 
> On Mon, Sep 5, 2022 at 5:47 PM madmurphy  <mailto:madmurphy...@gmail.com>> wrote:
> 
> Indeed, there is a dedicated package on Arch, |libcurl-gnutls|
> <https://archlinux.org/packages/core/x86_64/libcurl-gnutls/>. I just
> checked, and it seems that GNUnet works fine with it. Package
> updated
> 
> <https://aur.archlinux.org/cgit/aur.git/commit/?h=gnunet=3693252e6dcdf53bfa428b4c078729c08f68ecde>.
> 
> --madmurphy
> 
> 
> On Mon, Sep 5, 2022 at 4:25 PM Christian Grothoff
> mailto:groth...@gnunet.org>> wrote:
> 
> If Arch has a curl linked against GnuTLS, then yes. -Christian
> 
> On 9/5/22 17:11, madmurphy wrote:
> > On Arch GNUnet still depends on GNUrl, but as far as I
> understood now
> > cURL is preferred. Would I do the right thing if updated the Arch
> > package accordingly and dropped the GNUrl dependency for good?
> >
> > --madmurphy
> 

Re: About GNUrl and cURL

[Christian Grothoff]

If Arch has a curl linked against GnuTLS, then yes. -Christian

On 9/5/22 17:11, madmurphy wrote:
> On Arch GNUnet still depends on GNUrl, but as far as I understood now
> cURL is preferred. Would I do the right thing if updated the Arch
> package accordingly and dropped the GNUrl dependency for good?
> 
> --madmurphy

Re: SSH Trouble

[Christian Grothoff]

gnunet.org != git.gnunet.org, please try:

$ ssh -T g...@git.gnunet.org

-Christian

On 8/11/22 20:25, Willow Liquorice wrote:

Hello,

I'm getting my local repositories set up to push changes, but I received 
a "Permission denied (publickey)" error when I tested the ssh connection 
with "ssh -T g...@gnunet.org", after adding my private key to my ssh 
keyring.


Have I misconfigured something, or is my public key not in the right place?

Regards,
 Willow

Re: New SSH key

[Christian Grothoff]

Done. In general, please send these types of requests directly to me or 
Martin, no need to bother the list.


-Christian

On 7/23/22 16:27, Maxime Devos wrote:

Hi,

I'll be using a new SSH key: 'ssh-ed25519 
C3NzaC1lZDI1NTE5IPJa2FK5j9V6zkxVcvyvBQnt8dbXIXEABwO3rQZIhQ08'; 
the list of SSH keys for gnunet-scheme.git needs to be updated.


Also, there is no description on https://git.gnunet.org, for 
gnunet-scheme maybe:


GNUnet client implementation in (Guile) Scheme

Greetings,
Maxime

Re: First commit

[Christian Grothoff]

No problem, I've deleted the "bad" branch. -Christian

On 7/19/22 20:23, Tobias Platen wrote:
> Pushed my first signed commit, unfortunately I picked the wrong branch
> https://git.gnunet.org/gnunet.git/log/?h=multicast_messenger
> 
> The correct one should be
> https://git.gnunet.org/gnunet.git/log/?h=dev/tplaten/multicast_messenger
> 
> 
> 

Re: Small question about gnunet-search

[Christian Grothoff]

On 6/27/22 08:13, madmurphy wrote:

That said, I strongly suspect the *timeout* option the man page
refers to may have been removed a long time ago. Or maybe there is
one hiding in libgnunetfs that I'm not thinking of. ;-)

Yes, I meant reacting specifically to that “timeout” option (I don't 
even know how what key in the configuration file would map it, 
eventually)… But the idea is not bad! Although in that case it would 
also be needed to allow a |--timeout=infinity| option, for when a finite 
timeout is set in the configuration file…


That exists, it's just --timeout=forever

Re: Small question about gnunet-search

[Christian Grothoff]

On 6/26/22 17:28, madmurphy wrote:

Hi everyone,

I have a question about something I had noticed some months ago while 
reviewing the man page for |gnunet-search|. After typing |man 
gnunet-search| and scrolling down, the following text appears:


FILES
|~/.config/gnunet.conf| GNUnet configuration file; specifies the
default value for the timeout

However there is nothing in the source code of |src/fs/gnunet-search.c| 
 
that reacts to the configuration.




GNUNET_PROGRAM_run() reacts to the configuration, as does the rest of 
libgnunetutil and thus also libgnunetfs when it interacts with GNUnet 
services.


That said, I strongly suspect the *timeout* option the man page refers 
to may have been removed a long time ago. Or maybe there is one hiding 
in libgnunetfs that I'm not thinking of. ;-)


-Christian

(re-)planned downtime

[Christian Grothoff]

Dear all,

After the last attempt had to be aborted because the network was not 
ready, we'll now be moving the Git serves on Wednesday, June 21st (2022) 
from Bern (CH) to Biel (CH).


Even if everything works as planned, there will be some significant 
downtime of the Git and other co-located services affecting GNU 
Anastasis, GNUnet, GNU libmicrohttpd, GNU libextractor and GNU Taler 
development (Git), demonstrators, CI/CD, bugtracking, etc.



Happy hacking!

Christian

3 Milestones for "R5N (2021-02-038)"/C implementation reached

[Christian Grothoff]

Dear GNUnet community,

I'm happy to announce that as of the very recent
14da59e43311204cadc883cd3688be08bd77b6a8

it is also believed that the C code correctly implements the updated 
LSD0004 specification, for the first three milestones. In addition to 
fixing stylistic issues in the protocol (like message layouts) that 
arose from trying to write a clean specification, there were also 
various minor and major bugfixes where the routing implementation did 
not quite do what it should have, or simply could do better as we 
discovered when trying to write down what the C code was actually doing.


Furthermore, a new DHT underlay mechanism was added. Now the DHT 
implementation can use both GNUnet-core and/or a new simplistic UDP 
protocol as 'underlays'. The UDP protocol should be great for DHT 
interoperability testing (no encryption, no complicated GNUnet 
core+transport protocols to support first). Moreover, the DHT underlay 
mechanism is *general* and allows for additional underlay plugins to be 
defined. This will make it easy to run R5N over other P2P networks (like 
I2P) in the future. Because a single DHT process can use multiple 
underlays concurrently, this even allows the creation of one big R5N DHT 
that spans multiple P2P networks, as long as there are (some) peers that 
run DHT instances and have configured underlays in both P2P networks.


Last but not least, the latest implementation adds signatures to the 
paths (if path tracking is enabled), such that if an application enables 
DHT path tracking, it can actually be assured that the message did 
traverse the peers on the path and hence that path through the topology 
did exist. This prevents certain types of attacks on the CADET layer.


The next (milestone 4) task for the C agenda is interoperability testing 
with other implementation(s), which we will do jointly as these other 
implementations progress.



Happy hacking!

Christian

On 6/11/22 20:29, Bernd Fix wrote:

Dear GNUnet community,

I am happy to announce the completion of the first milestone of the "Go 
implementation of the R5N DHT" for the NLnet-funded project "R5N 
(2021-02-038)". The implementation is not based on the current GNUnet 
DHT/Transport protocol, but on a new protocol defined in 
https://lsd.gnunet.org/lsd0004. The new specification corrects some 
design decisions in the old protocol and improves security in many 
places (e.g. signed DHT-PATHes and HELLOs).


The source code is written for Go1.18+ (it makes use of generics in some 
places); it can be found in the GNUnet Git-Repository at 
"https://git.gnunet.org/gnunet-go.git/; with tag "v0.1.27" in the master 
branch. The code for Milestone 1 covers the following areas (the main 
source references are given in square brackets as a starting point):


# Defining and implementing base data structures:

## Routing table:

### K-Buckets:
   The code provides a Kademlia-like bucket implementation.
   [gnunet/dht/routingtable.go]

### network addresses:
   A generic, GNUnet-compatible address implementation based on URIs
   with many helpers (like thread-safe maps). [gnunet/util/address.go]

### distance metric:
   PeerAddress type [gnunet/dht/routingtable.go]

## Infrastructure messages

### add/update peers:
   A complete event signalling framework for transport layer events has
   been implemented. Listeners can define filters for events they are
   interested in. [gnunet/core/event.go]

# Defining and implementing base processes:

## Bootstrapping a node:
   Connect to the first node via HELLO URL or plain network address. The
   code implements HELLO messages, blocks and URLs as defined in the
   LSD0004 spec to send and receive HELLO messages (including signing
   and verification).
   [gnunet/core/core.go, gnunet/service/dht/blocks/hello.go]

## Message transport:
   The transport layer has been completely re-written from the previous
   version. It supports the "ip+udp" protocol and has a three tier layout
   (Endpoint/Transport/Core) to separate functionality. Currently only
   PacketEndpoints (UDP) are implemented.  [gnunet/transport/*.go]

## Persistence:
   A key/value store API [gnunet/service/store.go] for DHT blocks and
   stringed key/value pairs. DHT block storage is disk-based, whereas
   for string key/value pairs multiple implementations are avaiable
   (Redis,SQL). Eviction is based on expiry (mandatory) and the
   "lifeSpan * size / usedCount" ratio for optional removals.

## Block verification API:
   Verify methods incorporated into DHT query instances and DHT blocks
   [gnunet/service/dht/blocks/generic.go]

## Routing table lookup:
   The lookup methods as described in LSD0004 are implemented.
   [gnunet/service/dht/routingtable.go]


Please bear in mind that the code for this milestone compiles and run 
the unit tests, but it is not complete to run as a fully functional 
application. This is just the starting point for the next milestones; I 
hope to complete the next milestone in a rather 

Re: Doxygen Tidy-up

[Christian Grothoff]

On 6/10/22 3:42 PM, Willow Liquorice wrote:
> Oh, I didn't know we already had a standard. I'll remember that and put
> it in the updated Style Guide.

:-)

> It's a good thing the team has a self-appointed documentation busybody
> now, hm?

A very good thing. ;-)

> Provided that the more recent docs are the ones in the headers,
> I'll have the source docs deduplicated by the end of next week.

That's largely a safe assumption, just make sure to NEVER remove
comments from 'static' functions. If the function has a very long
detailed comment, you may need to check that the header does indeed have
that comment and is not only an abbreviated version, but 95% of the time
they will be identical.

> Anyway, these are the modules that I'm unsure about how to categorise:
> * "Load library"
> * "CURL integration library"
> * "NAT testing library"
> * "MySQL library"
> * "Friends library"
> * "Credential service"
> * "Resolver service"
> * "Network type categorisation"
> * "SOCKS proxy"
> 
> What do they do, and do any of these pertain to specific GNUnet subsystems?

MySQL (together with Postgres and Sqlite) are general helper functions
to talk to the respective database; they are often used with multiple
subsystems.

Load -- I think that's largely historic code to detect the current load
on the local system to allow FS (and theoretically other subsystems) to
adapt their behavior to system load.

CURL: generic http client logic

Resolver: generic DNS client logic

NAT testing/network type catgorization: helper subsystems for transport

Friends: parsing for 'topology' (gossip overlay / bootstrapping)

SOCKS: proxy logic for GNU Name System

Credential: GNS/Re:claimID.


> On 10/06/2022 07:04, Christian Grothoff wrote:
>> On 6/9/22 23:52, Willow Liquorice wrote:
>>> I've categorised the code as much as I can, though I'm not too sure
>>> about the function of some modules and I've only categorised within
>>> src/include, so there's still a bit that's unsorted. It's mostly
>>> services that are undocumented elsewhere, and libraries of uncertain
>>> function that I couldn't establish as part of libgnunetutil.
>>>
>>> I've also knocked a rudimentary script together, to process the literal
>>> torrent of warnings Doxygen emits when I build the source docs. I've
>>> used regexes to categorise them, and here are the results:
>>>  * 5655 occurrences of parameters with multiple docs across 175
>>> source files.
>>>  * 3372 documented parameters which do not exist in their
>>> corresponding function definitions, across 276 source files.
>>>  * 1660 functions with undocumented parameters, across 282 source
>>> files.
>>>  * 760 explicit links to other parts of the documentation cannot be
>>> resolved.
>>>  * 2-300 errors across a laundry list of other categories.
>>>
>>> This is a rather sorry state of affairs.
>>>
>>> Those redundant parameters reflect a common phenomenon in the
>>> repository, where a function is documented in multiple locations. I'm
>>> not sure about the reasons for doing this, but in my opinion it
>>> unnecessarily increases the maintenance load as documentation has to be
>>> updated in multiple locations.
>>
>> Right, which is why for a few years we've been eliminating the
>> duplicates, always only keeping the version in the header if a function
>> is non-static. Alas, as you said above, there is a very large number of
>> these, and so progress is slow but steady.
>>
>>> I think a code style decision needs to be made, about where to locate
>>> docs, and the redundant documentation removed.
>>
>> Headers, otherwise (static prototypes) on first occurrence.
>>
>>> I've also found, in my experiments with the new Sphinx docs, that the
>>> redundantly-documented parameters are counted twice by Breathe, which
>>> could motivate stripping the redundant docs if we decide to go ahead
>>> with integrating source code docs.
>>>
>>> What do people think?
>>
>> We've been doing this, but basically only whenever we edit a source file
>> already, due to, eh, "capacity" issues ;-).
>>
>> Cheers!
>>
>> Christian
>>
>>> On 06/06/2022 09:27, Martin Schanzenbach wrote:
>>>> Hi,
>>>>
>>>> that sounds like a good approach to me :)
>>>>
>>>> Thanks
>>>> Martin
>>>>
>>>> On Sun, 2022-06-05 at 23:59 +0100,

Re: Doxygen Tidy-up

[Christian Grothoff]

On 6/9/22 23:52, Willow Liquorice wrote:
> I've categorised the code as much as I can, though I'm not too sure
> about the function of some modules and I've only categorised within
> src/include, so there's still a bit that's unsorted. It's mostly
> services that are undocumented elsewhere, and libraries of uncertain
> function that I couldn't establish as part of libgnunetutil.
> 
> I've also knocked a rudimentary script together, to process the literal
> torrent of warnings Doxygen emits when I build the source docs. I've
> used regexes to categorise them, and here are the results:
> * 5655 occurrences of parameters with multiple docs across 175
> source files.
> * 3372 documented parameters which do not exist in their
> corresponding function definitions, across 276 source files.
> * 1660 functions with undocumented parameters, across 282 source files.
> * 760 explicit links to other parts of the documentation cannot be
> resolved.
> * 2-300 errors across a laundry list of other categories.
> 
> This is a rather sorry state of affairs.
> 
> Those redundant parameters reflect a common phenomenon in the
> repository, where a function is documented in multiple locations. I'm
> not sure about the reasons for doing this, but in my opinion it
> unnecessarily increases the maintenance load as documentation has to be
> updated in multiple locations.

Right, which is why for a few years we've been eliminating the
duplicates, always only keeping the version in the header if a function
is non-static. Alas, as you said above, there is a very large number of
these, and so progress is slow but steady.

> I think a code style decision needs to be made, about where to locate
> docs, and the redundant documentation removed.

Headers, otherwise (static prototypes) on first occurrence.

> I've also found, in my experiments with the new Sphinx docs, that the
> redundantly-documented parameters are counted twice by Breathe, which
> could motivate stripping the redundant docs if we decide to go ahead
> with integrating source code docs.
> 
> What do people think?

We've been doing this, but basically only whenever we edit a source file
already, due to, eh, "capacity" issues ;-).

Cheers!

Christian

> On 06/06/2022 09:27, Martin Schanzenbach wrote:
>> Hi,
>>
>> that sounds like a good approach to me :)
>>
>> Thanks
>> Martin
>>
>> On Sun, 2022-06-05 at 23:59 +0100, Willow Liquorice wrote:
>>> Hello everyone,
>>>
>>> I was going to mention this at the Dev Meeting today, but Mumble
>>> wasn't
>>> playing very nicely with my OS' audio system.
>>>
>>> Another thing I've decided to work on is making the Doxygen site more
>>> user-friendly, as I found out that it's possible to nest groups.
>>>
>>> I've used this capability to make the Modules page easier to navigate
>>> by
>>> adding an layer or two of domain-specific grouping on top of the
>>> current
>>> modules (putting all the libgnunetutil headers into their own group,
>>> the
>>> network backbone going into one group, etc. etc.).
>>>
>>> Does this sound like a good idea, and what would your recommendations
>>> be
>>> for how to organise the modules if so?
>>>
>>> Best wishes,
>>>  Willow
>>>
>>>
>>
>>
> 

Re: Packaging problems

[Christian Grothoff]

On 6/3/22 22:37, Willow Liquorice wrote:
> Alright, fair point.
> 
> Still, more automated testing/packaging isn't a bad thing. What exactly
> does the CI do, right now? I looked in .buildbot in the main repo, and I
> guess it just tries to build and install GNUnet from source on whatever
> OS hosts Buildbot? Couldn't see that much automated testing/packaging.
> 
> I'll say again that not having GNUnet running on Debian's CI is a big
> missed opportunity. Being able to deploy and test on Debian Unstable
> automatically would surely make it easier to keep the Debian package up
> to date.

Absolutely. Having the CI do more would be great.

> I'm not sure about the exact process, but I get the impression from
> reading about the subject that it could just be a matter of creating a
> new version, which could trigger building Debian packages, which then go
> to Debian Unstable, and are then used with autopkgtest on ci.debian.net.

Who can do this? Anyone, or only a DD? Our DD has been somewhat, eh,
distracted recently...

Cheers!

Christian

> Best wishes,
> Willow
> 
> On 03/06/2022 20: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.
>>
>> 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.
>>
>> 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.
>>>
>>>
>>
> 

Re: Packaging problems

[Christian Grothoff]

On 6/4/22 09:43, Schanzenbach, Martin wrote:
> 
> 
>> 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.

Oh, I'm talking about having many TGZ, not about generating multiple
binary packages from one master source. We do that already for the
GNUnet Debian packages for which we have rules in-tree.

Re: Packaging problems

[Christian Grothoff]

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.


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.


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.

Re: GNUnet e.V. – Taler Systems SA Agreement is a TeX file

[Christian Grothoff]

That's an agreement between GNUnet e.V. and Taler Systems SA, which you 
do not need to sign but should be aware of (and which primarily has 
implications if any of your code ends up in GNU Taler).


The one contributors should sign is here:

https://www.gnunet.org/static/pdf/copyright.pdf

Happy hacking!

Christian

On 5/31/22 20:00, Willow Liquorice wrote:

Hello,

I was looking at the copyright assignment page on the website, and I 
noticed that the version of the GNUnet e.V. — Taler Systems SA agreement 
is a TeX file, which doesn't strike me as something meant to be read by 
visitors. Is that meant to be the case?


Best wishes,
 Willow

Re: Attacking the documentation monster

[Christian Grothoff]

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 questions and look forward to you 
improving the documentation!


Happy hacking!

Christian

On 5/20/22 02:21, Willow Liquorice wrote:
I've got some free time on my hands now, and I gave some thought 
to improving the readability of the HTML documentation on the 
website (which is what the average prospective GNUnet dev is 
going to look at). Read the Docs and friends set the standard in 
this regard. Having the contents in a sidebar for easy access 
(regardless of your location) would be far more convenient than 
what's currently available.


I understand that TeXinfo's HTML generation is a bit simplistic 
in the name of compatibility, which, while not a bad thing, 
results in a subpar reading experience for the average dev who 
will, in all likelihood, be reading the docs on a very capable 
modern browser.


While thinking about how to improve things with TeXinfo, it 
occurred to me that, instead of trying to emulate the experience 
of using Read the Docs, one could just use Read the Docs! It's 
Free Software, after all. I haven't looked into it too deeply, 
but if the .texi sources are converted to the reStructuredText 
that it accepts, a migration (or use of a similar platform) might 
be worth considering. What do the people here think?


If I'm going to dedicate time to restructuring GNUnet's docs, I 
need to know where it all is. I've found four strands of docs in 
the repository (Handbook, Tutorial, Doxygen, and man pages), 
could someone give me a run-down of the state they're in, how 
they relate to one another, and what they're supposed to be for? 
Is that everything?


Thanks,
 Willow

On 01/03/2022 22:52, Christian Grothoff wrote:
Spam killed this. We already constantly have

Re: Attacking the documentation monster

[Christian Grothoff]

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 questions and look forward to you improving 
the documentation!


Happy hacking!

Christian

On 5/20/22 02:21, Willow Liquorice wrote:
I've got some free time on my hands now, and I gave some thought to 
improving the readability of the HTML documentation on the website 
(which is what the average prospective GNUnet dev is going to look 
at). Read the Docs and friends set the standard in this regard. 
Having the contents in a sidebar for easy access (regardless of 
your location) would be far more convenient than what's currently 
available.


I understand that TeXinfo's HTML generation is a bit simplistic in 
the name of compatibility, which, while not a bad thing, results in 
a subpar reading experience for the average dev who will, in all 
likelihood, be reading the docs on a very capable modern browser.


While thinking about how to improve things with TeXinfo, it 
occurred to me that, instead of trying to emulate the experience of 
using Read the Docs, one could just use Read the Docs! It's Free 
Software, after all. I haven't looked into it too deeply, but if 
the .texi sources are converted to the reStructuredText that it 
accepts, a migration (or use of a similar platform) might be worth 
considering. What do the people here think?


If I'm going to dedicate time to restructuring GNUnet's docs, I 
need to know where it all is. I've found four strands of docs in 
the repository (Handbook, Tutorial, Doxygen, and man pages), could 
someone give me a run-down of the state they're in, how they relate 
to one another, and what they're supposed to be for? Is that 
everything?


Thanks,
 Willow

On 01/03/2022 22:52, Christian Grothoff wrote:

Spam killed this. We already constantly have to delete 'bug reports'
from the Web that were submitted as link spam. A wiki will drain
resources to keep the spammers out, and at the same time 
experience says

the contributions will be low quality (it has been tried).

If someone really is capable and invests time into contributing to
documentation, they can pick up Git and send

Re: Attacking the documentation monster

[Christian Grothoff]

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 questions and look forward to you improving 
the documentation!


Happy hacking!

Christian

On 5/20/22 02:21, Willow Liquorice wrote:
I've got some free time on my hands now, and I gave some thought to 
improving the readability of the HTML documentation on the website 
(which is what the average prospective GNUnet dev is going to look 
at). Read the Docs and friends set the standard in this regard. 
Having the contents in a sidebar for easy access (regardless of your 
location) would be far more convenient than what's currently available.


I understand that TeXinfo's HTML generation is a bit simplistic in 
the name of compatibility, which, while not a bad thing, results in a 
subpar reading experience for the average dev who will, in all 
likelihood, be reading the docs on a very capable modern browser.


While thinking about how to improve things with TeXinfo, it occurred 
to me that, instead of trying to emulate the experience of using Read 
the Docs, one could just use Read the Docs! It's Free Software, after 
all. I haven't looked into it too deeply, but if the .texi sources 
are converted to the reStructuredText that it accepts, a migration 
(or use of a similar platform) might be worth considering. What do 
the people here think?


If I'm going to dedicate time to restructuring GNUnet's docs, I need 
to know where it all is. I've found four strands of docs in the 
repository (Handbook, Tutorial, Doxygen, and man pages), could 
someone give me a run-down of the state they're in, how they relate 
to one another, and what they're supposed to be for? Is that everything?


Thanks,
 Willow

On 01/03/2022 22:52, Christian Grothoff wrote:

Spam killed this. We already constantly have to delete 'bug reports'
from the Web that were submitted as link spam. A wiki will drain
resources to keep the spammers out, and at the same time experience 
says

the contributions will be low quality (it has been tried).

If someone really is capable and invests time into contributing to
documentation, they can pick up Git and send patches.

On 3/1/22 11:12 PM, madmurphy wrote:

I don't know if this will be a popular proposal, but I really believe
that setting up a self-hosted Wiki could be a very good choice. No
complicate git clone, no complaints, just read/edit what you need, and
distributed responsibilities about its design and direction.

My two cents

Re: Attacking the documentation monster

[Christian Grothoff]

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 questions and look forward to you improving the 
documentation!


Happy hacking!

Christian

On 5/20/22 02:21, Willow Liquorice wrote:
I've got some free time on my hands now, and I gave some thought to 
improving the readability of the HTML documentation on the website 
(which is what the average prospective GNUnet dev is going to look at). 
Read the Docs and friends set the standard in this regard. Having the 
contents in a sidebar for easy access (regardless of your location) 
would be far more convenient than what's currently available.


I understand that TeXinfo's HTML generation is a bit simplistic in the 
name of compatibility, which, while not a bad thing, results in a subpar 
reading experience for the average dev who will, in all likelihood, be 
reading the docs on a very capable modern browser.


While thinking about how to improve things with TeXinfo, it occurred to 
me that, instead of trying to emulate the experience of using Read the 
Docs, one could just use Read the Docs! It's Free Software, after all. I 
haven't looked into it too deeply, but if the .texi sources are 
converted to the reStructuredText that it accepts, a migration (or use 
of a similar platform) might be worth considering. What do the people 
here think?


If I'm going to dedicate time to restructuring GNUnet's docs, I need to 
know where it all is. I've found four strands of docs in the repository 
(Handbook, Tutorial, Doxygen, and man pages), could someone give me a 
run-down of the state they're in, how they relate to one another, and 
what they're supposed to be for? Is that everything?


Thanks,
 Willow

On 01/03/2022 22:52, Christian Grothoff wrote:

Spam killed this. We already constantly have to delete 'bug reports'
from the Web that were submitted as link spam. A wiki will drain
resources to keep the spammers out, and at the same time experience says
the contributions will be low quality (it has been tried).

If someone really is capable and invests time into contributing to
documentation, they can pick up Git and send patches.

On 3/1/22 11:12 PM, madmurphy wrote:

I don't know if this will be a popular proposal, but I really believe
that setting up a self-hosted Wiki could be a very good choice. No
complicate git clone, no complaints, just read/edit what you need, and
distributed responsibilities about its design and direction.

My two cents

planned downtime

[Christian Grothoff]

Dear all,

On Monday, May 23rd (2022) we will be (forced to) move git.gnunet.org 
and git.taler.net from Bern (CH) to Biel (CH) as the campus of BFH where 
we are currently hosted is closing down this summer.


Even if everything works as planned, there will be some significant 
downtime of the Git and other co-located services affecting GNU 
Anastasis, GNUnet, GNU libmicrohttpd, GNU libextractor and GNU Taler 
development (Git), demonstrators, CI/CD, bugtracking, etc.


Keep your fingers crossed that things work at the new location ;-).


Happy hacking!

Christian
p.s.: The new location is again temporary due to construction delays at 
the new campus, but at least we will physically move within the same 
city next time.

p.p.s.: And of course thanks to BFH for hosting us for free!

Re: Cannot download source code

[Christian Grothoff]

On 4/30/22 16:50, Mikhail wrote:

On Sat, Apr 30, 2022 at 08:06:52AM -0400, fossy--- via Mailinglist for GNUnet 
developers wrote:

Hello there.
I'd just like to report: http://ftpmirror.gnu.org/gnunet/gnunet-0.16.3.tar.gz
I get this message when I go and attempt to download it:

gz.part could not be saved, because the source file could not be read.
Try again later, or contact the server administrator.

I am running OpenBSD, but I have never seen such message until now..


Can't comment on download thing, but

"ftp http://ftpmirror.gnu.org/gnunet/gnunet-0.16.3.tar.gz;

works for me.

Compiling 0.16.3 on OpenBSD won't be successful though, you need to use
git sources for now, until there is a new release.



Looks like fossy hit a broken mirror. ftpmirror points to different 
servers for different people, if one is broken, well, it may not work 
for you. In that case, just use the main ftp archive.

Re: gnurl CVE applicability

[Christian Grothoff]

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...

Re: gnurl CVE applicability

[Christian Grothoff]

I don't see how either is terribly relevant for the (limited) GNUnet 
use-cases of HTTPS. Users would have to work pretty hard on a very 
customized curl/GNUnet setup to make themselves theoretically vulnerable 
--- and even then the impact would seem negligible.  Worst I can imagine 
is a network-level adversary doing a MiTM for every hostlist request to 
force a peer to bootstrap only against malicious nodes the adversary 
controls. But such a network-level adversary can likely achieve this 
almost as well by simply dropping traffic.


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.


On 4/4/22 16:47, Nikita Ronja Gillmann wrote:

Hi,

finishing the gnunet package for pkgsrc might require merging back the 
inactive gnurl into the pkgsrc tree from pkgsrc-wip.


I've looked at the current CVEs for curl, and I have open questions for 
2 of them. Could someone take a look at them and tell me if they apply 
in the context of how gnunet makes use of gnurl?
I guess the 2 CVEs aren't applicable in our context, but I'd like to be 
sure before I decide if I merge it back or not, or if I let the security 
team add an CVE to our security db.


https://wip.pkgsrc.org/cgi-bin/gitweb.cgi?p=pkgsrc-wip.git;a=blob_plain;f=gnurl/gnurl-CVEs;h=190a57f1d3e672ae53a1ee8f799ab0068d94b1a0;hb=HEAD 



https://curl.se/docs/CVE-2021-22924.html
https://curl.se/docs/CVE-2021-22890.html

Thanks!

Re: packaging question on gnunet-gtk

[Christian Grothoff]

Hi Nikita,

I've figured it out: gnunet-conversation-gtk was only being built when
GNU libextractor was found by configure --- because it was linked
against that library. However, that linkage was no longer needed, so I
was able to remove the dependency and now it works even without LE.

So workaround: --with-extractor=$LE_PREFIX
or: update to latest Git ;-)

Happy hacking!

Christian

On 3/21/22 19:34, Nikita Ronja Gillmann wrote:
> Hi,
> 
> I've picked the gnunet packages back up for pkgsrc.
> One odd thing I observed about gnunet-gtk is that
> it does not build the gnunet-conversation-gtk binary,
> even if the conditions for it are (as per config logs)
> met.
> 
> I don't see anything in my first look at this which makes me
> think that src/conversation is set to not build.
> 
> Build transcripts for builds from 0.16.0 tarball attached,
> "building" is with a gnunet with conversations submodule,
> "building-without" is with a gnunet without conversations submodule.
> 
> 
> Note: in log file 'building', the text below essentially says that the
> expected file (at the end of the build process, during creation of the
> package file) is not found:
> 
> pkg_create: can't stat 
> `/usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk'
> => Checking file-check results for gnunet-gtk-0.16.0
> ERROR: 
> ERROR: The following files are in the PLIST but not in 
> /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg:
> ERROR: 
> /usr/work/wip/gnunet-gtk/work/.destdir/usr/pkg/bin/gnunet-conversation-gtk
> *** Error code 1
> 
> PS: please only on-list replies, thanks. I subscribed for the time being.

Re: Reducing the number of executables to one

[Christian Grothoff]

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
> 

Re: Attacking the documentation monster

[Christian Grothoff]

Spam killed this. We already constantly have to delete 'bug reports'
from the Web that were submitted as link spam. A wiki will drain
resources to keep the spammers out, and at the same time experience says
the contributions will be low quality (it has been tried).

If someone really is capable and invests time into contributing to
documentation, they can pick up Git and send patches.

On 3/1/22 11:12 PM, madmurphy wrote:
> I don't know if this will be a popular proposal, but I really believe
> that setting up a self-hosted Wiki could be a very good choice. No
> complicate git clone, no complaints, just read/edit what you need, and
> distributed responsibilities about its design and direction.
> 
> My two cents

Re: Attacking the documentation monster

[Christian Grothoff]

On 3/1/22 8:51 PM, William Liquorice wrote:
> Hello,
> 
> A year or two ago, I tried to wrap my head around GNUnet so that I could
> try to make parallel implementations of small bits in Rust, but found
> its documentation to be utterly impenetrable. Not even from a technical
> standpoint, the massive reference manual / "handbook" is quite
> overwhelming and more akin to the Lord of the Rings.

The current documentation is admittedly not suitable for that. However,
for some pieces, suitable documentation exists! I would encourage you to
look through https://lsd.gnunet.org/ in that regards, those are the
pieces of documentation that exist that are suitable for re-implementation.

> Just now, I decided to look up the documentation for GNUnet's IPC
> functionality. This is a pretty important component of GNUnet's
> modularity. One rather important section about sending an example
> AddressLookupMessage between has the immediate subheading "FIXME: This
> is very outdated, see the tutorial for the current API!"
> 
> To my annoyance, there is no link provided to this tutorial. Where is
> it? I will put the link in there myself if it exists.

Please see gnunet.git/doc/tutorial/

> I am unfamiliar with how exactly documentation is put together for
> GNUnet, but just separating out the contributor's/developer's handbook
> (most of the page) would make the actual user manual significantly less
> intimidating. It doesn't need to all be on one page.

Indeed, and texinfo allows you to do just that:

$ cd gnunet/doc/handbook/
$ texi2html --split=chapter gnunet.texi

should do the trick.

> I also made some SVG diagrams of specific GNUnet subsystems (the core
> transport -> CADET stack, GNS, VPN), but I don't recall ever hearing
> back from anyone about them. Are they any good?

I barely remember, but what I do remember is that at the time I didn't
see a good place where they would be helpful in the documentation
monster ;-).

Re: libextractor - key-value pairs and mime types

[Christian Grothoff]

I've added your patch and also clarified the use-case for RESERVED
(which is still different from your proposed 'NONE'). Anyway, for
further discussions on this, please use the libextractor list...

-Christian

On 2/8/22 7:21 PM, madmurphy wrote:
> Actually, the first thing that I thought when I read
> |EXTRACTOR_METATYPE_RESERVED| was “not used today, but tomorrow will be
> used for the book's cover” :)
> 
> It definitely needs a renaming!
> 
> --madmurphy
> 
> 
> On Tue, Feb 8, 2022 at 5:52 PM madmurphy  > wrote:
> 
> Of course, the value of |EXTRACTOR_METATYPE_RESERVED| would be even
> better (zero would be the natural value for something like this).
> 
> But then it's a lexical problem. If I see something marked as
> “reserved” I read “do not ever try to use this label”.
> 
> Since already libextractor uses |EXTRACTOR_METATYPE_RESERVED| with
> the meaning of |EXTRACTOR_METATYPE_NONE|, would it not make sense to
> rename |EXTRACTOR_METATYPE_RESERVED| to |EXTRACTOR_METATYPE_NONE|
> and tell the user that there is nothing “reserved” about it?
> 
> By instinct if I see a label named |EXTRACTOR_METATYPE_RESERVED| I
> might think that there are cases in which libextractor marks a
> metatype with |EXTRACTOR_METATYPE_RESERVED|, expecting me to treat
> is as an opaque label. Instead, |EXTRACTOR_METATYPE_NONE| to be
> usable requires libextractor never to mark anything publicly with it
> (or throw it as a return value). Since apparently this is the case,
> a comment similar to the one I had left in the patch would also be
> useful (“used by libextractor only internally; available to the user
> for marking an |enum EXTRACTOR_MetaType| as not carrying any
> meaningful value”).
> 
> --madmurphy
> 

Re: libextractor - key-value pairs and mime types

[Christian Grothoff]

On 2/8/22 2:38 PM, madmurphy wrote:
> Got it! I agree about your solution for the duplicate mime types.
> 
> but until that is done, a key-value pair type would at least be
> better than 'unknown'.
> 
> “Unknown” can continue to exist as an identifier for other cases, just
> not the key-value ones :)

Yes, of course. That's what I meant, too.

> Also I forgot to mention a third point:
> 
> 3. Add an |EXTRACTOR_METATYPE_NO_METATYPE = -1| to |enum
> EXTRACTOR_MetaType| (more or less like |NULL| if that was a pointer).
> Without a |EXTRACTOR_METATYPE_NO_METATYPE| a programmer is forced to
> save the |have_metatype| information in another variable. The fact that
> it is a negative number is not a problem, because as the name suggests,
> /it is not a metatype/.

Are you sure that EXTRACTOR_METATYPE_RESERVED (0) is not good enough
here? We usually use it to terminate lists, but as far as I see, it
should be what you think of as NO_METATYPE. But if there is a use-case
RESERVED doens't cover, I'm not categorically against introducing a -1
value.

Patches welcome ;-).

-Christian

> P.S. Sorry for picking the wrong mailing list!
> 
> 
> On Tue, Feb 8, 2022 at 9:57 AM Christian Grothoff  <mailto:groth...@gnunet.org>> wrote:
> 
> Hi madmurphy,
> 
> The 'correct' place for GNU libextractor discussions would be
> 
>   https://lists.gnu.org/mailman/listinfo/libextractor
> 
> Alas, with my libextractor maintainer hat on, I would say this:
> 
> On 2/7/22 10:01 PM, madmurphy wrote:
> > Hi again, GNUnet people.
> >
> > Is this the place where to discuss about libextractor? I have two
> points.
> >
> > #1 I often see something interesting. Key-value pairs are
> categorized as
> > |EXTRACTOR_METATYPE_UNKNOWN|:
> >
> > unknown: chroma-format=4:2:0
> > unknown: bit-depth-chroma=8
> > unknown: colorimetry=bt709
> > unknown: stream-format=avc
> > unknown: stream-format=raw
> > unknown: bit-depth-luma=8
> > unknown: base-profile=lc
> > unknown: mpegversion=4
> > unknown: profile=high
> > unknown: alignment=au
> > unknown: parsed=true
> > unknown: framed=true
> > unknown: variant=iso
> > unknown: profile=lc
> > unknown: level=4.1
> >
> > But one point is that they are often numerous, and another point
> is that
> > that of a key-value type is a really interesting metatype to have (and
> > is not really “unknown”, since the key is self-explanatory). Would it
> > not make sense to add an |EXTRACTOR_METATYPE_KEY_VALUE_PAIR| to
> the list
> > of MetaTypes?
> 
> We could do that. Sometimes I think it would be better to add new
> specific LE types for some of the above, but until that is done, a
> key-value pair type would at least be better than 'unknown'.
> 
> > ...
> >
> >   /* generic attributes */
> >   EXTRACTOR_METATYPE_UNKNOWN = 45,
> >   EXTRACTOR_METATYPE_DESCRIPTION = 46,
> >   EXTRACTOR_METATYPE_COPYRIGHT = 47,
> >   EXTRACTOR_METATYPE_RIGHTS = 48,
> >   EXTRACTOR_METATYPE_KEYWORDS = 49,
> >   EXTRACTOR_METATYPE_ABSTRACT = 50,
> >   EXTRACTOR_METATYPE_SUMMARY = 51,
> >   EXTRACTOR_METATYPE_SUBJECT = 52,
> >   EXTRACTOR_METATYPE_CREATOR = 53,
> >   EXTRACTOR_METATYPE_FORMAT = 54,
> >   EXTRACTOR_METATYPE_FORMAT_VERSION = 55,
> >   *EXTRACTOR_METATYPE_KEY_VALUE_PAIR* = XXX,
> >
> > ...
> >
> > #2 I often see that files get tagged with multiple mime types
> according
> > to libextractor:
> >
> > mimetype: video/quicktime
> > mimetype: video/x-h264
> > mimetype: audio/mpeg
> > mimetype: video/mp4
> 
> That is because different plugins (using different methods/libraries)
> disagree on the 'correct' mime-type. Ideally, we'd identify which plugin
> gets it wrong (and why), and unify the mime-types.
> 
> > But that never reflects the reality, since files should have only one
> > mime type (or at most, multiple mime types that mean the same thing).
> > But then I see what happens with file names: there is only one
> > |EXTRACTOR_METATYPE_GNUNET_ORIGINAL_FILENAME|, but there can be many
> > |EXTRACTOR_METATYPE_FILENAME|s (in the case of archives, for example):
> >
> > EXTRACTOR_METATYPE_FILENAME = 2,
> > ...
> > EXTRACTOR_METATYPE_GNUNET_ORIGINAL_FILENAME = 180,
> >
> > Would it not make s

Re: libextractor - key-value pairs and mime types

[Christian Grothoff]

Hi madmurphy,

The 'correct' place for GNU libextractor discussions would be

  https://lists.gnu.org/mailman/listinfo/libextractor

Alas, with my libextractor maintainer hat on, I would say this:

On 2/7/22 10:01 PM, madmurphy wrote:
> Hi again, GNUnet people.
> 
> Is this the place where to discuss about libextractor? I have two points.
> 
> #1 I often see something interesting. Key-value pairs are categorized as
> |EXTRACTOR_METATYPE_UNKNOWN|:
> 
> unknown: chroma-format=4:2:0
> unknown: bit-depth-chroma=8
> unknown: colorimetry=bt709
> unknown: stream-format=avc
> unknown: stream-format=raw
> unknown: bit-depth-luma=8
> unknown: base-profile=lc
> unknown: mpegversion=4
> unknown: profile=high
> unknown: alignment=au
> unknown: parsed=true
> unknown: framed=true
> unknown: variant=iso
> unknown: profile=lc
> unknown: level=4.1
> 
> But one point is that they are often numerous, and another point is that
> that of a key-value type is a really interesting metatype to have (and
> is not really “unknown”, since the key is self-explanatory). Would it
> not make sense to add an |EXTRACTOR_METATYPE_KEY_VALUE_PAIR| to the list
> of MetaTypes?

We could do that. Sometimes I think it would be better to add new
specific LE types for some of the above, but until that is done, a
key-value pair type would at least be better than 'unknown'.

> ...
> 
>   /* generic attributes */
>   EXTRACTOR_METATYPE_UNKNOWN = 45,
>   EXTRACTOR_METATYPE_DESCRIPTION = 46,
>   EXTRACTOR_METATYPE_COPYRIGHT = 47,
>   EXTRACTOR_METATYPE_RIGHTS = 48,
>   EXTRACTOR_METATYPE_KEYWORDS = 49,
>   EXTRACTOR_METATYPE_ABSTRACT = 50,
>   EXTRACTOR_METATYPE_SUMMARY = 51,
>   EXTRACTOR_METATYPE_SUBJECT = 52,
>   EXTRACTOR_METATYPE_CREATOR = 53,
>   EXTRACTOR_METATYPE_FORMAT = 54,
>   EXTRACTOR_METATYPE_FORMAT_VERSION = 55,
>   *EXTRACTOR_METATYPE_KEY_VALUE_PAIR* = XXX,
> 
> ...
> 
> #2 I often see that files get tagged with multiple mime types according
> to libextractor:
> 
> mimetype: video/quicktime
> mimetype: video/x-h264
> mimetype: audio/mpeg
> mimetype: video/mp4

That is because different plugins (using different methods/libraries)
disagree on the 'correct' mime-type. Ideally, we'd identify which plugin
gets it wrong (and why), and unify the mime-types.

> But that never reflects the reality, since files should have only one
> mime type (or at most, multiple mime types that mean the same thing).
> But then I see what happens with file names: there is only one
> |EXTRACTOR_METATYPE_GNUNET_ORIGINAL_FILENAME|, but there can be many
> |EXTRACTOR_METATYPE_FILENAME|s (in the case of archives, for example):
> 
> EXTRACTOR_METATYPE_FILENAME = 2,
> ...
> EXTRACTOR_METATYPE_GNUNET_ORIGINAL_FILENAME = 180,
> 
> Would it not make sense to do something similar for mime types? Only one
> “original mime type”, and an infinity of secondary mime types…?
> 
> EXTRACTOR_METATYPE_MIMETYPE = 1,
> ...
> *EXTRACTOR_METATYPE_GNUNET_ORIGINAL_MIMETYPE* = XXX,

I guess it depends. If this is for archives where files _inside_ the
archive are given mime-types, then a different metatype makes sense
(ditto for FILENAME: here we probably could have two types, one for the
'archive' and one for the 'contents'). But if the different mime-types
are all about the 'original' file, then we should rather figure out
which plugin gets it wrong. As for the "_GNUNET_" in the
"_GNUNET_ORIGINAL_FILENAME" there, IIRC this again different because
that is NOT a metatype used by GNU libextractor, but one that GNUnet
itself generates and puts with the 'rest ' of the metadata.

> So, two simple proposals:
> 
>  1. Create |EXTRACTOR_METATYPE_KEY_VALUE_PAIR|
>  2. Create |EXTRACTOR_METATYPE_GNUNET_ORIGINAL_MIMETYPE|
> 
> What do you think? Does it make sense?

It should definitively not be "GNUNET_ORIGINAL_MIMETYPE", and the real
question is what is the origin of the different mime-types. If this is
from an archive, maybe we should introduce

EXTRACTOR_MIMETYPE_ARCHIVE_CONTENT_FILENAME
EXTRACTOR_MIMETYPE_ARCHIVE_CONTENT_MIMETYPE

and reserve

EXTRACTOR_MIMETYPE_FILENAME
EXTRACTOR_MIMETYPE_MIMETYPE

for the top-level file. But AFAIK that won't solve your mime-type issue,
which should really be resolved by going over the plugins and finding
out why and where they disagree and picking the 'right' answer.

My 2 cents

Christian

Re: Using some GPL comments in GFDL documentation

[Christian Grothoff]

Yes, that's fine. -Christian

On 2/6/22 3:44 PM, Maxime Devos wrote:
> Hi,
> 
> Some documentation I've been writing for Scheme-GNUnet (GNUnet-
> Scheme?) (GFDL1.3+, no invariant sections) is based on comments in
> src/include/gnunet_mq_lib.h, but that C header is GPL3+ licensed.  Do I
> have permission to use it in the GFDL1.3+ documentation (see
> attachement)?
> 
> More specifically, I've adapted the comments on
> GNUNET_MQ_PriorityPreferences, see attachement.
> 
> Greetings,
> Maxime.
> 

Re: gnunet.org currently not online

[Christian Grothoff]

Strange, seems an apt-get upgrade failed to restart apache. Fixed now.
Thanks for reporting! -Christian

On 1/10/22 2:45 PM, hyazin...@emailn.de wrote:
> Hello,
> 
> trying to visit gnunet.org fails currently. No matter if via https:// or 
> http:// .
> 
> 
> Best regards,
> Bastian Schmidt
> 
> 
> 

Re: Problem with sharing files

[Christian Grothoff]

Hi!

I looked into this a bit, but could not find it. What is known:

1) The client must be doing a datastore PUT or RESERVE operation (both
are possible), and expects the datastore to return a STATUS response
(type 94), but that never happens.

2) I checked, and on all code paths the datastore should generate a
STATUS for PUT/RESERVE requests. So I figured maybe it is blocked on
some other request, but also that does not seem to be the case from the
code logic. But, hard to be sure.

3) Some paths depend on the storage plugin being used (postgres, sqlite,
mysql, heap). It might help if you could (a) say which one you used, and
(b) tried with a different storage plugin so we can see if this is
plugin-specific.

4) I tried with 'gnunet-publish' on my system, which worked fine. Did
you try the CLI, or only gnunet-fs-gtk? It should not make a difference,
but diagnosing the issue might be easier if we can reproduce it with a CLI.

Last but not least, I did in the past have issues with the database if
it had gotten very big and slow. That's partially because of design
issues in FS, and partially because of naive usage of the database(s) --
depending on which backend you are using.  So another question here is:
how big is your database? I'd usually expect it to be empty if this is
you testing things for the first time, but if your peer was running for
a while, it might have grown to many gigabytes and may be really just
terribly slow...

My 2 cents

Christian

On 12/22/21 2:55 PM, TheJackiMonster wrote:
> Hey,
> 
> I'm currently working on the implementation of file sharing via GNUnet-
> FS service in the messenger-gtk application. But only the callback from
> uploading gets called only once with 0/N bytes uploaded and after some
> time the following warning shows up multiple times:
> 
>ERROR Request 0x5590f0f01830 of type 94 at head of datastore queue
>for more than 1 m
> 
> I've also thought this would be caused by some implementation issue on
> application side. So I checked using cadet-gtk which worked in the past
> already (it fails similarly) and even gnunet-fs-gtk provides the same
> problem. The upload starts but it does not proceed.
> 
> Maybe someone working on the datastore or FS service knows more details
> about this or how this could be fixed?
> 
> Happy hacking
> Jacki
> 

Re: gnunet.org currently not online

[Christian Grothoff]

My bad. Fixed now. -Christian

On 11/30/21 2:29 PM, hyazin...@emailn.de wrote:
> Hello,
> 
> trying to visit gnunet.org fails currently. No matter if via https:// or 
> http:// .
> 
> 
> Best regards,
> Bastian Schmidt
> 
> 
> 

Re: From gnunet-bcd to configure.ac

[Christian Grothoff]

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!

Happy hacking!

Christian

Re: Remove me from the buildbot mailing list

[Christian Grothoff]

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.
> 

Re: Patch for GNUnet documentation

[Christian Grothoff]

On 10/4/21 11:18 PM, Yujiri wrote:
> I found a couple of typographical errors in the GNUnet handbook and have 
> attached a patch. Please forgive any failure to follow protocols as this is 
> my first time using git format-patch ;)

Thanks, applied!

> There is another documentation issue I wanted to mention, which I didn't 
> create a patch for because I'm not sure exactly what to do about it. I was 
> going to run the unit tests before patching, even though it's just 
> documentation, but the instructions in the README under Hacking GNUnet say to 
> begin with ./configure, but there is no ./configure. This could be a 
> misunderstanding on my part but I believe the instructions should be clearer 
> if so.
> 

If you use Git, you first have to run 'bootstrap'. The README
instructions are for users of the .tar.gz, and there the 'configure'
will exist.

Happy hacking!

Christian



signature.asc
Description: OpenPGP digital signature

Re: GNU Anastasis press release of September 29, 2021 badly linked by Planet GNU: Fixable on our site?

[Christian Grothoff]

Well, I already noticed this, and I fixed the RSS generation (almost
immediately), but still the GNU planet picked up the new RSS but _also_
kept the old one. Hence the news shows up twice, once with a working and
once with a broken link.

Worse, the news site's CSS is awful, so I cannot in good faith recommend
reading it:

https://anastasis.lu/en/news/2021-10.html

IMO the designers did an inadequate job in that they overrode _all_
default styles for everything, destroying the standard functions of
things like  in their wake of making the main page(s) pretty,
instead of using a special style to be applied only to the pages where
they are needed.

If some CSS hacker were to fix that, I'd be much obliged. The Git with
the code is at git.taler.net/anastasis-www.git ;-)

Happy hacking!

Christian

On 10/4/21 5:52 PM, hyazin...@emailn.de wrote:
> Hello,
> 
> 2 issues:
> 
> 1. When you visit https://www.gnu.org/ today and have a look at the embedded 
> Planet GNU news window at the upper part of the site on the right, one of the 
> three news snippets is said GNU Anastasis press release:
> 
> '*GNU Anastasis v0.2.0 released*: GNU Anastasis is a Free Software protocol 
> and implementation that allows users to securely deposit core secrets with an 
> open set of escrow providers and to reco... '
> 
> The part between the two *'s has a clickable link, this one: 
> https://anastasis.lu/en/news/news/2021-10.html
> 
> Clicking on it doesn't lead to the teasered news, but instead to
> 
> '404 Not Found
> nginx/1.18.0'
> 
> Visiting https://planet.gnu.org/ the news snippet listed 2 times, is a bit 
> more extended, and has more links:
> 
> '
> *GNU Anastasis v0.2.0 released*
> GNU Anastasis is a Free Software protocol and implementation that allows 
> users to securely deposit core secrets with an open set of escrow providers 
> and to recover these secrets if their original copies are lost.
> 
> *29 September, 2021 10:00PM*
> 
> #GNU Anastasis v0.2.0 released#
> GNU Anastasis is a Free Software protocol and implementation that allows 
> users to securely deposit core secrets with an open set of escrow providers 
> and to recover these secrets if their original copies are lost.
> 
> #29 September, 2021 10:00PM#'
> 
> The 2 parts between two *'s have the same problem as experienced with the 
> embedded Planet GNU window on gnu.org.
> 
> The 2 parts between the two #'s has a working link, leading to 
> https://anastasis.lu/en/news/2021-10.html
> 
> I thought it's useful to inform you about this flaw, because you're certainly 
> interested in getting this news item out as good as possible and by knowing 
> that flaw you maybe can fix it one way or another. I don't know if the wrong 
> link is from somewhere on the GNU Anastasis website and correctly grapped by 
> Planet GNU, or if the flaw originates from Planet GNU itself.
> In the first case, maybe the link can be found and fixed, in the later case, 
> maybe GNUnet team can inform Planet GNU team, so that the Planet GNU team can 
> fix the link - maybe for now regarding said news or sustainably so that this 
> flaw doesn't happen again in future grapped press releases of GNU Anastasis.
> 
> 2.
> Besides, navigating through https://anastasis.lu/ seperately to it's news 
> section https://anastasis.lu/en/docs_news.html one discovers a news snippet 
> to said news, but no link to the press release.
> 
> 
> Best regards,
> Bastian Schmidt
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Re: Planning to continue working on Secushare

[Christian Grothoff]

Thanks. Applied as c94699a..d1d0d07. -C

On 10/3/21 11:16 AM, Tobias Platen wrote:
> I wrote a patch for gnunet-secushare.git that fixes 
> the config files that gnunet-arm will read.
> The @UNIXONLY@ stuff is removed since that causes a parse error.
> 
> Tobias
> 
> On Thu, 2021-09-23 at 11:56 +0200, TheJackiMonster wrote:
>> On Thu, 2021-09-23 at 11:39 +0200, carlo von lynX wrote:
>>> On Thu, Sep 23, 2021 at 11:05:06AM +0200, carlo von lynX wrote:
 The circular topology of end points *does* satisfy the secushare
 expectations on privacy and metadata privacy in particular
 AFAICT,
 so that's very cool.
>>>
>>> Whoopsa I'm posting faster than I am thinking, sorry. No, without
>>> any form of obfuscation such a scheme is not metadata-safe, just
>>> like multicast without onion routing wouldn't be.
>>>
>>> A few thoughts on metadata protection in the case of ring
>>> topologies.
>>>
>>> For maximum metadata protection we would need an onion routing
>>> layer below CADET which would hide any communication between two
>>> participants, or we could be having a second API-compatible CADET
>>> which actually has onion routing inside.. an ORCADET.
>>
>> I think it should be possible to use onion routing on the transport
>> layer below CADET. So CADET would still use peer identities for its
>> connections but the actual host behind it stays anonymous. Then the
>> messenger service can hide identities on a user-level.
>>
>> If we get an awesome app out of this also depends a lot on the user
>> interface. I'm currently working towards a resposive GUI application
>> which aims to be comparable to Telegram in terms of design but
>> Threema
>> in terms of transparency. For example the status of verification for
>> contacts should be visible and understandable to users. File sharing
>> inside of groups is also possible in a similar way as Threema
>> implements it but using the FS submodule of GNUnet instead of central
>> file servers.
>>
>>>
>>> I'm wondering if we can also achieve a reasonable degree of
>>> metadata
>>> protection by using less optimal ring structures and rather have
>>> multiple shared secrets on an existing ring. It still makes it
>>> clear which social bubbles exist, just not who exactly is talking
>>> to whom.
>>>
>>> If we enlarge such circles the metadata protection improves as the
>>> social bubble blurs, but in exchange the reliability  and speed of
>>> the ring is reduced, possibly to the point of not satisfying the
>>> job.
>>>
>>> Reminds me of the shards of Bitmessage - they were approaching the
>>> problem from the opposite side, starting out with a broadcast
>>> strategy, then reducing the broadcasts to slices of the totality.
>>>
>>> There may be some in-between constellation that works well enough 
>>> to achieve plausible metadata protection and there may be
>>> mathematical
>>> ways of modeling the architecture to prove how deep we need to dig.
>>>  
>>> For things that aren't time-critical (the secushare higher layers
>>> would know) Jeff's good-ole Mixes might come into play...
>>>
>>>
>>
> 



signature.asc
Description: OpenPGP digital signature

Re: What's a simple way to set up a private network of a few peers for testing purposes?

[Christian Grothoff]

Why don't you just run a few VMs on your local machine? It's not like a
GNUnet peer requires tons of resources, so a typical system should
easily be able to run several VMs with a GNUnet peer in each. If you
then disable external network connectivity, you're pretty much
guaranteed to only be talking to yourself ;-).

My 2 cents

-Christian

On 9/23/21 4:25 PM, Alessio Vanni wrote:
> Hello,
> 
> as per the subject, I'm looking for a way to set up a small independent
> network of peers to test an application.
> 
> What I'm looking for is primarily for this network to exist
> independently from the normal global GNUnet network that peers connect
> to when using the default configuration.
> 
> I don't really care if the testing can be automated or if it has to be
> handled manually, or if there are concerns about speed or stability; as
> long as the above condition holds I'm fine with anything. I can probably
> work around issues, if there's a need to.
> 
> I know that GNUnet has TESTING and TESTBED, but I can't tell if whatever
> they do happens on a dedicated network of peers or if they still make
> contacts with the outer world, in addition to having to study the API,
> so I haven't yet tried them.
> 
> The main reason is that I have some test data that I don't want to (and
> for some of it "can't") distribute on the global network, but I can't
> run any tests without having two or three other connected peers.
> 
> If it makes things different, as briefly said in the subject, the
> network can just be a total of three peers connected with each other, as
> that is enough to check if the application works regardless of other
> metrics, so I don't really need things that might make setting things up
> more complex.
> 
> Thanks,
> A.V.
> 
> P.S. to be honest, "just use TESTBED" would be the ideal answer, but
> since I need independence and I don't know if TESTBED does it, I thought
> I'd ask before spending time on something that I don't need.
> 



signature.asc
Description: OpenPGP digital signature

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

[Christian Grothoff]

On 9/15/21 12:57 PM, 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.

Nice.

> (*) 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?

See https://git.gnunet.org/: usually we'd call it gnunet-scheme. At
least that'd be consistent with the cocoa, go, nim, java and python
bindings / integrations...

> 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@?

Yes, alas I might need to manually approve info-gnunet@ (ditto for
messages from non-subscribers), so they might arrive with some delay.

> 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?

Yes, that would be desirable (also for your contributions), as that
could allow GNUnet e.V. to re-license/dual-license if ever required.
Note that the process is very simple (one signature), can be done under
a pseudonym (if you contribute under a pseudonym), and you also get to
keep the copyright! See https://gnunet.org/en/copyright.html for details.

As a rule of thumb, if you want write-access to git.gnunet.org, you must
sign the copyright agreement (technically what we do is not an
_assignment_ but _sharing_ of the copyright).

> 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.

I think that's a fine (and maybe generally preferable) approach rather
than doing bindings. I'd just not do the crypto itself directly in
Guile, that's likely neither performant nor safe. The real question is,
does your work render the bindings obsolete?

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

Very nice ;-).

Happy hacking!

-Christian



signature.asc
Description: OpenPGP digital signature

Re: Gettext macros (and a couple other ones)

[Christian Grothoff]

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: OpenPGP digital signature

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

[Christian Grothoff]

Hi Alessio,

Sorry that it took me even longer to reply, but it took me a while to
get around to coming up with a good answer.

I've now done so with Git 00c03c7bb..f9f3cbe9f.

With that change, the logic gnunet-config shared with taler-config and
anastasis-config is now properly moved into libgnunetconfig, so we can
avoid the PRELOAD hack in the future.

For how to do GNUnet-only extensions of the existing gnunet-config tool,
please see the "backend_check" option.

I hope that answers this issue.

Best,

Christian

On 8/3/21 4:49 PM, Alessio Vanni wrote:
> Hello,
> 
> apologies for the late reply...
> 
> Christian Grothoff  writes:
> 
>> I suggest youy pass all of the information (also possibly via #define's)
>> into the GNUNET_OS_ProjectData and grab it from there! That way, Taler
>> can override it without having to change gnunet-config itself.
> 
> I'm not really sure about this approach, but it's mostly because I don't
> know the reasoning behind Taler's way of doing things.  If I could get
> somewhere resources about why Taler is overriding gnunet-config with
> LD_PRELOAD, rather than using its own dedicated program, that would be
> very helpful.
> 
> At the very least, if the change is actually done in GNUnet, it would
> help with coming up with a solution that would fit all the interested
> parties (as much as possible), instead of something hacked together
> without knowing anything.
> 
> Also, I'm going to push a tentative Autoconf macro. It's going to be in
> the same branch because it still relates to "build infos", but since it
> lives in "contrib" it should not cause too many issues.
> 
> Thanks,
> A.V.
> 



signature.asc
Description: OpenPGP digital signature

Re: Git server migration

[Christian Grothoff]

Hmm. Not sure why Apache stopped running, but I have now restarted it.
Should be back. -Christian

On 9/3/21 6:28 PM, hyazin...@emailn.de wrote:
> Probably related: Since today connection issues arise when trying to access 
> gnunet.org:
> 
> https://gnunet.org:
> Firefox can't connect
> 
> 'Unable to connect
> 
> Firefox can’t establish a connection to the server at gnunet.org.
> 
> The site could be temporarily unavailable or too busy. Try again in a few 
> moments.
> If you are unable to load any pages, check your computer’s network 
> connection.
> If your computer or network is protected by a firewall or proxy, make 
> sure that Tor Browser is permitted to access the Web.
> 
> [OPTION]
> Try again'
> 
> http://gnunet.org/—with activated HTTPS Everywhere:
> HTTPS Everywhere stops process for warning
> 
> 'HTTPS Everywhere noticed you were navigating to a non-HTTPS page, and tried 
> to send you to the HTTPS version instead. The HTTPS version is unavailable. 
> Most likely this site does not support HTTPS, but it is also possible that an 
> attacker is blocking the HTTPS version. If you wish to view the unencrypted 
> version of this page, you can still do so by disabling the 'Encrypt All Sites 
> Eligible' (EASE) option in your HTTPS Everywhere extension. Be aware that 
> disabling this option could make your browser vulnerable to network-based 
> downgrade attacks on websites you visit.
> 
> http://gnunet.org/
> 
> [OPTIONS]
> Copy URL
> 
> Proceed anyway (unsafe)
> 
> Disable on this site'
> 
> 
> Greetings,
> Bastian Schmidt
> 
> --- Ursprüngliche Nachricht ---
> Von: "Schanzenbach, Martin" 
> Datum: 01.09.2021 19:20:50
> An: Gnunet Developers ,  help-gnunet 
> , libmicroht...@gnu.org
> Betreff: Git server migration
> 
>> 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: OpenPGP digital signature

Re: [PATCH gana 0/1] gnu-name-system-record-types: Add entry for ERIS_READ_CAPABILITY

[Christian Grothoff]

Done. -Christian

On 9/2/21 9:57 AM, pukkamustard wrote:
> Hello GNUNet,
> 
> I would like to request an addition to the GANA "GNU Name System record 
> types" registry for ERIS read capabilities. Following patch adds the entry.
> 
> ERIS (http://purl.org/eris) is an encoding of content into uniformly sized, 
> encrypted blocks. Access to the ERIS read capability allows the content to be 
> reconstructed. A GNS record type allows meaningful names to be associated 
> with ERIS encoded content.
> 
> ERIS is a variation of the ECRS encoding (see 
> http://purl.org/eris#_previous_work), which is currently used in the GNUNet 
> filesharing application.
> 
> I have added a corresponding section in the ERIS specification: 
> http://purl.org/eris#_gana_considerations
> 
> Kind regards,
> pukkamustard
> 
> pukkamustard (1):
>   gnu-name-system-record-types: Add entry for ERIS_READ_CAPABILITY
> 
>  gnu-name-system-record-types/registry.rec | 5 +
>  1 file changed, 5 insertions(+)
> 



signature.asc
Description: OpenPGP digital signature

Re: A GNUNET_log oddity

[Christian Grothoff]

On 31.08.21 15:41, Alessio Vanni wrote:
>> As for applications using libgnunetutil, well, they again need to copy
>> that mechanism into their configure-scripts, or they won't get
>> DEBUG-level logging. I think that's OK.  That said, we _may_ be able to
>> improve the (developer) handbook documentation on logging on this point.
> 
> Then if no one minds, I'm going to flip the value given to
> GNUNET_EXTRA_LOGGING when the configure script doesn't define it, from 0
> to 1, so that third-party application developers can leverage the full
> range of error levels during development (e.g. me, while I test things
> out in my application and decide to get swamped by messages only when
> something strange happens.)  I'm not sure if giving larger values, like
> GNUnet does, is meaningful when the goal is to get debug messages. If
> even more verbosity is required, developers should probably use their
> own mechanism.

Sounds good to me.

-Christian

Re: A GNUNET_log oddity

[Christian Grothoff]

Dear Alessio,

The idea behind DEBUG-level logging was to allow developers to put tons
of verbose log messages into the code _without_ having to worry about
increasing the code size on production systems. GNUnet should run on
embedded-ish systems, and binary size does matter. The idea behind the
configure flag is that by default, DEBUG messages are never included,
and only developers can (and likely will) explicitly enable them to aid
their diagnosis.

So if you want a message to be possibly visible to ordinary users,
formulate it nicely and log at INFO level. DEBUG messages are, as the
name says, for debugging, and that's not something normal users should
have to do ;-).

As for applications using libgnunetutil, well, they again need to copy
that mechanism into their configure-scripts, or they won't get
DEBUG-level logging. I think that's OK.  That said, we _may_ be able to
improve the (developer) handbook documentation on logging on this point.

My 2 cents

Christian

On 8/29/21 8:31 PM, Alessio Vanni wrote:
> Hello,
> 
> I was recently puzzled by a behaviour which apparently has been going on
> for a while, but I noticed it only now.
> 
> It seems that `GNUNET_log' (and `GNUNET_log_from') is unable to print
> messages when the error level is GNUNET_ERROR_TYPE_DEBUG under certain
> circumstances.
> 
> Consider this small testcase:
> 
> #include 
> #include 
> #include 
> #include 
> 
> static void
> run(void *cls, char *const *args, const char *cf, const struct 
> GNUNET_CONFIGURATION_Handle *cfg) {
>  GNUNET_log(GNUNET_ERROR_TYPE_ERROR, "error\n");
>  GNUNET_log(GNUNET_ERROR_TYPE_WARNING, "warning\n");
>  GNUNET_log(GNUNET_ERROR_TYPE_INFO, "info\n");
>  GNUNET_log(GNUNET_ERROR_TYPE_DEBUG, "debug\n");
>  GNUNET_SCHEDULER_shutdown();
> }
> 
> int main(int argc, char *argv[]) {
>  const struct GNUNET_GETOPT_CommandLineOption opts[] = {
> GNUNET_GETOPT_OPTION_END,
>  };
>  return GNUNET_PROGRAM_run(argc, argv, "test-client", "",
>  opts, , NULL);
> }
> 
> (To compile it just run
> 
> gcc -o   -lgnunetutil
> 
> nothing else is required.)
> 
> If you run it with different values for the `-L' flag, you will see that
> `-L DEBUG' will print only up to INFO.
> 
> Apparently, this is because of this condition check:
> 
> (GNUNET_EXTRA_LOGGING > 0) || ((GNUNET_ERROR_TYPE_DEBUG & (kind)) == 0)
> 
> Trying to understand why a message is logged only when this condition is
> true, I discovered that it was introduced in a commit that simply says:
> 
> "Let the compiler not include debug strings in binary when make is not
> configured with verbose"
> 
> (The commit's full hash is: 51ded2191d94c707434cc5e082c7053f9469f149)
> 
> This is somewhat in line with a section of the GNUnet Developer
> Handbook, specifically about building GNUnet from source:
> 
> "If you want to be able to enable DEBUG-level log messages, add
> ‘--enable-logging=verbose’ to the end of the ‘./configure’ command.
> ‘DEBUG’-level log messages are in English only and should only be useful
> for developers (or for filing really detailed bug reports)."
> 
> Because the above doesn't apply to applications not part of the GNUnet
> core, there is currently no way to log DEBUG-level messages unless the
> application developer knows that GNUNET_EXTRA_LOGGING has to be defined
> to a value bigger than 0; it is normally set to 0 if the symbol is not
> defined in "gnunet_common.h".
> 
> It's true that there is a comment briefly explaining
> GNUNET_EXTRA_LOGGING and that it could be possible to change its value
> to a different number when it's not defined (never happens in GNUnet
> core, as configure.ac always define a value for it) in a way that
> applications have DEBUG-level logging enabled by default, but should the
> current behaviour be kept at all in the first place?
> 
> DEBUG-level messages, even when enabled, still require the `-L' flag to
> be set to "DEBUG", so no matter how GNUnet is built users will never see
> those messages unless they explicitly ask for them. Similarly, people
> interested in DEBUG-level messages first will have to build GNUnet with
> the appropriate "configure" flags, which might not be possible in
> certain situations, and then use `-L' accordingly.
> 
> I think that at least the calls to `GNUNET_log' (and `GNUNET_log_from',
> and other similar "generic" function/macros) should always try to print
> something, letting the `-L' flag decide whether the user should see the
> message or not, leaving the whole GNUNET_EXTRA_LOGGING stuff as
> something used internally by GNUnet and nothing else (since it is used
> in a few places to include or exclude some code paths.)
> 
> Thanks,
> A.V.
> 



signature.asc
Description: OpenPGP digital signature

Re: Gettext macros (and a couple other ones)

[Christian Grothoff]

On 8/25/21 9:42 PM, Alessio Vanni wrote:
> This means that once the application is being executed, gettext will try
> to search the application's PO files for the e.g. the string
> 
> "Assertion failed at %s:%d. Aborting.\n",
> 
> failing because that string is defined in a header which gettext doesn't
> know about, thus always displaying the original string and defeating the
> purpose of using gettext at all.

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.

> For this problem the solution is simple: just change any call to `_'
> with an explicit call to `dgettext' and give it the appropriate domain,
> but this actually creates a new issue.
> 
> Currently, GNUnet's gettext domain is set inside the
> `GNUNET_OS_ProjectData' structure defined in `gnunet_os_installation.c'
> and it's set to the macro "PACKAGE". To make sure both GNUnet's
> internals and the macros in the util header use the same domain, the
> dgettext calls ought to also use PACKAGE as their domain arguments.

There is a much simpler (and IMO proper) solution: GNUNET_OS_ProjectData
should really just use "gnunet" and not PACKAGE.

> While I was investigating this issue I discovered that there is at least
> one other macro where an Autoconf macro can be overridden, giving an
> inappropriate value.
> 
> Again inside the util header there is the macro "GNUNET_AGPL_URL", which
> is currently defined as:
> 
> #define GNUNET_AGPL_URL "https://gnunet.org/git/gnunet.git#; PACKAGE_VERSION

Oh, that should at least be updated to git.gnunet.org, fixing as well ;-).

> Inside GNUnet this correctly gives
> "https://gnunet.org/git/gnunet.git#0.15.2; (or whatever the current
> version is when expanded), but if used within an application with e.g. a
> version number of "13.0.1" it will generate
> "https://gnunet.org/git/gnunet.git#13.0.1; which is obviously incorrect
> as of today.
> 
> I can think of a couple of ways to fix these issues, for example by
> having a separate header file for this kind of macros, which is expanded
> by Autoconf at configure time (i.e. a ".h.in" generating a ".h") and
> thus the values can't be overridden, but before progressing I'd like to
> ask for opinions, in case changing how these macros are handled ends up
> touching things I wasn't aware of.

I think that would likely be the best fix for the PACKAGE_VERSION issue.
 We _could_ use this also for the PACKAGE issue you raised, but here I'm
fine with just hard-coding "gnunet" as a quick fix.

> Hopefully things can be changed without too many consequences, as it's
> otherwise a fairly easy issue to tackle and fix.

I also do not currently see any unintended consequences of what you
describe.

> Thanks,
> A.V.
> 
> P.S.: Apologies for the long e-mail for what in the end is a simple
> issue, but I wanted to explain in details to avoid (as much as possible)
> misunderstandings. :)

Thanks for the very clear report ;-).

> P.P.S: Is the GNUNET_AGPL_URL value correct? Currently it redirects to
> the homepage of git.gnunet.org, but I don't know if that's what it
> should point to.

The idea was to point to the tag. I have fixed that in Git as well.

-Christian



signature.asc
Description: OpenPGP digital signature

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

[Christian Grothoff]

On 25.07.21 15:23, Alessio Vanni wrote:
> Hello,
> 
> Christian Grothoff  writes:
> 
>> 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!)
> 
> I don't follow Taler's development, so I didn't know about this "trick".
> Thanks for reporting.

Sure, it is very non-obvious ;-).

> I'm going to push a patch to change the hardcoded values to something
> based on the values returned by `GNUNET_OS_installation_get_path'.
> Hopefully that's going to work for Taler, as I can't think of any other
> way to have it print the includedir and the libdir otherwise :)

I suggest youy pass all of the information (also possibly via #define's)
into the GNUNET_OS_ProjectData and grab it from there! That way, Taler
can override it without having to change gnunet-config itself.

> As a side note, to keep gnunet-config coherent with the pkg-config
> definition, I also had it print `-lgnunetutil' when using the `--libs'
> flag.
> 
> I don't know how Taler handles its public APIs, if it has any, so if an
> application wants to compile against Taler it would be useful to have
> taler-config also print e.g. `-ltalerutil'.

Yes, it is similar. So you should get the "-gnunetutil" also from some
new field you add to the GNUNET_OS_ProjectData. Ideally, you could even
put an array of command-line options into GNUNET_OS_ProjectData, so that
all of the new functions you add becomes fully customizable via LD_PRELOADs.

> I doubt this is something that gnunet-config can handle internally, so
> if Taler (or any application using the LD_PRELOAD + gnunet-config combo)
> has special needs for the `--libs' (or even the `--cflags') flag, the
> execution with that flag should be intercepted somehow and the
> appropriate values appended to the default output of gnunet-config.

My point was the "intercepted somehow" we should use is the
customization via the GNUNET_OS_ProjectData!

Happy hacking!

Christian

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

[Christian Grothoff]

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
> 

Re: Problem Building GNUNet (Devuan GNU/Linux)

[Christian Grothoff]

You need to grab libsodium from testing or wait for the next Devuan
stable release. Debian/Devuan allow you to mix distributions. You may
find the instructions at

https://docs.taler.net/taler-exchange-manual.html#installing-the-gnu-taler-binary-packages-on-debian

helpful for that particular setup.

Happy hacking!

Christian

On 7/18/21 9:03 PM, AllLogarithmsEqual wrote:
> Hi GNU Net Developers,
> 
> Just for fun, I tried to configure and install GNU Net from source (gcc
> version 8.3.0), but I ran into problems due to missing libraries. I was
> able to install a few of them very easily (libgcrypt, libjansson,
> libcurl, and so forth), but the one that I'm stuck on is libsodium.
> 
> `apt` tells me that "libsodium-dev is already the newest version
> (1.0.17-1)," but I know that the system requires me to have libsodium
> 1.0.18 or higher. So I went to the libsodium page and tried to download
> 1.0.18 from their releases page
> , but even after
> installing this into /usr/local/lib, the configure script (for GNU Net)
> yields the same version error.
> 
> Could you let me know if you can help me find it?
> Any help would be well-appreciated.
> 
> -Vince, aka allLogarithmsEqual
> 
> P.S. I love developing in C, but I cannot promise I can contribute much
> to this. I just wanted to see if I could test it out.
> 
> Sent with ProtonMail  Secure Email.
> 



signature.asc
Description: OpenPGP digital signature

Re: Datastore warning

[Christian Grothoff]

There are different datastore plugins (sqlite, postgres, mysql). Alas,
that will likely only help a bit.  Ultimately, I think we need to
completely rework the FS subsystem to not store so many small blocks and
instead keep files whole. But that is a very big task nobody is yet
working on. -Christian

On 03.07.21 00:04, Guilherme Macedo via Mailinglist for GNUnet
developers wrote:
> Hey!
> 
> I was checking my GNUnet's log and saw that it's generating tons of entries 
> like this:
> 
> # tail -f /var/log/gnunet.log
> Jul 02 23:59:20-094877 fs-476 ERROR Request 0x11__OMITTED__ of type 100 at 
> head of datastore queue for more than 1 m
> Jul 02 23:59:20-152517 fs-476 WARNING Datastore lookup already took 1 m!
> Jul 02 23:59:20-158602 fs-476 WARNING Datastore lookup already took 2 m!
> Jul 02 23:59:20-170017 fs-476 WARNING Datastore lookup already took 4 m!
> Jul 02 23:59:20-246629 fs-476 WARNING Datastore lookup already took 2 m!
> Jul 02 23:59:20-350934 fs-476 WARNING Message `Datastore lookup already took 
> 2 m!' repeated 1 times in the last 104 ms
> Jul 02 23:59:20-350934 fs-476 WARNING Datastore lookup already took 9 m!
> Jul 02 23:59:20-371016 fs-476 WARNING Datastore lookup already took 3 m!
> Jul 02 23:59:20-419521 fs-476 WARNING Datastore lookup already took 5 m!
> Jul 02 23:59:20-512454 fs-476 WARNING Datastore lookup already took 4 m!
> Jul 02 23:59:20-563323 fs-476 WARNING Datastore lookup already took 2 m!
> Jul 02 23:59:20-599091 fs-476 WARNING Datastore lookup already took 4 m!
> 
> I suppose that this is not expected. I couldn't find any info in the handbook 
> about how to fix or tune the datastore, except for the QUOTA option.
> 
> Does anyone knows about this error and how to fix it, please?
> 
> Appreciate any help in advance.
> 
> Best regards.
> 
> Guilherme Macedo
> 

Re: Some questions about the hostlist

[Christian Grothoff]

On 06.07.21 00:04, Guilherme Macedo via Mailinglist for GNUnet
developers wrote:
> Hey!
> 
> I've a few questions about how the hostlist works, after reading the handbook 
> and looking into the source code.
> 
> Why the hostlist is tied to a specific versioned subdomain - 
> http://v14.gnunet.org/hostlist ?

Because protocol changes may require using a different hostlist for
different versions of GNUnet.

> Could it be made generic like https://gnunet.io/hostlist ?Every time that 
> it's updated, it also requires the handbook to be updated too.
> Why it's served through plain http?

For no particular reason, other than the server not yet being setup with
HTTPS support.

> The file doesn't seem to be signed, so how can the network protect itself 
> from malicious or rogue nodes?

The hostlist is one way of bootstrapping, the network has other ways to
bootstrap. This is NOT a directory server like in Tor listing all nodes.

> Is the validation being done in some code besides 
> https://git.gnunet.org/gnunet.git/tree/src/hostlist ?

No. As I said, this is not a list of all the nodes in the network, and
the hostlist server is no special authority. Anyone can run one, and
offer any subset of the peers.

> What is the purpose of fulcrum.net.in.tum.de in 
> https://git.gnunet.org/gnunet.git/tree/src/hostlist/hostlists_learn_peer2.file
>  ?

That was simply a peer which used to run GNUnet. It has no particular
meaning, the file is simply a valid hello IIRC.

> Who curates the hostlist?

Nobody, really. It is dynamically generated based on the peers known to
the specific peer serving a hostlist.

> I'm asking because there is a difference between the hosts available in 
> http://v14.gnunet.org/hostlist and https://gnunet.io/hostlist .

Which is again by design perfectly acceptable. You can use either or
both hostlists, or offer a third one yourself that is again different.

> Appreciate if someone could point to me specific section in the handbook or 
> in the source code that I might have missed, please.

Maybe https://docs.gnunet.org/handbook/gnunet.html#HOSTLIST-Subsystem ?

Happy hacking!

Christian

Re: Error download hostlist

[Christian Grothoff]

Hi Guilherme,

Good to know this was the problem. I've updated the instructions to
clarify this point better.

Thanks!

Christian

On 6/27/21 11:11 AM, Guilherme Macedo wrote:
> Hi Christian.
> 
> Indeed I haven't updated /etc/apt/sources.list to include testing and 
> unstable. I just followed Taler's doc without realizing this missing step - 
> `which means you should use a system which at least includes unstable 
> packages in its source list`.
> 
> Thanks for helping with this!
> 
> Now I have GNUnet working in both Debian and Ubuntu.
> Best regards.
> 
> Guilherme Macedo
> 
> 
> 
> 27 Jun 2021, 00:05 by groth...@gnunet.org:
> 
>> Hi Guilherme,
>>
>> Did you actually update your /etc/apt/sources.list to include
>> testing/unstable packages? Looks like you're _only_ on stable, which
>> cannot satisfy our dependencies.
>>
>> /etc/apt/sources.list should contain lines like:
>>
>> deb http://ftp.ch.debian.org/debian/ testing main
>> deb http://ftp.ch.debian.org/debian/ unstable main
>>
>> -Christian
>>
>> On 6/26/21 11:45 PM, Guilherme Macedo wrote:
>>
>>> Hi Christian.
>>>
>>> I tried to install in Debian stable, as according to the instructions in 
>>> the doc, but it failed while trying to download the dependencies.
>>>
>>> # apt install -f -t sid gnunet
>>> Reading package lists... Done
>>> Building dependency tree  
>>> Reading state information... Done
>>> Some packages could not be installed. This may mean that you have
>>> requested an impossible situation or if you are using the unstable
>>> distribution that some required packages have not yet been created
>>> or been moved out of Incoming.
>>> The following information may help to resolve the situation:
>>>
>>> The following packages have unmet dependencies:
>>> gnunet : Depends: libgnunet (= 0.14.1-1) but it is not going to be installed
>>>   Depends: libc6 (>= 2.29) but 2.28-10 is to be installed
>>>   Depends: libgnutls-dane0 (>= 3.7.0) but it is not going to be 
>>> installed
>>>   Depends: libgnutls30 (>= 3.7.0) but 3.6.7-4+deb10u7 is to be 
>>> installed
>>>   Depends: libsodium23 (>= 1.0.18) but 1.0.17-1 is to be installed
>>> E: Unable to correct problems, you have held broken packages.
>>>
>>> I tried to force the install, but I failed. Certainly it's trivial to fix, 
>>> but I must admit that my Linux skills are a bit rusty. I've been using Mac 
>>> for too long. Maybe it's time to switch back :)
>>>
>>> So I opted for the easy way, installed Ubuntu and used the package provided 
>>> by Taler (v0.14.1 git-2a1a812f3). It worked like a charm!
>>>
>>> The only issue that I had, is that it complained that it could not create 
>>> /var/log/gnunet.log. I just had to create it manually for GNUnet to finally 
>>> work. Not sure if it's related to Taler's package or if I should open a bug 
>>> report.
>>>
>>> I'll try another time to compile it again from source. Now it's time to 
>>> play a bit with GNS and re:claimID :)
>>>
>>> Quick question, is there a doc about which ports are needed and used by 
>>> GNUnet?
>>> I'm asking in order to harden the server and only open the needed ones in 
>>> the firewall.
>>>
>>> Best regards.
>>>
>>> Guilherme Macedo
>>>
>>>
>>>
>>> 25 Jun 2021, 08:12 by groth...@gnunet.org:
>>>
 I recommend installing a way more recent package, i.e. by following:

 https://docs.taler.net/taler-exchange-manual.html#installing-the-gnu-taler-binary-packages-on-debian

 And then running

 # apt install -t sid gnunet

 instead of

 # apt install -t sid taler-exchange

 ;-)

 Happy hacking!

 Christian

 On 6/25/21 12:05 AM, Guilherme Macedo via Mailinglist for GNUnet
 developers wrote:

> Hey!
>
> I installed GNUnet v0.10.1 in Debian 10.10 from the package provided by 
> the distro. However, for some reason I can't connect to the peer network 
> since it can't download the hostlist. The returned error is:
>
> hostlist-645 WARNING Download of hostlist from 
> `http://v10.gnunet.org/hostlist' failed: `Couldn't resolve host name'
>
> If I try to download it manually, I receive the same error.
>
> % curl http://v10.gnunet.org/hostlist    
> curl: (6) Could not resolve host: v10.gnunet.org
>
> I've read the documentation, but I couldn't find a solution. Maybe the 
> solution is trivial, so apologies in advance.
>
> Best regards.
>
> Guilherme Macedo
>
> 



signature.asc
Description: OpenPGP digital signature

Re: Error download hostlist

[Christian Grothoff]

Hi Guilherme,

Did you actually update your /etc/apt/sources.list to include
testing/unstable packages? Looks like you're _only_ on stable, which
cannot satisfy our dependencies.

/etc/apt/sources.list should contain lines like:

deb http://ftp.ch.debian.org/debian/ testing main
deb http://ftp.ch.debian.org/debian/ unstable main

-Christian

On 6/26/21 11:45 PM, Guilherme Macedo wrote:
> Hi Christian.
> 
> I tried to install in Debian stable, as according to the instructions in the 
> doc, but it failed while trying to download the dependencies.
> 
> # apt install -f -t sid gnunet
> Reading package lists... Done
> Building dependency tree  
> Reading state information... Done
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
> 
> The following packages have unmet dependencies:
> gnunet : Depends: libgnunet (= 0.14.1-1) but it is not going to be installed
>   Depends: libc6 (>= 2.29) but 2.28-10 is to be installed
>   Depends: libgnutls-dane0 (>= 3.7.0) but it is not going to be 
> installed
>   Depends: libgnutls30 (>= 3.7.0) but 3.6.7-4+deb10u7 is to be 
> installed
>   Depends: libsodium23 (>= 1.0.18) but 1.0.17-1 is to be installed
> E: Unable to correct problems, you have held broken packages.
> 
> I tried to force the install, but I failed. Certainly it's trivial to fix, 
> but I must admit that my Linux skills are a bit rusty. I've been using Mac 
> for too long. Maybe it's time to switch back :)
> 
> So I opted for the easy way, installed Ubuntu and used the package provided 
> by Taler (v0.14.1 git-2a1a812f3). It worked like a charm!
> 
> The only issue that I had, is that it complained that it could not create 
> /var/log/gnunet.log. I just had to create it manually for GNUnet to finally 
> work. Not sure if it's related to Taler's package or if I should open a bug 
> report.
> 
> I'll try another time to compile it again from source. Now it's time to play 
> a bit with GNS and re:claimID :)
> 
> Quick question, is there a doc about which ports are needed and used by 
> GNUnet?
> I'm asking in order to harden the server and only open the needed ones in the 
> firewall.
> 
> Best regards.
> 
> Guilherme Macedo
> 
> 
> 
> 25 Jun 2021, 08:12 by groth...@gnunet.org:
> 
>> I recommend installing a way more recent package, i.e. by following:
>>
>> https://docs.taler.net/taler-exchange-manual.html#installing-the-gnu-taler-binary-packages-on-debian
>>
>> And then running
>>
>> # apt install -t sid gnunet
>>
>> instead of
>>
>> # apt install -t sid taler-exchange
>>
>> ;-)
>>
>> Happy hacking!
>>
>> Christian
>>
>> On 6/25/21 12:05 AM, Guilherme Macedo via Mailinglist for GNUnet
>> developers wrote:
>>
>>> Hey!
>>>
>>> I installed GNUnet v0.10.1 in Debian 10.10 from the package provided by the 
>>> distro. However, for some reason I can't connect to the peer network since 
>>> it can't download the hostlist. The returned error is:
>>>
>>> hostlist-645 WARNING Download of hostlist from 
>>> `http://v10.gnunet.org/hostlist' failed: `Couldn't resolve host name'
>>>
>>> If I try to download it manually, I receive the same error.
>>>
>>> % curl http://v10.gnunet.org/hostlist    
>>> curl: (6) Could not resolve host: v10.gnunet.org
>>>
>>> I've read the documentation, but I couldn't find a solution. Maybe the 
>>> solution is trivial, so apologies in advance.
>>>
>>> Best regards.
>>>
>>> Guilherme Macedo
>>>
> 



signature.asc
Description: OpenPGP digital signature

Re: Error download hostlist

[Christian Grothoff]

I recommend installing a way more recent package, i.e. by following:

https://docs.taler.net/taler-exchange-manual.html#installing-the-gnu-taler-binary-packages-on-debian

And then running

# apt install -t sid gnunet

instead of

# apt install -t sid taler-exchange

;-)

Happy hacking!

Christian

On 6/25/21 12:05 AM, Guilherme Macedo via Mailinglist for GNUnet
developers wrote:
> Hey!
> 
> I installed GNUnet v0.10.1 in Debian 10.10 from the package provided by the 
> distro. However, for some reason I can't connect to the peer network since it 
> can't download the hostlist. The returned error is:
> 
> hostlist-645 WARNING Download of hostlist from 
> `http://v10.gnunet.org/hostlist' failed: `Couldn't resolve host name'
> 
> If I try to download it manually, I receive the same error.
> 
> % curl http://v10.gnunet.org/hostlist    
> curl: (6) Could not resolve host: v10.gnunet.org
> 
> I've read the documentation, but I couldn't find a solution. Maybe the 
> solution is trivial, so apologies in advance.
> 
> Best regards.
> 
> Guilherme Macedo
> 



signature.asc
Description: OpenPGP digital signature

Re: Taler press release of 17 June 2021 badly linked by Planet GNU: Fixable on our site?

[Christian Grothoff]

Hi Bastian,

Thanks for the long report, I think I've fixed the links now (both for
the GNUnet and GNU Taler RSS feeds.)

-Christian

On 6/21/21 5:57 PM, hyazin...@emailn.de wrote:
> Hello,
> 
> when you visit https://www.gnu.org/ today and have a look at the embedded 
> Planet GNU news window at the upper part of the site on the right, one of the 
> three news snippets is said Taler press release:
> 
> ' *How to issue a privacy-preserving central bank digital currency*: We are 
> happy to announce the publication of our policy brief on"How to issue a 
> privacy-preserving central bank digital currenc...'
> 
> The part between the  two *'s has a clickable link, this one: 
> https://taler.net/en/news/news/2021-06.html
> 
> Clicking on it doesn't lead to the teasered news, but instead to
> 
> '404 Not Found
> nginx'
> 
> Visiting https://planet.gnu.org/ the news snippet is a bit more extended and 
> has more links:
> 
> 
> 'June 16, 2021
> #GNU Taler news#
> *How to issue a privacy-preserving central bank digital currency*
> We are happy to announce the publication of our policy brief on"How to issue 
> a privacy-preserving central bank digital currency" by The European Money and 
> Finance Forum.
> 
> *16 June, 2021 10:00PM* '
> 
> The part between the two #'s has a working link, leading to 
> https://taler.net//
> 
> The both parts between two *'s have the same problem as experienced with the 
> embedded Planet GNU window on gnu.org.
> 
> Following the working link of said part between the two #'s, and scrolling 
> down the website to the news section reveals, that the correct link to said 
> press release is the following and, of course, finally leads to said complete 
> news one originally got interested by the news snippets on gnu.org and Planet 
> GNU: https://taler.net/en/news/2021-06.html
> 
> I thought it's useful to inform you about this flaw, because you're certainly 
> interested in getting this news item out as good as possible and by knowing 
> that flaw you maybe can fix it one way or another. I don't know if the wrong 
> link is from somewhere on the Taler website and correctly grapped by Planet 
> GNU, or if the flaw originates from Planet GNU itself.
> In the first case, maybe the link can be found and fixed, in the later case, 
> maybe GNUnet team can inform Planet GNU team, so that the Planet GNU team can 
> fix the link - maybe for now regarding said news or sustainably so that this 
> flaw doesn't happen again in future grapped press releases of Taler.
> 
> 
> Best regards,
> Bastian Schmidt
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Jyväskylä

[Christian Grothoff]

Dear all,

It looks like I will be visiting Jyväskylä in early August. So if
someone from Finland here wants to meet me, or invite me to give a talk,
this could be an opportunity...

Happy hacking!

Christian



signature.asc
Description: OpenPGP digital signature

Re: CADET API: Obtaining the CADET channel closure?

[Christian Grothoff]

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...

Happy hacking!

Christian

On 5/24/21 10:37 PM, Alessio Vanni wrote:
> Hello,
> 
> there might be a better way to do what I'm trying to do, but I couldn't
> really think of it, so here it is:
> 
> I'm opening CADET channels on demand and then stashing them away until
> they are needed again (or closed.) Because those channels require some
> "state" when something is received through them, I give them a closure
> which is unique for each of them and allocated dynamically at the time
> of the channel creation.
> 
> When the other end of the channel shuts down or when the service itself
> terminates, this closure is deallocated through the disconnect callback.
> However, when a channel is closed manually with the `channel_destroy'
> function, this closure would linger and never be deallocated as the
> callback is not called.
> 
> Most of this "state" provided by the closure could actually be provided
> in a different way, but the remaining part would be really inefficient
> without this closure, so for the sake of avoiding having to continuously
> run a for-loop every time certain actions are taken, I'm approaching the
> issue this way.
> 
> Would it be possible to get that closure somehow? As it is right now
> it's impossible, but a way to do it could be added somewhere, if it
> makes sense.
> 
> I see that there is a function to fetch channel options which currently
> returns only the other peer; maybe it could be expanded?
> 
> Thanks,
> A.V.
> 



signature.asc
Description: OpenPGP digital signature

Re: Improving FCFS daemon

[Christian Grothoff]

FCFS is just a software that allows anyone to run a
first-come-first-served registry. That's not something for GANA.

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.

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. ;-)

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.
>>
>