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