headers
jan marco alkema | 7 Dec 2003 17:17
Picon
Favicon

ripe-md160/HashCode160/CRC/MD5

Hello Christian,

I have downloaded 2 different Ripemd160 source code distributions and 1 crc
source code program.

I can't match the ripe-md160/crc with the gnunet "GNUNET_URI" for
marije_004.jpg

Christian, Maybe I do something wrong?

Greetings Jan Marco

Appendix Hashes:

RipeMD160(marije_004.jpg): bfd5d02dd853ad075e5413f0616bf1ee0c0af113

MD5(marije_004.jpg): E5D0CC3887595816D48D983D0DC341AD

CRC(marije_004.jpg): 68ce0184

FileSize(marije_004.jpg): 33736

# ./gnunet-insert --key=mary4 /home/janmarco/marije_004.jpg
Inserting marije_004.jpg (no description supplied, unknown) under keyword
mary4.
# ./gnunet-search mary4
gnunet-download -o "marije_004.jpg" --
gnunet://afs/3CC486373A389B854F26710EAD6F9D70327CF93E.37EDB64A937600C1854858
A8A9131B53BC64EEFA.60713D60.33736
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christian Grothoff | 7 Dec 2003 22:58
Picon
Favicon

Re: ripe-md160/HashCode160/CRC/MD5


On Sunday 07 December 2003 11:17 am, jan marco alkema wrote:
> Hello Christian,
>
> I have downloaded 2 different Ripemd160 source code distributions and 1 crc
> source code program.
>
> I can't match the ripe-md160/crc with the gnunet "GNUNET_URI" for
> marije_004.jpg
>
> Christian, Maybe I do something wrong?

No, the GNUnet URL for a file has nothing (!) to do with the direct 
ripe/crc32/md5 hash of that file.  Read 
http://www.ovmj.org/GNUnet/download/ecrs.ps for the details of the GNUnet 
encoding.  The summary is, that taking the hash of the entire file means that 
you can only verify the integrity of the entire file, not of individual parts 
of the file.  Since we want to be able to securely retrieve parts of the file 
from different, possibly malicious peers, we need to be able to verify the 
file-integrity on a more fine-grained level, which is what ECRS (previously 
called ESED2) allows us to do.

Christian

> Greetings Jan Marco
>
> Appendix Hashes:
>
> RipeMD160(marije_004.jpg): bfd5d02dd853ad075e5413f0616bf1ee0c0af113
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Grothoff | 8 Dec 2003 20:13
Picon
Favicon

Re: Re: [Help-gnunet] trouble with cvs


I was able to reproduce this and I believe it should now be fixed in CVS (by 
re-libtoolizing with libtool 1.5 which is now back on the GNU ftp server).

Christian

