View Issue Details

IDProjectCategoryView StatusLast Update
0003559gnunet-gtkgnunet-peerinfo-gtkpublic2018-06-07 00:25
ReporterellAssigned ToChristian Grothoff 
PriorityurgentSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
PlatformOSXubuntu-14.04-64amdOS Version
Product VersionSVN HEAD 
Target Version0.11.0pre66Fixed in Version0.11.0pre66 
Summary0003559: Revision 34405, peerinfo by gnunet-gtk differs from gnunet-peerinfo
DescriptionUsing the account "gnunet" I get

gnunet@Xubu-14:~$ gnunet-peerinfo -s
I am peer `668DM7TYCG4E1JXQM1KQACHQSRG9CBBV1Y03A0QFV5SWPTHKCDPG'.

Running in the useraccount I get
ell@Xubu-14:~/gnunet$ gnunet-peerinfo -s
I am peer `ABY7AB0QYXE6KCM64YY0V5JKXYBF36GH6GTHTR344A0HZTVZQ0R0'.

But running gnunet-gtk in the useraccount shows
64TF
and not the expected ABY7 or 668D.

Is this quit normal or is it a bug?
TagsNo tags attached.

Activities

Christian Grothoff

2014-11-17 09:20

manager   ~0008625

Where are you looking in gnunet-gtk? Note that this is definitively already an issue because user and gnunet-account should not disagree like that (I have an idea as to why this happens). But with respect to gnunet-gtk, I suspect you might be looking at the wrong key. Could you please attach a screenshot?

ell

2014-11-17 10:12

reporter  

Christian Grothoff

2014-11-21 14:15

manager   ~0008626

Ok, you're certainly right that those 3 should _all_ be identical. However, I cannot reproduce this here. So I have two questions:

What does

$ gnunet-config -s peerinfo

show? (as either user). Also, what do you get for

$ ps ax | grep gnunet-service-peerinfo

You should get only one process, if not, that might also be a hint (peer started multiple times with multiple configurations?).

ell

2014-11-21 17:23

reporter   ~0008627

Beginning with no gnunet-processes running I will do my very best:

First I started gnunet-arm in account gnunet and get:
gnunet@Xubu-14:~$ ps ax | grep gnunet
 6174 pts/14 S 0:00 sudo su - gnunet
 6175 pts/14 S 0:00 su - gnunet
 6730 pts/14 S+ 0:00 grep gnunet
gnunet@Xubu-14:~$
gnunet@Xubu-14:~$ gnunet-arm -c /etc/gnunet.conf -s
gnunet@Xubu-14:~$ Nov 21 16:45:09-994254 peerinfo-6744 ERROR Assertion failed at gnunet-service-peerinfo.c:607.
Nov 21 16:45:09-994405 peerinfo-6744 ERROR Assertion failed at gnunet-service-peerinfo.c:607.

As second step I started gnunet-arm in user-account ell and get:
ell@Xubu-14:~$ gnunet-arm -c ~/.config/gnunet.conf -s
ell@Xubu-14:~$

Third step is starting gnunet-gtk in useraccount ell:
ell@Xubu-14:~$ gnunet-gtk

