Re: GSoC 2024: gnunet-gtk gtk4 upgrade
On 28.02.2024 3:20, Jacki wrote: But I assume it's also possible to use Cambalache already. Most important functionality should work. It's also possible to write UI files by hand instead of using Glade. On Tue, 2024-02-27 at 20:58 +0100, Christian Grothoff wrote: Let me just say this: using a RAD tool like Glade is just the only logical thing, it is 1000% more productive for UX development then doing the building of Gtk objects by hand. So for the sake of sanity, please use *some* RAD tool. Besides, AFAIK GtkBuilder isn't deprecated, just Glade itself is being rewritten/replaced. We used Glade for quite a while despite it being WIP/in beta, with GNOME's reluctance to declare something stable I'm not sure a WIP RAD tool is inherently a bad idea. But I *am* sure that doing gtk_box_add() by hand is the road to insanity. So I would very strongly recommend using Cambalance --- and to use the opportunity to clean up the GUIs ;-). On 2/27/24 20:51, Schanzenbach, Martin wrote: I think our use of glade is historical. It just made sense to somebody (not me, my guess is Christian). I personally have no issue with moving away from glade as RAD tool as I find it very cumbersome myself. Note, however, that it will also mean writing a lot of code that is currently hidden behind those glade XML files. OTOH moving to a WIP RAD tool is also not such a smart idea, maybe. But that depends on the maturity of cambalanche, which I cannot judge myself right now as I have never tried it. BR On 27.02.24 20:19, Gotam Gorabh wrote: Hello Martin, Note that migration from gtk3 to gtk4 especially for gnunet- gtk is not trivial: We use libglade, which does not exist for gtk4. We will need to decide if we want to migrate to something like https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-released/ < https://blogs.gnome.org/xjuan/2023/09/28/cambalache-0-16-0-release d/> or something different entirely. Why can't we use the proper GObject concept like other gnome application does? E.g. GNOME Settings, Nautilus, etc. which can handle the properties, and signals in a structured way. Thanks. Regards Gotam Gorabh -- O< ascii ribbon - stop html email! - www.asciiribbon.org OpenPGP_signature Description: OpenPGP digital signature
[GNUnet-developers] The function of GNUNET_SCHEDULER_FdInfo->sock
What is it used for? I did grep the code, but some things are unclear. Specifically, this field is sometimes used with the calls that look like: GNUNET_NETWORK_fdset_test_native (ws, pos->fdi->sock)) Does that imply that the sock field is interpreted as a socket descriptor in these cases? I.e. GNUnet is not trying to fill fdset with file descriptors for local files? signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
[GNUnet-developers] Missing gnunet_reclaim_plugin.h
That file is mentioned in src/include/Makefile.am, but it's not in git. signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] New README.md and Github
On 02.08.2018 14:58, Nils Gillmann wrote: > GNOME is still a GNU project, right? Because they have a very active mirror > account: > https://github.com/GNOME > > Just as an example for GNU on Github. Gnome is, in general, lax on the software freedom purity issue. It also recently set up its own gitlab instance[1], so while that Github mirror will probably continue to exist (for the reasons already stated earlier), all the action (issue tracking, git pushes, branches, personal repositories) happens elsewhere. I don't think that GNUnet, being more ideologically-focused, can be as lax as the giant, diverse Gnome project. [1]: http://gitlab.gnome.org/ signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] Post-quantum symetric crypto
On 22.02.2016 23:14, Jeff Burdges wrote: > > Symmetric crypto might start worrying more about being post-quantum > soon : http://arxiv.org/abs/1602.05973 There was a presentation about post-quantum crypto at 32c3[1], they even have a website[2]. [1] https://media.ccc.de/v/32c3-7210-pqchacks [2] http://pqcrypto.org -- O< ascii ribbon - stop html email! - www.asciiribbon.org signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] copyright assignment
On 23.12.2015 15:10, Christian Grothoff wrote: > On 12/23/2015 11:52 AM, LRN wrote: >> On 23.12.2015 12:09, Christian Grothoff wrote: >>> I would like to ask all contributors/developers to assign their >>> copyright on GNUnet code to "GNUnet e.V." (https://gnunet.org/ev) >>> >>> The reason is that situations continue to pop up where the ability to >>> dual-license some code would be helpful for the project (similar to how >>> we added GPL+eCos to GNU libmicrohttpd in the past). If we had the >>> copyright with GNUnet e.V., then at least we had a relatively small >>> group (the annually elected "Vorstand") representing the developers in a >>> position of making decisions about dual-licensing. >>> >> >> I will sign away my copyright to anything i've contributed to GNUnet (and, >> if you want, GNUnet-gtk and Extractor; by the way, what's the status of MHD >> in this regard? Though my contributions to MHD are very minor, so it >> shouldn't matter), on the condition that my contributions are dual-licensed >> under GPLv2+ (or GPLv3+, or v4+, or whatever) and LGPLv2.1+ (and i'll bump >> v2.1+ to v3+ or even higher as needed). The reason for this is that i've >> tinkered with the utility code (mostly its W32 side) a lot and i would >> really like to be able to re-use it elsewhere, as an LGPL library or in a >> project that is LGPL-licensed (in glib and GTK+, for example). > > Ok, I guess I should clarify: I'm not asking you to exclusively assign > rights to GNUnet e.V., we merely need that GNUnet e.V. has 'shared' > ownership and thus the right to add additional licenses if necessary > (obviously there is no plan to abandon GPLv3+). So you currently have > and would preserve the right to dual-license your contributions. > I'm still not sure how this stands legally (IANAL, by the way) - is there such thing as a "shared right to re-license"? I assume you've had some legal advice in this regard. And given that (as far as you've told us) this is not the usual copyright assignment (as practiced by, say, FSF), how does it relate to other copyright-assignment-ish things? Such as copyright enforcement (can "GNUnet e.V." go after copyright infringers? Does it intend to?). But if what you describing is correct, then i'm OK with that kind of assignment. -- O< ascii ribbon - stop html email! - www.asciiribbon.org signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] copyright assignment
On 23.12.2015 12:09, Christian Grothoff wrote: > I would like to ask all contributors/developers to assign their > copyright on GNUnet code to "GNUnet e.V." (https://gnunet.org/ev) > > The reason is that situations continue to pop up where the ability to > dual-license some code would be helpful for the project (similar to how > we added GPL+eCos to GNU libmicrohttpd in the past). If we had the > copyright with GNUnet e.V., then at least we had a relatively small > group (the annually elected "Vorstand") representing the developers in a > position of making decisions about dual-licensing. > I will sign away my copyright to anything i've contributed to GNUnet (and, if you want, GNUnet-gtk and Extractor; by the way, what's the status of MHD in this regard? Though my contributions to MHD are very minor, so it shouldn't matter), on the condition that my contributions are dual-licensed under GPLv2+ (or GPLv3+, or v4+, or whatever) and LGPLv2.1+ (and i'll bump v2.1+ to v3+ or even higher as needed). The reason for this is that i've tinkered with the utility code (mostly its W32 side) a lot and i would really like to be able to re-use it elsewhere, as an LGPL library or in a project that is LGPL-licensed (in glib and GTK+, for example). -- O< ascii ribbon - stop html email! - www.asciiribbon.org signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] social messaging progress
On 09.09.2015 0:05, tg (x) wrote: > * Next steps > > Next steps will be a client application to demonstrate the use of the social > API How are you going to call it? How about WhatsGNU? :) -- O< ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
[GNUnet-developers] Broken udp plugin? ARM test fails
When test_gnunet_service_arm runs, it fails for me.
Debugging shows that it segfaults while loading udp plugin (LoadLibrary()
call). The crash happens deep in W32 libs, so i don't know exactly why this
happens.
The change that introduced this error happened somewhere between 23 Feb and 28
Mar of 2015, W32 buildslave (or buildmaster) didn't work at the time, so we
don't have the precise bot reports for that period.
After git-bisecting i found that
27a9e1b1a7e7c1454eae1337c8c63a4fa2d722f6 is the first bad commit
commit 27a9e1b1a7e7c1454eae1337c8c63a4fa2d722f6
Author: grothoff grothoff@140774ce-b5e7-0310-ab8b-a85725594a96
Date: Sat Mar 7 20:18:54 2015 +
simplify test, log failure cause
git-svn-id: https://gnunet.org/svn/gnunet@35356
140774ce-b5e7-0310-ab8b-a85725594a96
The commit does not touch udp, but does change test_gnunet_service_arm. It's
full of style fixes (hey, grothoff! Thank you for mixing style fixes and
meaningful code changes!), but does have this noticeable chunk of code removed:
- char *armconfig;
-
- if (NULL != cfgfile)
- {
-if (GNUNET_OK !=
-GNUNET_CONFIGURATION_get_value_filename (c, arm, CONFIG,
- armconfig))
-{
- GNUNET_CONFIGURATION_set_value_string ((struct
GNUNET_CONFIGURATION_Handle *) c,
- arm, CONFIG,
- cfgfile);
-}
-else
- GNUNET_free (armconfig);
- }
No explanation is given other than simplify test, log failure cause (hey,
grothoff! Thank you for almost never leaving descriptive commit messages!).
Note that other ARM tests do have this chunk of code.
Adding this chunk back solves the problem for me - test_gnunet_service_arm does
not crash. Here's a patch.
--
O ascii ribbon - stop html email! - www.asciiribbon.org
From fef6e0716a6bbca8096414b4e7cfd923f720da7e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
=?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= lrn1...@gmail.com
Date: Fri, 24 Apr 2015 00:35:32 +
Subject: [PATCH] Partially revert r35356
---
src/arm/test_gnunet_service_arm.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/src/arm/test_gnunet_service_arm.c
b/src/arm/test_gnunet_service_arm.c
index 3e4b9db..465652e 100644
--- a/src/arm/test_gnunet_service_arm.c
+++ b/src/arm/test_gnunet_service_arm.c
@@ -38,6 +38,7 @@
#define TIMEOUT GNUNET_TIME_relative_multiply (GNUNET_TIME_UNIT_SECONDS, 10)
+static const struct GNUNET_CONFIGURATION_Handle *cfg;
static int ret = 1;
@@ -172,6 +173,20 @@ run (void *cls,
const char *cfgfile,
const struct GNUNET_CONFIGURATION_Handle *c)
{
+ char *armconfig;
+ cfg = c;
+ if (NULL != cfgfile)
+ {
+if (GNUNET_OK != GNUNET_CONFIGURATION_get_value_filename (cfg, arm,
+CONFIG, armconfig))
+{
+ GNUNET_CONFIGURATION_set_value_string ((struct
GNUNET_CONFIGURATION_Handle
+ *) cfg, arm, CONFIG,
+ cfgfile);
+}
+else
+ GNUNET_free (armconfig);
+ }
arm = GNUNET_ARM_connect (c, NULL, NULL);
GNUNET_ARM_request_service_start (arm, arm,
GNUNET_OS_INHERIT_STD_OUT_AND_ERR,
--
1.8.5.3
0x922360B0.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] GNUnet and multi-threading
On 22.10.2014 15:50, Andrew Cann wrote: Over the last couple of days I've been writing a rust library for GNUnet. Rust libraries are supposed to use a mult-threaded-with-blocking-calls api design but I couldn't find a way to build this around the C library's single-threaded-event-loop-with-callbacks design. So I ended up avoiding GNUnet's scheduler entirely which meant re-writing all of the socket-level stuff. Would people be interested in me implementing this or should I stick to re-writing parts of the api in Rust? IMO, rewrite. GNUnet scheduler and event loop with callbacks are a necessary evil: GNUnet avoids multithreading in C, and this is the only way to do it (that i know of). Any operations that could take any considerable amount of time are broken up into multiple procedures chained together by the scheduler. This complicates debugging and makes the code more difficult to read. Don't drag this into Rust, use tasks for such things. You may or may not need some kind of event dispatcher loop (possibly multiple loops?), but it will just spawn tasks to handle stuff, at most. Hopefully. I don't grok Rust well enough to just make up a working model for a GNUnet service written in Rust in my head without running it past the compiler to see if it relies on something unsafe. Also, interfacing with GNUnet C libraries basically makes your program unsafe: you call a C library that has very weak safety guarantees (and could have even more threading-related issues hidden by the fact that GNUnet avoids multithreading) instead of using the unsafe keyword to isolate small pieces of code where you, personally, can enforce safety (as it's too complex for the compiler to handle). Do spend a few months (years?) re-writing parts of libgnunetutil in Rust on top of Rust stdlib. That's better than spending decades catching bugs and arguing with the GNUnet C implementation devs about the interface they present in the libraries and how it could be made more Rust-friendly. You'll probably be able to re-use parts of the util librariy related to crypto/hashes. -- O ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] W32 console woes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.01.2014 21:31, Nils Durner wrote: I have found no way to wait (and thus select) on a console handle. I haven't actually tried it, but the documentation for WaitForMultipleObjects() explicitely specifies Console input as a supported handle type (maybe obtained by GetStdHandle()?). Tried WaitForSingleObject() on the console input handle, didn't work. Thus it will have to be done with a thread. Other idea: reimplement the console (like Turbo Pascal for Windows did) and add MsgWaitForMultipleObjectsEx() to plibc's select(). Right...At this rate it'll be easier to just use conemu. OR we could do our usual trick and fork another helper process to interact with the console ;-). That might work, as it turns console I/O into socket or pipe I/O (both of which are supported), from the point of view of the application. (Probably) phrased differently: do the actual work in a background process and have a really lean, telnet(.exe) like, console UI. A proper Windows implementation would be easy to do then. Well, i did implement a console helper as grothoff suggested. Worked for me (though i had to fudge the inheritance a bit to make sure children do get access to the console). Which leads me to the question: do we really need interactive console on Windows? Without knowing anything about the background subject, I'd say: no. Either have a real graphical UI or forget about it. That is what i think as well. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSzY48AAoJEOs4Jb6SI2Cwi/gIAIB8BP3j5qxYhFQzYplB9Ls2 5UqZm3uxl5aDaetcaNUCqXmXfDX6u+yKNeDfF01g23sIxmrqxz6ER3z1owO+OKfU A1UDut20HThHVMwDfueEj8lKaVQxntavC0oYonw5HVtKXQMXc+3/HwyiXIrjdKu5 urxf4pnFQfUNsCF/HAv4Q1K8h5xtppkaHgIMNxZqcCNmC41YHWDpvC9OSPc9qMqR hv16pmHVp3cKgh7eJ6xs9TjKAF6PvhdEmH8Pu6xZypaot/elQiTE1XC0KEV8DJTg F5TQnb8nfpN2W00j4k9bHKY1J2ygGzRieqHDmA1sI84EzxKK/QoZCXsNTGU8KOU= =6bnN -END PGP SIGNATURE- ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] NS updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02.03.2013 16:49, LRN wrote: A compromise solution would be to enable hashmap check, but make it more sophisticated - take more than just id into account. Also, when a previously-traversed item is encountered, don't just return immediately - add the item, and set it up so that choosing it will make the selection jump to its other copy somewhere else (which is the only copy that is selectable; through i'm not sure i can make GtkComboBox do that...), also marking it as such, and then return. So it will be a tree, but with loopends that user can traverse. Here's how it looks (hashes last_id, next_id, uri and last_meta). Didn't even try to do that selection-jumping thing though. But it looks OK without it too, so maybe that's enough. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRMf3TAAoJEOs4Jb6SI2CwEuUIAL2u7h0i1z6AW7hc+iyBjupH 5Nl9HN4q2IrBfFQS6l/+w7agTrHUnhAzc+qBN1A+rOSa64ATahl2tZ/DGGiH53i3 yESPQGErQNftwhqAGMOQujpJ/4/hQ1hG1LcgDN3QUCZ9CH2DdXSK+cEiM0qdm34S bAN+N5tvvn57pNhnpzaFCfB3Z0l0pfEge7EenWiqGCqALEyeiKEZQBPXO8NWw0tf 0z4BbQboWUL9yWcFm0BDo7muUZoGa0987DCvngJRRBkRrEt8sfhokP+tS1999l4E JsjE31308VoWYLDdWtyo85MyeoVlbcjlvuXhPfrET2eSiBUHTAfYvUIDJ005Hp8= =Qvzw -END PGP SIGNATURE- attachment: gnunet_publishing_master_dropped_down_complexhashmap_morecycles.png___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
[GNUnet-developers] NS updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm looking at gnunet-fs-gtk core at the moment, and i don't get it. It is my understanding that 'next_id' is simply an identifier, and its presence in metadata indicates that GNUnet client should do a search for that identifier, and any results should be considered 'updated' versions of the original. Fairly straightforward. add_updateable_to_ts() inserts last_id value it gets from the iterator as PSEUDONYM_MC_LAST_ID, while setting PSEUDONYM_MC_NEXT_ID to an empty string. GNUNET_GTK_master_publish_dialog_execute_button_clicked_cb() gets PSEUDONYM_MC_LAST_ID and PSEUDONYM_MC_NEXT_ID and uses them as identifier and update identifier respectively. When populating the treeview, PSEUDONYM_MC_CURRENT_ID_EDITABLE is set to FALSE for all updateable items, it seems, and TRUE for all empty rows (for new publications that do not update anything). PSEUDONYM_MC_NEXT_ID_EDITABLE is always TRUE, no matter what. But. GNUNET_FS_namespace_list_updateable () passes nsn-id as a second callback argument (which becomes last_id), and nsn-update as a last callback argument (which becomes next_id). So. fs-gtk pseudonym threeview seems to have four different item types: 1) Blanks - items for new publications, where you can edit both 'id' and 'next_id' 2) Leaves - items for updates, where 'id' is frozen with the value of 'next_id' from a previous publication, and 'next_id' is editable. 3) Stems - items that were inserted during the updateable items graph walking. Their 'id' is frozen with the value of 'next_id' from a previous publication, and 'next_id' is editable. They differ from the leaves in that there already were updates to these items. Updating them again will sprout more leaves (creating ambiguity, as one stem will now have 1 possible updates instead of 0 or 1 updates). 4) Root - initial publication that started the update graph. Its 'id' is frozen with the value of 'id' (!) from the initial publication, and 'next_id' is editable. Making updates with this item will, in fact, produce a new publication with the same identifier (thus increasing ambiguity, as one identifier will now yield multiple items), and not update anything. IMO (4) should not be in the list at all, why does add_updateable_to_ts() add it? And the need of (3) is debatable as well, since they break linearity of the update graph. If (3) is to be offered, it should at least be indicated appropriately (to think of it, (4) may remain in the tree as well, it just has to be unusable for publications). Do we _strive_ for linear update graphs at all? It'd prefer to encourage users to maintain linear update graphs. If someone wants branching graphs, we should offer a special widget for that (you ever seen git commit trees in tutotirals? that's how that special widget should look like, roughly). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRLKp+AAoJEOs4Jb6SI2CwtWgIANHV0qyepzKytSnpBycP9hbN gohrabUHSfsq9KH6KOkWuXk8tU/8V2zAVYZ26LdxcAHbck50fmXmTyZSAbtpKNIY xgjVnSOWOrcLAgC+eKygnRxsu0Q+KVsk6Q2mX3t/JNOi6AUYkVICZhO9Izf9KSU1 j3i0oVdsmG9qnoo74Vx9+FRkvSOf74uLB5Q+U8O9TOZOMSvRkO9EV87XLlFNAvut tZg/IUkNAQi8HDqvlsrIMqcNGRRdqPIHOgTJsBXJ8Ww22xssSw+nrofHOTsOx0SJ KPJ5g54uwAK5XfqF+gCOVMCG6RtSPGyt9VH3ljgSahzb66M8Aayh1pkJML1jU/8= =uKtX -END PGP SIGNATURE- ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] Idea for file storage in GNUnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Answer: Because it disturbs the logical flow of communication. Question: Why so many people think that top-posting is bad? On 07.12.2012 7:28, hypothesys wrote: I understand (or at least believe I do) your point about the available storage not being a priority as it is not limitative, however could this increased storage not make up for a potencially lower latency for the network? After all, if the there is more storage the same data could be made available from a greater number of nodes. As such the number of network hops a single data block has to travel between the asking node and the data provider node diminishes, and so does latency at least when in darknet mode. I do not know if this would be impossible due to the way GNUnet routes data, or a misconception on my reasoning, but I assume GNUnet must use some implementation of Key-based routing and DHT. Perhaps this lower latency could pose problems from the anonymity POV, and I cannot predict the security implications, still it would not mean that the smallest route had to be taken, only diminishing the minimum number of hops necessary to transfer data. Probably it would mean small-world networks world would become smaller proportionately to the total amount of available storage at each node. You'd have to wait for Grothoff's reply to get his opinion on this. My highly uneducated guess is that data variety is greater than the available space. Thus, no matter how large datastores of GNUnet nodes are, the probability of just finding a block of data in a random node that is not sharing it on purpose is relatively small, as compared to sharing files on purpose (which likely means using indexing - datastore size is not relevant) OR sharing blocks that are also being downloaded by the node (i.e. seeding what you're downloading; unless you're stingy, your datastore would be large enough to fit all of them anyway) OR sharing hot, often-requested blocks (that's the best case for increased datastore size). Now, what i find compelling in this idea is the space management. When i think of what i would tell people about setting up a GNUnet node, and specifically - about choosing the datastore size, the answer i come up with is this: Think of the largest number of files you'd be downloading simultaneously, then add their sizes together - that's the minimum space you should allocate for datastore. However, if that wost-case scenario actually happens, your node will not run optimally - all your datastore will be filled with the blocks you're downloading right now, while all migrated blocks will be removed, and (depending on your priority choices earlier on) inserted blocks might go away as well. I wouldn't want this to happen too often. So the right answer is the above recommendation _PLUS_ any gigabytes of storage that you can spare. And spare is the problem. I can easily spare 20 or 40 gigabytes, but 100 or 200 is somewhat trickier. I might have that kind of space now, and be willing to give it to GNUnet, but i might want that space back at some point. Not sure what GNUnet will do right now, if i shut down my node, reduce the datastore size, then start the node up again. Probably discard lowest-priority blocks until datastore shrinks to the new limit? Now, having a minimum space allocated to the datastore, and then just using N% of the remaining free disk space for for datastore too, while it's available - that really makes the decision easier. If GNUnet is then taught to use pre-allocated datastore for important blocks (files being downloaded or published; what are privacy issues here?), that would mean that your node will serve _your_ interests first, and will use the free space available to serve the network as best as it can. It should maintain either F% of space free, or G gigabytes (whichever is larger). Obviously, F and G are configurable (i.d say - default F to 20, and G to 20; unless GNUnet daemon that would reclaim free space would be a slowpoke, 20 gigabytes should give it enough time to react). It should also be completely disabled for SSDs, IMO. Because they are small to begin with, _and_ because their performance degrades greatly as they are filled with data. Thus the idea is the same as with CPU resources - you set up low and high thresholds for CPU load that GNUnet can cause. It will go as high as the high threshold when uncontested, and will go down to the low threshold when other processes compete for CPU resources with GNUnet. Same for storage - use large portion of available free space for datastore (primarily - for migrated and cached blocks), but be ready to discard all that, and go as low as the size of the pre-allocated datastore. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJQwZwTAAoJEOs4Jb6SI2CwdnAIAKd8G+z2v0jcD68PpF0jGvaD
[GNUnet-developers] Camouflage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is the idea that i've been thinking on. It should be possible for GNUnet node operator to hide the fact that his machine runs a GNUnet node. Ways to achieve this: 1) Fake HELLO messages. AFAIU, right now anyone can collect HELLO messages (by running a node, or by querying a hostlist server), and then claim (with certain degree of sureness) that GNUnet nodes run on all addresses listed in these messages. Companies that track torrent users do this for BitTorrent. They may then proceed to actually connect to listed addresses to verify them, but that is quite another story. The solution is to spread fake HELLOs with fake public keys and fake addresses. A node should use its private key (key K) as a seed to generate a set fake of addresses (set A). Then use K and A themselves to generate fake public key (key F) for each A, thus getting a complete HELLO message. The use of K as a seed ensures that the node will keep lying about the same set of addresses (how large that set should be is an open question) with the same keys, making the fakes more believable (observer might think that these are real nodes, maintaining their real HELLOs over time; failure to validate any of them might be blamed on firewalls, etc). Address sets will intersect (A1 and A2 generated from K1 and K2 may share some elements), obviously, although that might not be true for IPv6 addresses... I expect that address generator will apply some rules to generate believable addresses (i.e. don't generate invalid IP addresses, like 10.1.0.255). As an extra, a node could validate generated addresses and do non-agressive portscanning (or something similar - we're not speaking only of tcp) on them, to be able to add ports (or other parts of the address) that look believable to observers. AFAIU, right now nodes won't gossip about fake HELLOs (i.e. a node will never tell another node about a HELLO it got, unless it validated that HELLO). That might need to be changed to allow nodes to choose a random subset of invalid HELLOs and gossip about them as well. Otherwise only the node that generated them will be able to spread them. Not sure about hostlists. Extra yummy feature - add user-configurable fake templates, which could have addresses only, or addresses and private keys. GNUnet node will use templates from time to time (configurable) instead of generated addresses, and will generate missing template elements. It would be neat to be able to tell the world that 65.55.58.201 [1] runs a GNUnet http_server transport on port 80... 2) Transport disguise. Modify the protocol to allow clients to ignore initial data sent by the server, and require clients to be the first ones to speak GNUnet protocol after connecting (i'm not sure how the protocol works right now; what a GNUnet node sends to the connected party immediately after accepting an incoming connection? Does it send anything at all?). A node should send fake data that looks like, say, FTP greeting, faking a real-life FTP server. This will prevent casual observers from identifying the node as GNUnet node. Non-casual observer should not follow the fake protocol, but proceed to send a normal GNUnet handshake. If the node doesn't get a GNUnet handshake as a reply to its fake greeting, it might either drop the connection, or use some kind of bogus access control error as an excuse to drop it (i.e. ask for ftp login/password combo, and then reject all such combos and drop clients that failed to authenticate this way). Or a node should simply remain silent until it gets incoming handshake message. 3) Handshake-first protocol Besides (2), which may or may not be implemented, don't identify yourself as GNUnet node until incoming peer sends a handshake, then drop it, if it doesn't match one of your friends, if you're running in F2F-only mode. You will be able to hide the fact that you're a GNUnet node, since only friends will get _anything_ out of you. Other non-friend (normal or malicious) GNUnet clients will have their connections dropped after their handshake message. To make it work both ways, GNUnet should establish a generic session with TLS encryption first. Again, it's not uncommon for services to have ports on which clients are expected to connect with an SSL/TLS session (instead of connecting normally and then issuing StartTLS). The point here is to use common TLS certificates and TLS connections for initial authentication (friend nodes will know TLS certificates of each other in advance). Otherwise your node will not be able to connect to any of your friends without revealing that it's a GNUnet node (friend won't identify itself as a GNUnet node initially, until you send a handshake, thus preventing you from verifying that you've connected to your friend, not to some man in the middle; and if you send a GNUnet handshake, you will reveal yourself as GNUnet node to the other end of the connection, not knowing who might be there). TLS allows
Re: [GNUnet-developers] Propose new feature - Search Indexer WebService for GNUnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09.11.2012 21:32, SMoratinos wrote: I think the second part of my previous mail was misunderstood (probably because of my english). I propose a third idea. The first idea was central server = bad The second was 3 entity, a downloader, a uploader, and a database maintainer = too many problems (cf LRN previous mail). The third is database link indexer is a new service in gnunet. There is only one entity, a gnunet user, each gnunet user have a database. The new service could be built on top of file-sharing, or not (i don't know). This is not a fs replacement but an extension or an alternative. Possible features : - gnunet-search-db : search in the local database. - gnunet-notifier-db : notify user that new content, only uri with metadata (like CHK) not the document, is arrived from the network. - gnunet-indexer-db : a process which accept new entry from network and put them in his database. A process wich send new entry to the network. Wwhat is this information which are store in the database. It's like KBlock but with a all know K (i call it PBlock). For example K=gnunet_public by convention. All uploader who want that a publication became indexes by this new service must publish the content with keyword gnunet_public. When an uploader publish content under the K=gnunet_public, then gnunet-indexer-db send a PBlock to the network. The PBlock will be propagated over the network. If the Key is know by all, so intermediaries could view metadata and uri, and that's what we want. Am I right ? Is it a problem ? That would be easily censorable _and_ nodes will not have plausible deniability (i don't know what i was routing) - anyone will be able to see contents of these P-blocks, and thus it will be possible for some parties to demand of nodes to do some kind of content-based filtering (i.e. drop all P-blocks that have a word X in filename or as one the other metadata items). I doubt that Grothoff will like this suggestion. About the size of the database. I have no idea of that size. In the documentation, i have understood that KBlock are appromatively 1% of the content. If I have in my database 1 PBlock who reference 1 files with an average size of 1Go. The content of my database will be 100Go, it's too huge. But this is not a problem if we keep PBlock only for a few period. For example only which are 10days old. Because I actually want the fresh result not the old. And I want notification not actually store all gnunet network ! If I want old content I can search via normal gnunet-fs-search. And guys who want store more historic can, if they want. K-blocks can have any size up to 64k, their size does not depends on size of the files they link to. If you keep them small, their database impact will be less. The problem with them is usually that you have more than one (much more than one). With your proposal there will be [mostly] only one P-block per file, so that's totally not a problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQnZABAAoJEOs4Jb6SI2CwPI8IAJbCOFqj3m7LeflQslBz/oMJ 9o+3M7XU80e3QtilttuYcj9yfoNJDe0PpCO2CNkuy3ubOFzgnMVLyTUMBEi7eL4N 7BZqs6zl8rRZ5LzS2wa0ZTFG377swgDfSvid/+7fwWAjGzFEcrPLL5mCl24sLMmi JedQHVnmufIRmv3aCzo44w58hPKfu0kIjUomxxYf0V3c4qoILVZMCXxuCIeq+2l3 yYMoK4+fqAzQh6op4bVb7EoUnKYXqU9DVvK/wQigBrGhV2gj8y13klAHviC11wHw 89pjwnDPJwLAGchVPzbThtgA+Me1QIB8et4md0nSZ1r2isJXlGjwEwUVLFfCDeA= =9cVa -END PGP SIGNATURE- ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] Propose new feature - Search Indexer WebService for GNUnet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08.11.2012 17:37, SMoratinos wrote: So what about that ? Well, i really can't continue to discuss it, until i have clear understanding of how namespace publications work, and how namespace searches do, and how they will once namespace search unification is implemented. Specifically, what a node (or a user) must know in order to search in a namespace. Also, how reverse publications (encrypted with other namepaces' public key) will work. /me gives Grothoff a meaningful look. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQm9PnAAoJEOs4Jb6SI2CwxSoH/0fq4VNWZgEgdth4KBZ1k51j 4AIuq4Ga+L904xQaJXZfbcR1sToV76x/eDG37V7GwNe1dpBz1JY8bhLAkTbzT9Gv XUlPEqp2w2hcyYympXc5/IQNextuIcwyssu1IWe3ymtvYBYZ7z1W+crcFWFoPhq+ AyedxKetLVn8HH5ThGV0RN53wN01J/ViaWfq4LqSNV2Uvf/5CWpQCe0u/QrCMc24 jXYQhMwQ+mI8GrVzO2OZ2iE9Lycq1v1yU91N9Kr8R3bXYKOE6AiyfZ6KoSeXBPGn n9/rDccRKph1tJy2F43wXgAUviUPgcVVFGWfHiInxAYNt2cfwDtppIaaOvmN/9I= =Y9gz -END PGP SIGNATURE- ___ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
Re: [GNUnet-developers] Propose new feature - Search Indexer WebService for GNUnet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08.11.2012 17:37, SMoratinos wrote:
3 / The Uploader publish things encrypted by namespace a1 public
key, it publish thinks to goodfiles namespace.
We'd have to avoid that, see below.
4 / The namespace owner a1 will continuously search for
publications for namespace a1. This suppose to be the default
functionning of gnunet, a namespace search content for his own
namespace. He find the new content and index only it's link to him
database.
Your wording is quite unfortunate. I know what you mean publications
intended for inclusion in a1, not publications made in a1, because
only a1's owner can publish in a1. Searching your own namespace makes
no sense - only you can publish things in it anyway. And if you do
share its private key, then it is just the same as the global namespace.
But how the downloader discover the a1 namespace ? The problem is
the same as the beginning.
Off-band. How do you know about TPB? You learn eventually, somehow.
Maybe google for it. Sadly, unless database contents are published on
a public web-site, they won't be googleable (and you won't be able to
discover database's existence initially by finding its contents), and
publishing them like that will attract attention, censorship, and may
threaten publisher's anonymity (OTOH, publisher may not be the same
entity as the database maintainer; still, who'd want to put himself in
danger like that? On a regular basis?)
If there is no central server, the link index database must be in
all the network.
Yes, each user who regularly uses the database will maintain his own
copy (a closed community of users may opt to share one copy, but that
is their business).
All peers are a Database Owner, all the peer on the network have a
copy of the Link Index Database.
No, only one node (or group of collaborating nodes) is the owner, able
to publish updated database in a1 namespace.
When a database is updated, this update is propagated over the
network.
Yes, since everyone will [eventually] get a copy. For the purpose of
efficiency database won't be monolithic, so you'd only need to
downloads a couple of megabytes to update existing copy.
Search became local ! This is no longer the search result which is
propagated but this is the Link Index Database.
Yes, although your local database will always be somewhat older than
the one database maintainer has (depending on how often you're able to
update it).
Finally, I'm notified by all the network from updates. New
contents are indexes by all the network continuously.
Yes, but GNUnet kind of does that already. Database is only different
in that it's moderated and allows discovering new stuff without
foreknowledge.
The drawback is that all peers must persit this database, and have
enough disk space but few Gbits is not a problem ?
Yes (also, see above about database sharing).
And yes Gnunet doesn't work like this now.
Yes. Some things are pending features (DSA, always-namespace
searches), others are yet-to-be designed (basically what this
discussion is).
So what about that ?
OK, i took some time to actually read [1] instead of just glancing
over the points.
Normal (global) search is like this (based on GHM 2010 talk):
K-block for keyword K contains payload R (payload is CHK and metadata).
H(K) is the hash of the keyword.
R is encrypted with a symmetric key derived from H(K), i.e. encrypted
payload is E_{H(K)} (R).
K is used to generate an RSA private/public key pair {PRIV_K, PUB_K}.
Publisher then appends PUB_K to E_{H(K)} (R), and signs all that with
PRIV_K to produce B, which is the K-block.
B can be produced by anyone, you only need to know the keyword.
Query initiator goes through the same thing - computes {PRIV_K,
PUB_K}, then produces hash of the public key H(PUB_K) and sends it as
a query.
Also anyone, who somehow gets a K-block, can check its signature
(verify that E_{H(K)} (R) + PUB_K was signed with PRIV_K, you only
need PUB_K itself for that).
Anyone, who has the K-block, can take the PUB_K part of it and hash
that, producing the same H(PUB_K), and remember that hash, then match
incoming queries against it. If it matches, then query initiator asked
for the corresponding K-block.
Since that stuff only depends on K, attackers can pre-compute PUB_K
and H(PUB_K) for any K's that they want to censor/monitor, but the
worst thing they can do is to refuse to re-transmit a query for K they
know. Or send valid K-blocks with garbage payload (yeah, that's
actually worse than dropping queries). But that is where namespaces
come in.
Now, what [1] proposes:
All K-blocks are published under _some_ namespace. The corner case is
the global namespace, private key for which is not a secret, so anyone
can share in that namespace.
PUB_N is the public key of a namespace, PRIV_N is the private key of a
namespace.
H(K+PUB_N) is the hash of the combination of keyword K and public key
of the namespace (as opposed to
