Greetings! *** John Goerzen [2021-08-07 16:12]: >I am wanting to set up an area where only one node is authorized to create >packets bound for it, but a bunch of nodes can receive those packets. I >thought I might do so by distributing the prv line of the area to every >node, but keeping the pub line to only the node authorized to send. If you know private key -- you always can deterministically generate public key from it. *25519, *448, ECDSA and similar algorithms are mathematically constructed that way. Public key can be completely ignored in the storage and computed from private key all the time -- this is just more CPU hungry. Current areas architecture has no ability to make any kind of sender's authorization. You can only check the signature of the sender and determine is it authorized one or not. Everything that NNCP can do is check against predefined "trusted"/authorized senders in the configuration file (currently there is no that option, but can be relatively easily added). >In testing, I thought "what would happen if I try to nncp-exec area:nodelist >newnodelist on a box that doesn't have the pub line for the area?" I will add an additional check that either both prv/pub exists, or none of them. I did not expect someone will leave only "prv" field :-) >I think the overall behavior is correct - it should be able to receive but >not send if it has only prv "Sending" capability can be *artificially* limited, but private key knowledge (that is required for reception) automatically gives you public key knowledge too, from mathematical point of view. If anyone wants to pass that artificial restriction, it would be trivial, just changing the couple of source code lines and recompiling. So that is not possible. NNCP's areas are very simple multicast capability and nothing more: no moderation, no authorization, no roles (moderator, administrator, poster, owner, whatever). Only signed encrypted packets, copied to multiple recipients on each hop. >segfault wasn't what was intended. Segfaults are never intended to be of course. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF