Greetings!

*** John Goerzen [2021-07-31 21:04]:
>One is error handling.

Yeah, that thing NNCP is completely lacking. Just logs and retries
forever until operator intervene with it. Definitely something has
to be done in that direction.

I do not think that packet's ordering can be "solved" easily. If we
will store some kind of sequence numbers in encrypted packet -- it is
unnecessary and unwilling metainformation leak. If we decrypt it and get
the plaintext packet, then it can contain some ordering information,
but... if it is already processing, then we should process it and store
on the disk, removing the encrypted packet, clearing out the spool
directory.

I met the problem of ordering with extensively used chunked files (most
of data I sent is chunked): http://www.nncpgo.org/Chunked.html
And "solve" it just by parsing the .nncp.meta file and waiting for all
.nncp.chunk* appearance. And only after that they are checksummed and
reassembled to the destination packet.

>One could request no notifications ever, notifications on
>processing with any kind of result, or notifications only for errors.  These
>notifications would be emailed back (and the address to send them to could
>be specified).

Also thought about that. But not sure about any kind of feedback error
channel, because of the complexity and possible metainformation leakage
(watching for the facts of feedbacked information sent back). Currently
I assume that NNCP networks are small enough and each time each operator
decides himself what to do, possibly manually sending email about
invalid/unexpected exec/whatever-packets.

>Secondly, reouting.  What if we supported, say, "partial source routing?"
>A - B - C - D

Exactly that use-case is already covered in 7.2.0 release. I just tested
it locally with [abcd] nodes to be sure. http://www.nncpgo.org/Release-7_005f2_005f0.html

>Finally, the commands for nncp-exec in nncp.hjson.  I think it would be
>really useful to be able to say "do not pass parameters to this program" (or
>maybe pass them as an environment variable instead of on the command line or
>something).  I'm using wrapper scripts for this purpose right now but just
>blocking them entirely could be nice for security.

Passing as environment variable (something like NNCP_ARG1, NNCP_ARG2
..., NNCP_ARGS=2) can complicate scripts forcing them to probably unset
those envvars before calling another command. Arguments are "local" for
just single command call. I think that using wrappers is just some kind
of necessary and completely ok thing to do. Someone probably want to
block the stdin entirely -- I do not think that NNCP should cover all
possible call-cases: flexible wrappers are for that.

>Thanks again for all you do, Sergey!

Glad it is useful!

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF