public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* A few other features?
@ 2021-08-01 2:04 John Goerzen
2021-08-03 10:57 ` Sergey Matveev
0 siblings, 1 reply; 4+ messages in thread
From: John Goerzen @ 2021-08-01 2:04 UTC (permalink / raw)
To: nncp-devel
Hi,
These are brainstorms that are somewhat forward-looking....
In thinking about NNCP -- I also happen to have purchased some old
books on UUCP and am researching the old UUCPNet -- it occurs to
me that there are three areas where there may be useful
improvements.
One is error handling. Right now, if a packet arrives at a node
and toss can't deal with it, it basically retries forever. I
exploit this behavior heavily with my nncp-exec processing;
sometimes I need to process packets in order, and of course there
is no guarantee for ordering in nncp-exec. However, I can check
if I'm ready for a certain sequence number or whatnot, and just
exit nonzero if not, and it'll try again when hopefully the
prerequisite has been processed. Very nice.
However, sometimes it's not quite as nice; maybe a file is sent to
a host that's configured to disallow from the sender, or a command
is run that's not defined, etc. uux had the -z option, which
indicates what should happen on error. 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). I'm not entirely sure what the right idea here is,
but maybe there is some way to keep the currect behavior (which is
quite useful) as a default and offer an alternative to just fail
(perhaps with a notification) if selected by the user (or forced
in nncp.hjson on the recipient side).
Secondly, reouting. What if we supported, say, "partial source
routing?"
Say we have a network like this:
A - B - C - D
A wants to send something to D.
Of course, it could say -via B,C
But what if B's nncp.hjson defines D as "via C". Could A just say
-via B? B could unwrap the packet, see that it got a destination
for D, look that up, see it's got to go via C, re-wrap it in an
onion for C and queue it up for C.
I'm not entirely sure yet if this is actually useful but my gut
tells me it may be if we scale up.
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.
Thanks again for all you do, Sergey!
- John
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A few other features?
2021-08-01 2:04 A few other features? John Goerzen
@ 2021-08-03 10:57 ` Sergey Matveev
2021-08-03 20:22 ` John Goerzen
0 siblings, 1 reply; 4+ messages in thread
From: Sergey Matveev @ 2021-08-03 10:57 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A few other features?
2021-08-03 10:57 ` Sergey Matveev
@ 2021-08-03 20:22 ` John Goerzen
2021-08-04 8:19 ` Sergey Matveev
0 siblings, 1 reply; 4+ messages in thread
From: John Goerzen @ 2021-08-03 20:22 UTC (permalink / raw)
To: Sergey Matveev; +Cc: nncp-devel
On Tue, Aug 03 2021, Sergey Matveev wrote:
> *** 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
I understand, and that's fine with me, and in fact the current
retrying works for other situations as well.
>>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.
It does send a message about certain things, right? Such as files
received? Or is that different in your mind because that's all on
the receiving end? I suppose there could be a new packet type -
"result" or some such - that wouldn't require a remote to be able
to exec sendmail, and could be transformed into an email locally.
>
>>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
You know, I had thought that was the case too, and went back and
looked at what had happened when I tried it. Server in question
was still on 7.1.1 *facepalm*. Indeed it is doing that now.
That actually dramatically simplifies things. Leaf nodes in a
large "NNCPNet" wouldn't need to know much of any routing at all.
Just set every node to go via a central hub and let the central
hub figure it out.
> 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
Very good point.
> 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.
Fair enough. That makes sense.
- John
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: A few other features?
2021-08-03 20:22 ` John Goerzen
@ 2021-08-04 8:19 ` Sergey Matveev
0 siblings, 0 replies; 4+ messages in thread
From: Sergey Matveev @ 2021-08-04 8:19 UTC (permalink / raw)
To: nncp-devel
[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]
*** John Goerzen [2021-08-03 15:22]:
>It does send a message about certain things, right? Such as files received?
>Or is that different in your mind because that's all on the receiving end?
>I suppose there could be a new packet type - "result" or some such - that
>wouldn't require a remote to be able to exec sendmail, and could be
>transformed into an email locally.
Yeah, I thought and mean exactly about the new packet type ("result").
Of course not ordinary exec-packet.
>That actually dramatically simplifies things.
Should so! I am honestly do not know why I artificially limited ability
to "reroute" those packets. Possibly becase I assumed that the
originator of the packet forcefully wants *exactly* that nodes to
participate during the transmission? Possibly someone forcefully do not
want some node to see some packets (even their sizes)? But anyway noone
has any guarantees about delivery path, so why bothering? It is like
SMTP: you can send email to the server via forced TLS, but after that,
you have no abilities to control if TLS is used at all.
--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-08-04 11:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-01 2:04 A few other features? John Goerzen
2021-08-03 10:57 ` Sergey Matveev
2021-08-03 20:22 ` John Goerzen
2021-08-04 8:19 ` Sergey Matveev