View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002856 | GNUnet | obsolete | public | 2013-04-05 13:57 | 2024-05-03 12:02 |
| Reporter | Matthias Wachs | Assigned To | Matthias Wachs | Due Date | |
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.10.0 | Fixed in Version | 0.10.0 | ||
| Summary | 0002856: Handling of Friend-only HELLO messages | ||||
| Description | With 0002676 we introduced a F2F mode for HELLO messages. Peerinfo supports this mode, but there are issues to be discussed regarding peerinfo service handling of HELLO messages. | ||||
| Tags | No tags attached. | ||||
| Changing from public -> f2f: when a peer does that, it changes it's HELLO to FRIEND-HELLO When it now changes back to public mode, it creates a new HELLO, that will be atm merged with the FRIEND-HELLO what results in a FRIEND-HELLO gnunet-peerinfo-service.c: 520 | |
| Leaking host ids: The friend-only flag is included in the HELLO message itself But peerinfo service can have a peerid without a HELLO. If this id was created in F2F it's possible that it's leaked | |
| Peerinfo service handles own's HELLO in the same way as other peer's HELLO A peer's own HELLO is not added with all the other's peer in the same hashmap under the peer's id and query it by using it own peer id | |
| Discussion: peerinfo service uses a: struct HostEntry { /** * Identity of the peer. */ struct GNUNET_PeerIdentity identity; /** * Hello for the peer (can be NULL) */ struct GNUNET_HELLO_Message *hello; }; Should we store both a private and a public HELLO in the struct? How do we handle the peer id as public/friend only itself? | |
| PeerIdentity's themselves don't have to be secret, they're pretty meaningless to anyone. I think extending the 'struct HostEntry' with a third member for the friend-hello should be fine. | |
| When leaking ids is not a problem that's fine for me. Implementation idea: struct HostEntry { struct GNUNET_PeerIdentity identity; struct GNUNET_HELLO_Message *hello; struct GNUNET_HELLO_Message *friend_hello; } Discussion: When client asks for friend hello and we have both public and friend: - Do merge them? (IMHO yes) When a client asks for a friend and we have a public do we return it? IMHO yes to both questions since the include_friend flag in peerinfo api semantically means: "Do you public only or in addition friend only info?" How do we serialize them to disc? ATM hellos are written to disc using peer id as filename - Append a suffix ".public" and ".friend"? | |
| Yes, we merge. If we just have a public one, we return the public one. Serialize to disk: I think we should NOT use two files (high overhead), we can just write both HELLOs one after the other to the same file. | |
| Sounds reasonable to me | |
| Implemented with 26832. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-04-05 13:57 | Matthias Wachs | New Issue | |
| 2013-04-05 14:01 | Matthias Wachs | Note Added: 0007038 | |
| 2013-04-05 14:03 | Matthias Wachs | Note Added: 0007039 | |
| 2013-04-05 14:10 | Matthias Wachs | Note Added: 0007040 | |
| 2013-04-05 14:14 | Matthias Wachs | Note Added: 0007041 | |
| 2013-04-05 14:14 | Matthias Wachs | Status | new => feedback |
| 2013-04-06 23:32 | Christian Grothoff | Note Added: 0007042 | |
| 2013-04-08 07:56 | Matthias Wachs | Note Added: 0007043 | |
| 2013-04-08 07:56 | Matthias Wachs | Status | feedback => new |
| 2013-04-08 09:15 | Christian Grothoff | Note Added: 0007044 | |
| 2013-04-08 11:04 | Matthias Wachs | Note Added: 0007045 | |
| 2013-04-10 11:29 | Matthias Wachs | Note Added: 0007046 | |
| 2013-04-10 11:29 | Matthias Wachs | Status | new => resolved |
| 2013-04-10 11:29 | Matthias Wachs | Resolution | open => fixed |
| 2013-04-12 10:42 | Christian Grothoff | Assigned To | => Matthias Wachs |
| 2013-04-12 10:42 | Christian Grothoff | Product Version | => Git master |
| 2013-04-12 10:42 | Christian Grothoff | Fixed in Version | => 0.10.0 |
| 2013-04-12 10:42 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-12-24 19:55 | Christian Grothoff | Status | resolved => closed |
| 2024-05-03 12:02 | Christian Grothoff | Category | peerinfo service => obsolete |