don't feel
like trying to reproduce those tbh.
Was the NULL check missing due to performance or something?
Kind regards
fenceFrom fe5757f56f2443e1bc95ad17ab376be781752877 Mon Sep 17 00:00:00 2001
From: fence
Date: Tue, 23 Jul 2024 15:33:50 +0200
Subject: [PATCH] util: fix segfaults when c
g 201 is more suited
for the nature of the endpoint.
The attached patch fixes that.
kind regards,
fence
From 39b8f30d1f19ddec2dddb4bbce6839d79cc2c951 Mon Sep 17 00:00:00 2001
From: fence
Date: Wed, 31 Jul 2024 00:34:26 +0200
Subject: [PATCH] rest: ensure identity plugin follows docs
The
Hello mailing list,
I have a question about the identity service's IPC interface.
Were the message types "GNUNET_MESSAGE_TYPE_IDENTITY_GET_DEFAULT" and
"GNUNET_MESSAGE_TYPE_IDENTITY_SET_DEFAULT" deprecated? or are they just
unimplemented? Or am I just blind?
kind regards,
fence
Yes, I found it there.
I think they should be kept as the message types meant something in the
past, but a comment above indicating that they're deprecated would be
helpful.
fence
On 05.08.2024 10:58, Schanzenbach, Martin wrote:
Hello,
yes, it was remov
Hewo,
Is there a reason why GNUNET_JSON_GNSRECORD_FLAG_SHADOW is only
deserialised but never serialised?
Is that a bug or was the functionality removed and still being parsed in
case an old client still sending the flag?
kind regards,
fence
So I've looked into the issue and fixed it.
The shadow flag wasn't parsed properly from JSON and it overwrote the
"is_supplemental" flag when converting a record to JSON.
As for the rewrite, I don't have that much time on my hand right now.
kind regards,
fe