Clarify putSigned

[coolacid]

Just to ensure I understand the expectations.

One can putSigned a key with a static id. This can then be edited as long as the same identity send the same putSigned with the same id number.

However, if a different identity was to attempt to send a putSigned, what happens? Another Copy just from a different From address and you should verify that the message came from the expected from address?

[coolacid]

My testing indicates that only the owner of the key/id pair can change that dataset. This means that if permanent is set, and the identity is lost the key doesn't appear to disappear. Other issues indicate that if the node that created a DHT item goes away, the item should also go away, however this doesn't seem to be the case for putSigned + permanent items. (I can't seem to kill or modify some that was not removed when a node died.)

[coolacid]

It appears that after some amount of time the signed permanent messages did expire, and my node is able to send messages again.

Something to note, the sending node received a successful message when sending the messages, even though it was signed by the wrong key to update. It might be better to reject the message?

[coolacid]

I continue to sit corrected. I just pulled the values for URFCA1 and found two of the same ID, but from different owners:

2024-01-10 09:42:59 INFO     r.owner=<InfoHash '4ba2101f0d50e7c2a4e6a64622850a8a3627eb52'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=532
2024-01-10 09:43:00 INFO     r.owner=<InfoHash '1e3f129f2f66ffb7e86fa539cdf9ff6520e795e5'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=567

The first message has an internal timestamp of: Wednesday, 10 January 2024 02:24:48 (GMT)
The second message has an internal timestamp of: Monday, 8 January 2024 23:16:42

This node was restarted (so got new identity) about 12 hours ago, so the 4ba21 owner should be the correct owner.

Something else I have yet to figure out is how to confirm a message was signed by the node I expect it to come from. How does one translate an identity into the owner InfoHash.

[coolacid]

More oddities.

2024-01-11 06:41:33 INFO     r.owner=<InfoHash '1e3f129f2f66ffb7e86fa539cdf9ff6520e795e5'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=567
2024-01-11 06:41:33 INFO     New: User(timestamp=1704763662, sequence=9, Userlist=[['VE3YCA  ', 'VE3YCA  B', 65, 'URFCA1  ', 1704763661]])
.... <snip> ... 
2024-01-11 06:41:41 INFO     r.owner=<InfoHash '1e3f129f2f66ffb7e86fa539cdf9ff6520e795e5'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=567
2024-01-11 06:41:41 INFO     Expired: User(timestamp=1704763662, sequence=9, Userlist=[['VE3YCA  ', 'VE3YCA  B', 65, 'URFCA1  ', 1704763661]])
.... <snip> ...
2024-01-11 07:32:46 INFO     r.owner=<InfoHash '4ba2101f0d50e7c2a4e6a64622850a8a3627eb52'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=532
2024-01-11 07:32:46 INFO     Expired: User(timestamp=1704853476, sequence=0, Userlist=[])
.... <snip> ... 
2024-01-11 07:32:46 INFO     r.owner=<InfoHash '4ba2101f0d50e7c2a4e6a64622850a8a3627eb52'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=532
2024-01-11 07:32:46 INFO     New: User(timestamp=1704853476, sequence=0, Userlist=[])
.... <snip> ... 
2024-01-11 07:32:47 INFO     r.owner=<InfoHash '1e3f129f2f66ffb7e86fa539cdf9ff6520e795e5'> r.recipient=<InfoHash '0000000000000000000000000000000000000000'> r.user_type='urfd-users-1' r.id=4 r.size=567
2024-01-11 07:32:47 INFO     New: User(timestamp=1704763662, sequence=9, Userlist=[['VE3YCA  ', 'VE3YCA  B', 65, 'URFCA1  ', 1704763661]])

It almost appears as tho the network is expiring, and something is resurrecting old entries?

The service that should be populating these records, hasn't sent anything since it was started 35 hours ago.

[n7tae]

@coolacid, thanks for raising this issue! As author of urfd, I could use some clarification as well! Especially about putSigned() and the other end, checkSignature(). Currently, urfd does not check signatures. I have started another collection of tools to examine information published on the ham-dht that does use checkSignature(), but it's not clear to me what it's actually doing. The OpenDHT documentation would benefit from a more complete example.

As a clarification that might be useful, urfd publishes a 4-part dht::Value using a key that is based on the same string that is used to generate its identity. The dht::Value::id values are 1 to 4. Currently, all 4 part are marked permanent, and I now think that's probably wrong. Parts 1 and 2 are urfd configuation data and usually don't change once urfd is running and should be marked as permanent. Parts 3 and 4 represent current connection state data for the node that is usually quite transient in nature. I think that these two parts should not be permanent and should only be putSigned() once, whenever that piece of urfd's state changes, so that those Value parts will die a natural death within a few minutes. The idea here is that any nodes interested in these parts of a urfd's Value should be doing a listen() and not a get(). All of the OpenDHT stuff in urfd is in reflector/Reflector.cpp.

[aberaud]

Thanks for the reports.

The documentation was updated to clarify how SecureDHT works, as well as the semantics of signed values and value edition.

Every value provided to get and listen callbacks is already checked beforehand by OpenDHT. If a value has a owner field set and was provided by a dht callback, it is signed and valid.

However there seems to be a bug that causes some values to never expire, investigating.