Add public key to alfred's announces

[MichaelSasser]

Hi,

is it possible to add the public key of a node to alfred's announces, so that they appear in the json file of the meshviewer backend? I am currently writing a script, that matches the files of a fastd peer repo with that json file. We are using files with comments like this:

#Name: KL-Benzinoring-56_UPL-1
#MAC: 30:b5:c2:6e:87:cf
key "53e024c51fa8126018735fabbf4357b4ddf210c2139fb3a3e18fb1f84c0e7c46";

to identify the keys. I am matching the name and the mac of the node. I observed some weird changes over the last "year", so I can't be sure if the key is the correct one. If the node has been replaced by another with the same name and the old one is used by someone else there is one file with a correct mac, one with a correct name and both are online. Ok, by committing time... but not all files have these comments.

[neocturne]

While adding such a field would be trivial, we'd like to avoid mixing the VPN data with other topology information (on the VPN servers, this information can already be queried over the status socket for connected nodes).

[jplitza]

I also proposed to have the fastd public key in the alfred data long ago (#5), and still think there are valid use cases. You could easily run tests like "are all the public keys of nodes that announce an enabled mesh VPN connected to some VPN server", or have a key policy to automatically add keys from nodes that are already somehow connected to the mesh.

I don't understand why this would mean "mixing VPN data with other topology information". We have all sorts of information in the announces, topological or not, even the version of fastd. In fact, I would consider only the information in neighbours.d as "topology information", and everything else is... something else. ;-)

[tcatm]

This feature might fit into the Gluon Community repo.

[viisauksena]

hello MichaelSasser : if you cant wait ... nobody stops you inserting a cronjob in your firmware like
*/5 * * * * /etc/init.d/fastd show_key mesh_vpn | alfred -s 123
every 5 minute (alfred forgets after 10 minutes) - this node should send the public key with identifier 123 -- you get the stuff back with alfred -r 123 ... if you know how to decrypt it right you also can do a gzip pipe in between - but since the keys should be heavily random you wont get much compression, an decompression is hard (https://cccfr.de/wiki/freifunk:verueckte_ideen_und_unbeantwortete_fragen?&#decode_alfred_stuff)
i let out the hostname, you could get it via the mac anyway and this way you get a very nice alfred json like
{ "e8:ca:ff:ee:af:fe", "b...569511592...35115b74cce21fc18a65656\x0a" },
(only the \x0a is annoying) - hope this helps ..
i am interestet in your skripts by the way.

[MichaelSasser]

Hi, @viisauksena thank you for your help. I have solved it with a package (package: https://github.com/Real-Instruments/packages with that site conf: https://github.com/Real-Instruments/site-ffwp/tree/testing ). I think it's like @tcatm says. It might be fit into the Community Repo. The script is currently in development (you will find the lib there: https://github.com/Real-Instruments/fflib ). By now i'm in a conflict with myself. I am not sure if it's the right way to "finish" the script. While I'm developing this lib I have noticed that the lib will run into a big privacy issue. With the combined data sources you are able to see a way too much informations, so it's very easy to track different things about the node owners and probably the users.

[viisauksena]

the privacy issue does not start here -- the only thing here is that you can do something like Man-in-the-middle between node and supernode. But this is mostly not secured anyway - so a bogus wannabe supernode can accept any whatsoever fastd key from you node and being fucked up.

the privace issue (offtopic) begins straight with using batman-adv and the layer 2 network. In this network it is neccessary to now all other clients by their mac-address. And you have to know how to reach them, so you know their actual connected nodes. And while many Freifunk comunitys speak proudly of node infos (in Terms of Names, overall users, and geodata, datathrouput, connected clients, availibility) you can easily know what Mac address visited what Party (social network datamining) and with whom this mac address wanders home - or maybe not so home. Who else was on this party or demonstration and so on ..
At this point only by their mac, a valuable perfect identifier for any profile.

sure you need to correlate mac to somebody - but this is the same magic as with gsm-mobile phones - you only have to make one "mistake" ... login to google at a bogus node.
Than you got a profile - you can connect it to email adress and name and so on...
And the only thing you have to do is being inside this open Network as a node (as sombdy who speaks Batman inside the net)
you actually dont have to care about what kind of traffic they generate .. the more interesting is mostly where, with whom, how long and direction.
the tiny little extra infos from fastd-key are just the cherry on top of a realy big sweet surveillance cake

[mweinelt]

Fixed in 42763d2