View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003559 | gnunet-gtk | gnunet-peerinfo-gtk | public | 2014-11-16 12:34 | 2018-06-07 00:25 |
Reporter | ell | Assigned To | Christian Grothoff | ||
Priority | urgent | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
OS | Xubuntu-14.04-64amd | ||||
Product Version | Git master | ||||
Target Version | 0.11.0pre66 | Fixed in Version | 0.11.0pre66 | ||
Summary | 0003559: Revision 34405, peerinfo by gnunet-gtk differs from gnunet-peerinfo | ||||
Description | Using 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? | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
|
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? |
|
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?). |
|
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-" |
|
ell: note that I've seen this, but so far I'm just puzzled -- and I cannot reproduce it (yet). |
|
Ok, got it reproduced now. |
|
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. |
|
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. |
|
SVN 34563 fixes the related issue in FS. |
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 | => Git master |
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 |