Meanwhile I got some warnings and errors in the gnunet-account pasted in here:
gnunet@Xubu-14:~$ gnunet-arm -c /etc/gnunet.conf -s
gnunet@Xubu-14:~$ Nov 21 16:45:09-994254 peerinfo-6744 ERROR Assertion failed at gnunet-service-peerinfo.c:607.
Nov 21 16:45:09-994405 peerinfo-6744 ERROR Assertion failed at gnunet-service-peerinfo.c:607.
Nov 21 16:50:24-051331 cadet-6739 WARNING External protocol violation detected at gnunet-service-cadet_channel.c:1977.
Nov 21 16:50:24-051859 cadet-chn-6739 WARNING MID 0 on channel ES98:19 gid:0 (0 / B0000000) not expected (window: 1 - 64). Dropping!
Nov 21 16:52:23-268221 cadet-6739 WARNING External protocol violation detected at gnunet-service-cadet_channel.c:1977.
Nov 21 16:52:23-276378 cadet-chn-6739 WARNING MID 0 on channel P00P:19 gid:40000000 (80000000 / 0) not expected (window: 1 - 64). Dropping!
Nov 21 16:52:27-017817 cadet-6739 WARNING External protocol violation detected at gnunet-service-cadet_channel.c:1977.
Nov 21 16:52:27-017947 cadet-chn-6739 WARNING MID 0 on channel P00P:19 gid:40000000 (80000000 / 0) not expected (window: 1 - 64). Dropping!
Nov 21 16:54:40-118623 transport-6742 ERROR Trying to transmit ACK to peer `50.131.189.92:2086' but not session found!
Nov 21 16:55:08-623433 transport-6742 ERROR Trying to set unknown address to unused for peer `ES98', plugin `tcp', session 0x7f840c92ed20
Nov 21 16:55:08-623751 transport-6742 ERROR Assertion failed at ats_api_scheduling.c:1397.
Nov 21 16:57:04-059968 transport-6742 ERROR Trying to transmit ACK to peer `50.131.189.92:2086' but not session found!

Now I get in the gnunet-account:
gnunet@Xubu-14:~$ gnunet-config -s peerinfo
USE_INCLUDED_HELLOS = YES
NO_IO = NO
HOSTS = $GNUNET_DATA_HOME/peerinfo/hosts/
UNIX_MATCH_GID = YES
UNIX_MATCH_UID = NO
UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-peerinfo.sock
ACCEPT_FROM6 = ::1;
ACCEPT_FROM = 127.0.0.1;
BINARY = gnunet-service-peerinfo
HOSTNAME = localhost
AUTOSTART = YES
gnunet@Xubu-14:~$

and in the user-account ell:
ell@Xubu-14:~$ gnunet-config -s peerinfo
USE_INCLUDED_HELLOS = YES
NO_IO = NO
HOSTS = $GNUNET_DATA_HOME/peerinfo/hosts/
UNIX_MATCH_GID = YES
UNIX_MATCH_UID = NO
UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-peerinfo.sock
ACCEPT_FROM6 = ::1;
ACCEPT_FROM = 127.0.0.1;
BINARY = gnunet-service-peerinfo
HOSTNAME = localhost
AUTOSTART = YES
ell@Xubu-14:~$


Looking for processes in account gnunet gives:
gnunet@Xubu-14:~$ ps ax | grep gnunet-service-peerinfo
 6744 ? S 0:00 /usr/local/lib//gnunet/libexec/gnunet-service-peerinfo -c /etc/gnunet.conf
 7499 pts/0 S+ 0:00 grep gnunet-service-peerinfo
gnunet@Xubu-14:~$

and looking for processes in user-account ell gives:
ell@Xubu-14:~$ ps ax | grep gnunet-service-peerinfo
 6744 ? S 0:00 /usr/local/lib//gnunet/libexec/gnunet-service-peerinfo -c /etc/gnunet.conf
 7578 pts/0 S+ 0:00 grep --color=auto gnunet-service-peerinfo
ell@Xubu-14:~$
well, seems to exist only one process.

The already mentioned peer "ABY7AB0QYXE6KCM64YY0V5JKXYBF36GH6GTHTR344A0HZTVZQ0R0"
I can see in the gnunet-gtk phone-tab preceeded with "1-"

Christian Grothoff

2014-11-24 11:47

manager   ~0008629

ell: note that I've seen this, but so far I'm just puzzled -- and I cannot reproduce it (yet).

Christian Grothoff

2014-12-14 13:42

manager   ~0008684

Ok, got it reproduced now.

Christian Grothoff

2014-12-14 14:30

manager   ~0008685

Ok, I understand the problem now, just not sure what a good answer is. Goes back to how to best manage the private key of the peer. We need to expose the private key to certain system components running under the user's account (gnunet-peerinfo is kind of just the canary in the coal mine here, especially as it only needs the public key but uses the private key to compute the public key), and currently they don't have a way to get it (as it is cordoned off at the gnunet-system user). So what they do is make up a new one, which is then different from the one they should be using. However, exposing a generic 'hand-over-private-key' API to users (while convenient) seems wrong from a security perspective.

Christian Grothoff

2014-12-14 21:53

manager   ~0008686

SVN 34554 should fix the delta between the two 'gnunet-peerinfo -s' commands. I was unable to reproduce gnunet-peerinfo-gtk disagreeing with the two. There is also a similar issue with LOC signing in FS, which is why I leave the bug open regardless at this point.

Christian Grothoff

2014-12-14 23:16

manager   ~0008688

SVN 34563 fixes the related issue in FS.

Issue History

Date Modified Username Field Change
2014-11-16 12:34 ell New Issue
2014-11-17 09:20 Christian Grothoff Note Added: 0008625
2014-11-17 09:20 Christian Grothoff Assigned To => Christian Grothoff
2014-11-17 09:20 Christian Grothoff Status new => assigned
2014-11-17 09:21 Christian Grothoff Product Version => SVN HEAD
2014-11-17 09:21 Christian Grothoff Target Version => 0.11.0pre66
2014-11-17 10:12 ell File Added: Screenshot - 17.11.2014 - 10:07:48.png
2014-11-21 14:15 Christian Grothoff Note Added: 0008626
2014-11-21 17:23 ell Note Added: 0008627
2014-11-24 11:47 Christian Grothoff Note Added: 0008629
2014-12-12 01:22 Christian Grothoff Priority normal => high
2014-12-14 13:42 Christian Grothoff Note Added: 0008684
2014-12-14 14:30 Christian Grothoff Note Added: 0008685
2014-12-14 15:19 Christian Grothoff Priority high => urgent
2014-12-14 21:53 Christian Grothoff Note Added: 0008686
2014-12-14 23:16 Christian Grothoff Note Added: 0008688
2014-12-14 23:16 Christian Grothoff Status assigned => resolved
2014-12-14 23:16 Christian Grothoff Fixed in Version => 0.11.0pre66
2014-12-14 23:16 Christian Grothoff Resolution open => fixed
2018-06-07 00:25 Christian Grothoff Status resolved => closed