On Saturday 15 November 2003 09:36 pm, Marcos D. Marado Torres wrote:
> On Fri, 7 Nov 2003, N. Durner wrote:
> > > ltdl.c:2174: warning: `struct direct' declared inside parameter list
> >
> > [...]
> >
> > > What now? O:-)
> >
> > What version of libtool are you using?
> > If it is < 1.5, please try to update to 1.5.
>
> I updated it:
> # libtool --version
> ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: 49
> $
>
> but the problem is still there:
> # make
> [...]
> gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c ltdl.c  -fPIC -DPIC -o
> .libs/ltdl.lo ltdl.c:2174: warning: `struct direct' declared inside
> parameter list ltdl.c:2174: warning: its scope is only this definition or
> declaration, which is probably not what you want ltdl.c: In function
> `lt_argz_insertdir':
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Grothoff | 9 Dec 2003 22:25
Picon
Favicon

Re: Re: [Help-gnunet] trouble with cvs


On Friday 07 November 2003 05:57 pm, Igor Wronsky wrote:
> Btw, in insertContent(), whats this supposed to achieve,
>
>   if ( ( sender != NULL) &&
>        ( randomi(2 + importance) == 0) ) {
>     return SYSERR; /* don't bother... */
>   }
>
> ? Yes, I can read what it does. Whats the reasoning?

Ok, let me recap what it does first (since it is out-of-context...).

If we're not processing content originating from the local user (sender != 
NULL) and the content has been decided to be of low value, we 
probabilistically do not even bother going to the database to see if we have 
space to store it.

Reasoning: processing the database (find lowest-priority content or find that 
we have enough space, do the insertion, etc) costs us many disk-accesses.  If 
the content additionally has a rather low priority, it is likely that this 
whole process will fail (lowest-priority content has higher or equal priority 
to new content).  So we just don't do it all the time.  Which also makes it 
slightly harder to predict whether or not a given peer will cache content 
floating by.  Now, the exact formula (2+importance) comes from that even 
importance == 0 should have a chance to be added to the local DB.

Christian
Permalink | Reply | 0 comments |
headers
Tom Barnes-Lawrence | 10 Dec 2003 06:15
Favicon

gnunet-gtk crashes (was Re: [Help-gnunet] Questions on latest version)

Long, long ago, in a galaxy not so far away,
On Wed, Sep 03, 2003 at 01:54:32PM -0500, Christian Grothoff wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1024 (LWP 799)]
> > 0x08055d08 in _IO_stdin_used ()
> > (gdb) ba
> > #0  0x08055d08 in _IO_stdin_used ()
> > #1  0x08055d03 in _IO_stdin_used ()
> > #2  0x00000000 in ?? ()
> >
> > after trying to start a download. I forget what caused the segfault a few
> > days ago, but in the past it's generally been from simply starting
> > searches. Whether it's been for unusual keywords or common keywords or
> > second searches or first searches, or what, has *never* been clear to me.
> 
> That trace doesn't really say anything (stack trace is garbage).  Could be 
> pthreads (glibc-version?), could be anything.  What platform are you using? 
> If it is Linux/x86, I'd suggest starting gnunet-gtk with valgrind (x86 memory 
> debugger), that may tell us which component is to blame. Yes, it will be slow 
> - -- on a P4 performance is acceptable.  Do other GTK applications run nicely?

 Right, well after to-ing and fro-ing across the country a fair bit, and
trying to get together some more content for GNUnet, I've finally gotten
around to trying just that. I think I'd heard of Valgrind before, but
never actually tried it. NB- I'm still running V0.6.0a rather than CVS.

 Well, as it was running, it said:
(snip)
==1219== Estimated CPU clock rate is 451 MHz
==1219== For more details, rerun with: -v
(Continue reading)

Permalink | Reply | 6 comments |
headers
Christian Grothoff | 10 Dec 2003 07:35
Picon
Favicon

Hint: configuration file changes (in CVS)

In order to properly address bug #609, I've had to change a bit the way GNUnet 
is configured.  The existing 'gnunet.conf' file has been split into two 
files, one for the configuration of gnunetd (resource limits, transports, 
modules) and one for the configuration of the user-level tools (gnunet-gtk, 
gnunet-tracekit, gnunet-chat).

gnunetd now expects its configuration by default in /etc/gnunet.conf (template 
is in contrib/gnunet.root). 

The tools expect their configuration in ~/.gnunet/gnunet.conf (template is in 
contrib/gnunet.user).  

Christian
Permalink | Reply | 0 comments |
headers
Christian Grothoff | 12 Dec 2003 00:16
Picon
Favicon

Re: gnunet-gtk crashes (was Re: [Help-gnunet] Questions on latest version)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me start with some important hint with respect to gdb.  The latest gdb 
(6.0) reliably produces broken stacktraces for me.  Switching to an earlier 
version (5.x) solved the problem.  So if your stacktrace contains a ton of 
"??" lines, I recommend trying with another gdb version.

On Wednesday 10 December 2003 12:15 am, Tom Barnes-Lawrence wrote:
> Long, long ago, in a galaxy not so far away,
>
> On Wed, Sep 03, 2003 at 01:54:32PM -0500, Christian Grothoff wrote:
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 1024 (LWP 799)]
> > > 0x08055d08 in _IO_stdin_used ()
> > > (gdb) ba
> > > #0  0x08055d08 in _IO_stdin_used ()
> > > #1  0x08055d03 in _IO_stdin_used ()
> > > #2  0x00000000 in ?? ()
> > >
> > > after trying to start a download. I forget what caused the segfault a
> > > few days ago, but in the past it's generally been from simply starting
> > > searches. Whether it's been for unusual keywords or common keywords or
> > > second searches or first searches, or what, has *never* been clear to
> > > me.
> >
> > That trace doesn't really say anything (stack trace is garbage).  Could
> > be pthreads (glibc-version?), could be anything.  What platform are you
> > using? If it is Linux/x86, I'd suggest starting gnunet-gtk with valgrind
(Continue reading)

Permalink | Reply | 5 comments |
headers
Tom Barnes-Lawrence | 12 Dec 2003 06:08
Favicon

Re: gnunet-gtk crashes

On Thu, Dec 11, 2003 at 06:16:35PM -0500, Christian Grothoff wrote:
> Let me start with some important hint with respect to gdb.  The latest gdb 
> (6.0) reliably produces broken stacktraces for me.  Switching to an earlier 
> version (5.x) solved the problem.  So if your stacktrace contains a ton of 
> "??" lines, I recommend trying with another gdb version.

Hmm, well I used to have troubles using GDB with gnunet-gtk (and
some other programs, possibly gnunetd). IIRC it was to do with threads.
Then I upgraded a couple of months back, and it was much better.
But the version I upgraded to (being on Debian/Stable) was 5.2.cvs,
not 6.anything. I don't really remember other programs getting
these ??s anywhere.

I'm not discounting the idea, I just don't want to play "blindly hunt
the version of GDB that gets it right", if you see what I mean.

> On Wednesday 10 December 2003 12:15 am, Tom Barnes-Lawrence wrote:
> >
> >  Right, well after to-ing and fro-ing across the country a fair bit, and
> > trying to get together some more content for GNUnet, I've finally gotten
> > around to trying just that. I think I'd heard of Valgrind before, but
> > never actually tried it. NB- I'm still running V0.6.0a rather than CVS.
> 
> Well, there are fixes for various minor and some major bugs in CVS.

mneh, I suppose that must be true, but I still generally avoid using CVS.
Remind me, the current CVS version now uses 2 separate config files, does
it have other changes, eg to the directory heirarchy, data formats,etc
that I'd need to know about first?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tom Barnes-Lawrence | 12 Dec 2003 07:22
Favicon

Namespace discovery+navigation

I felt like starting another discussion on informal protocols and
such things:

Since the namespaces thing finally got into GNUnet, I've been interested
to actually see some reference to someone's namespace. But I never have.
I've found a couple of directories, which was nice and interesting, but
still no namespaces.

 From my discussion a few months back with Christian, and from reading
the new ECRS paper a couple of days ago, I understand that the only
ways you can actually *get* a namespace key, is:

-By some out-of-band means
-Be the one who creates it (really counts as the previous method)
-Find it referenced in a directory
-OK, also have some plain-text file or something shared across GNUnet,
 which is more or less equivalent to the directory method but a bit
 stupid really)

So, to try the only real in-band way of finding a namespace, I tried
doing a search for "directory". Found some directories, but no
namespaces. Perhaps there are none yet. But that's not important.

Point is, as the main way of using GNUnet will probably involve the
namespaces (so you can largely stick to content you can reasonably
trust not to be spam), people will need some reliableish way to
get access to a decent number of namespaces.

My first informal-protocol proposal:
Choose some key that people can advertise their own namespaces on.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Grothoff | 13 Dec 2003 00:42
Picon
Favicon

Re: Namespace discovery+navigation


On Friday 12 December 2003 01:22 am, Tom Barnes-Lawrence wrote:
> I felt like starting another discussion on informal protocols and
> such things:
>
> Since the namespaces thing finally got into GNUnet, I've been interested
> to actually see some reference to someone's namespace. But I never have.
> I've found a couple of directories, which was nice and interesting, but
> still no namespaces.
>
>  From my discussion a few months back with Christian, and from reading
> the new ECRS paper a couple of days ago, I understand that the only
> ways you can actually *get* a namespace key, is:
>
> -By some out-of-band means
> -Be the one who creates it (really counts as the previous method)
> -Find it referenced in a directory
> -OK, also have some plain-text file or something shared across GNUnet,
>  which is more or less equivalent to the directory method but a bit
>  stupid really)

Right.  There is one other possibility: gnunetd can 'snoop' namespaces by 
seeing a namespace reply pass by.  gnunetd can then 'learn' the namespace, 
but it would of course still not know any contents in it.  And it is only a 
passive approach in that it requires any of the above -- snooping can not 
occur unless someone *else* requests something in that namespace.  Note that 
snooping will only reveil the existence and ID of a namespace but not the 
contents that were transferred.

> So, to try the only real in-band way of finding a namespace, I tried
(Continue reading)

Permalink | Reply | 0 comments |

Gmane