public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
* ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
@ 2021-08-20  3:42 John Goerzen
  2021-08-20 10:52 ` Sergey Matveev
  2021-08-20 11:11 ` nncp-sudo Sergey Matveev
  0 siblings, 2 replies; 14+ messages in thread
From: John Goerzen @ 2021-08-20  3:42 UTC (permalink / raw)
  To: nncp-devel

Hi folks,

As I've been exploring various ways to exchange NNCP data, I've 
written up a document with a number of the ones I've tried:

https://github.com/jgoerzen/nncp-tools/blob/main/docs/tunneling.org

I also have a more detailed exploration of how sudo and NNCP can 
work together, both for exchanging data between two different NNCP 
installations on a local machine, and for cases where NNCP runs as 
a different user than your regular user.

https://github.com/jgoerzen/nncp-tools/blob/main/docs/nncp-sudo.org

- John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-20  3:42 ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp) John Goerzen
@ 2021-08-20 10:52 ` Sergey Matveev
  2021-08-20 12:36   ` John Goerzen
  2021-08-20 11:11 ` nncp-sudo Sergey Matveev
  1 sibling, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2021-08-20 10:52 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

Greetings!

*** John Goerzen [2021-08-19 22:42]:
>https://github.com/jgoerzen/nncp-tools/blob/main/docs/tunneling.org

Cool! Additionally, for COM-port/serial links I find that the most easy
way currently is to setup PPP-link, with automatically assigned IPv6
link-local addresses. http://www.nncpgo.org/PPP.html

-- 
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] 14+ messages in thread

* Re: nncp-sudo
  2021-08-20  3:42 ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp) John Goerzen
  2021-08-20 10:52 ` Sergey Matveev
@ 2021-08-20 11:11 ` Sergey Matveev
  2021-08-20 12:30   ` nncp-sudo John Goerzen
  1 sibling, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2021-08-20 11:11 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

Greetings!

*** John Goerzen [2021-08-19 22:42]:
>I also have a more detailed exploration of how sudo and NNCP can work
>together, both for exchanging data between two different NNCP installations
>on a local machine, and for cases where NNCP runs as a different user than
>your regular user.
>https://github.com/jgoerzen/nncp-tools/blob/main/docs/nncp-sudo.org

And yet again, possibly stupid question out of curiosity: isn't the
ordinary Unix permissions are not enough? I assume that there is some
host with two (or more) users, sharing the same spool. Honestly I do not
remember if I tried the setup, but because
http://www.nncpgo.org/Administration.html#Shared-spool
page exists, seems that I tried it. The problem out-of-box is that newly
created files are owned solely by the user who called nncp-commands.
Let's try to "bias" the permissions to the group:

* create "nncp"/whatever group with the users allowed to share NNCP
  installation (spool/logs)
* chgrp -R nncp $NNCPCFG $NNCPLOG $NNCPSPOOL
* allow group reading of the configuration file: chmod g+r $NNCPCFG
* allow group reading/writing of the spool: chmod -R g+rwx $NNCPSPOOL
* force group owning of the spool, so newly created packets won't be
  owned by user's group: chmod -R g+s $NNCPSPOOL
* by default many users have umask 022. Personally I have umask 077.
  That will prohibit read/write of newly created packets in the spool,
  even taking the fact that they are owned (because of chmod-setgid) by
  "nncp" group. Let's force necessary umask usage:
      echo 'umask: "007"' >> $NNCPCFG

That way all newly created/generated packets will be owned by different
users, but with the same common "nncp" group, having RW-access.

Personally I run nncp-daemon mainly on 540 TCP-port ("uucp" one) and
that requires root privileges to listen on. That is why I use
ucspi-tcp+daemontools to run tcpserver (utility from UCSPI-TCP) under
root, that runs setuidgid-ed nncp-daemon when connection is established
(with capturing log in separate file through the separate daemon running
under different privileges):

    # cat /var/service/nncp-daemon/run
    #!/bin/sh -e
    NNCPLOG=FD:4 exec envuidgid uucp tcpserver -DHRU -l 0 ::0 uucp \
      nncp-daemon -ucspi -quiet -autotoss 4>&1

    # cat /var/service/nncp-daemon/log/run
    #!/bin/sh -e
    exec setuidgid stargrave multilog ./main

-- 
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] 14+ messages in thread

* Re: nncp-sudo
  2021-08-20 11:11 ` nncp-sudo Sergey Matveev
@ 2021-08-20 12:30   ` John Goerzen
  2021-08-21 19:02     ` nncp-sudo Sergey Matveev
  0 siblings, 1 reply; 14+ messages in thread
From: John Goerzen @ 2021-08-20 12:30 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel


On Fri, Aug 20 2021, Sergey Matveev wrote:

> Greetings!
>
> *** John Goerzen [2021-08-19 22:42]:
>>I also have a more detailed exploration of how sudo and NNCP can 
>>work
>>together, both for exchanging data between two different NNCP 
>>installations
>>on a local machine, and for cases where NNCP runs as a different 
>>user than
>>your regular user.
>>https://github.com/jgoerzen/nncp-tools/blob/main/docs/nncp-sudo.org
>
> And yet again, possibly stupid question out of curiosity: isn't 
> the
> ordinary Unix permissions are not enough? I assume that there is 
> some

Hi Sergey!

I have a couple of scenarios in mind:

1) Where one main config file isn't desirable.  For instance, 
individual users want to define their own exec commands, areas, 
etc.

2) Where users don't fully trust each other (this can also play 
into #1)

3) Desire to run NNCP commands with privilege separation

I did indeed see your shared spool directory.  I actually have 
been working to make NNCP work on SDF which has thousands (tens of 
thousands?) of users.  I don't have root there, so I couldn't 
create an NNCP group, and so would have been unable to run it more 
securely than basically a wide-open /tmp.  (Since I don't have 
root there, I also can't implement the sudo option)

So, thinking a bit about #1.  Shared-spool might be undesirable 
because:

- sudo rules would need to be defined for each exec target that 
  needs to run as a particular user

- Unless each user also had write access to the configuration, 
  they'd have to request all changes from someone else

Basically, the sudo setup lets the administrator delegate control 
over what a user does with NNCP to the user.

Other drawbacks of the shared spool?

- More security risks (think of, for instance, a world-readable 
  set of files in /var/mail).  Users have access to the secret 
  keys and could read each other's incoming packets at the very 
  least.  Or delete them, etc.

- Would certainly let all users see metadata about each other - 
  where they're sending packets and what size.

One reason I am running it as a separate user is because I think 
that's the appropriate way to go, even though I'm the only user on 
my box.  I wouldn't run postfix, exim, apache, tor, etc. as 
jgoerzen, because the more things run as my user, the greater the 
consequences of a security hole exploitation.  By running NNCP as 
a separate user, and having restrictive permissions on my home 
directory, I have the same kind of isolation that I get with these 
other daemons.  (Yes, I know about things like namespaces and 
capabilities on Linux, but they are Linux-specific and rather 
complicated.)  Then I can use pinpoint sudo rules for any exec 
targets I want to run as jgoerzen.  (This isn't directly about 
using sudo to talk between call/daemon but just a general reason 
that I don't want to run NNCP commands as jgoerzen.)  On these 
particular situations, I have an additional layer of gpg signature 
verification protecting against any sort of data injection at the 
NNCP level.

I'm not saying NNCP is bad - far from it!  But basically I want as 
much isolation from every component on my system as possible, and 
to treat everything as untrusted as much as I can, even if I think 
it's pretty good.

On Unix systems, with certain exceptions (email interface mainly) 
I generally don't run any commands associated with daemons as my 
local user.

(/usr/sbin/sendmail is an odd one; setuid root with exim4 and so 
forth.  I'm not fond of this model at all.  Maybe it's better with 
Postfix.)

- John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-20 10:52 ` Sergey Matveev
@ 2021-08-20 12:36   ` John Goerzen
  2021-08-21 18:30     ` Sergey Matveev
  0 siblings, 1 reply; 14+ messages in thread
From: John Goerzen @ 2021-08-20 12:36 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel


On Fri, Aug 20 2021, Sergey Matveev wrote:

> Greetings!
>
> *** John Goerzen [2021-08-19 22:42]:
>>https://github.com/jgoerzen/nncp-tools/blob/main/docs/tunneling.org
>
> Cool! Additionally, for COM-port/serial links I find that the 
> most easy
> way currently is to setup PPP-link, with automatically assigned 
> IPv6
> link-local addresses. http://www.nncpgo.org/PPP.html

I did read that, but now I realize it's not under "use cases" but 
rather "integration", so I've added a more explicit link to what I 
was working on.  PPP can be a pretty nice option, especially with 
VJ header compression, and I support it (along with tun/tap) on my 
xbnet radio stack at 
https://github.com/jgoerzen/xbnet/blob/master/doc/xbnet.1.md#running-tcpip-over-xbee-with-ppp

It is a nice solution!

But it does have some drawbacks:

- Often requires special privileges (root) to establish

- Carries security implications, since it can be used for more 
  than just one thing (open ports on one end can be reached by the 
  other, for instance), and thus often require firewall rules 
  which can get complicated.  That's the big one for me.  I don't 
  often want to have to deal with that level of hassle.

- Less efficient than certain UUCP protocols or ZModem for really 
  slow or half-duplex links

- John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-20 12:36   ` John Goerzen
@ 2021-08-21 18:30     ` Sergey Matveev
  2021-08-24  2:31       ` John Goerzen
  0 siblings, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2021-08-21 18:30 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

*** John Goerzen [2021-08-20 07:36]:
>> http://www.nncpgo.org/PPP.html
>It is a nice solution!
>- Often requires special privileges (root) to establish

Yeah, that is true.

>- Carries security implications

Well, also true. Personally I always run firewall, so just remember
about it all the time.

>- Less efficient than certain UUCP protocols or ZModem for really  slow or
>half-duplex links

Well, technically it should be of course slightly less efficient because
of PPP, IP and TCP header sizes, but with high MTU it should be not so
considerable overhead. The main issue is window scaling algorithm and
TCP on null-modem and similar links is good enough. Also PPP exists in
OS (*BSD) out of box, comparing to UUCP or ZModem-utilities. And also it
allows online protocol usage immediately. I am not trying to persuade
PPP usage, just personally my struggles stopped me at that solution :-)

-- 
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] 14+ messages in thread

* Re: nncp-sudo
  2021-08-20 12:30   ` nncp-sudo John Goerzen
@ 2021-08-21 19:02     ` Sergey Matveev
  2021-08-24  2:35       ` nncp-sudo John Goerzen
  0 siblings, 1 reply; 14+ messages in thread
From: Sergey Matveev @ 2021-08-21 19:02 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 3734 bytes --]

*** John Goerzen [2021-08-20 07:30]:
>1) Where one main config file isn't desirable.  For instance, individual
>users want to define their own exec commands, areas, etc.

Ah, true. But seems that everyone can have its own configuration file.
However currently I do not know what will happen when others will see
node/area/whatever in his "own" (actually shared) spool unknown to him.
Possibly some panics will occur.

>- More security risks (think of, for instance, a world-readable  set of
>files in /var/mail).  Users have access to the secret  keys and could read
>each other's incoming packets at the very  least.  Or delete them, etc.

In that case I think that any kind of "sharing" (via permissions, via
sudo, whatever) should not be done at all. Possibly only an additional
via-hop should be shared (with intermediate copy/nncp-xfer to transfer
files to it).

Personally I just really do not like sudo. If some nncp-exec target
should be run under some specific user/rules, then I would probably
create an additional user, with his own spool and make him available
through the "via". I really have not met situations where sudo was
necessary. Of course if the task is "run this thing under that user",
then possibly it could not be solved without sudo-like tools, but as a
rule in my practice that tasks are replaced with something completely
different (possibly just some daemon checking some abstract spool
directory for the tasks). So I just have got bias to sudo :-)
And I really would not wish to create shared spool unless everyone
trusts each other -- it is complication that needs *very* complex tools
(sudo) playing with privileges/security. I fear of that :-)

>One reason I am running it as a separate user is because I think that's the
>appropriate way to go, even though I'm the only user on my box.  I wouldn't
>run postfix, exim, apache, tor, etc. as jgoerzen, because the more things
>run as my user, the greater the consequences of a security hole
>exploitation.

Understand, fully agreed and support privilege separation!

>(Yes, I know about things like namespaces and
>capabilities on Linux, but they are Linux-specific and rather complicated.)

There are some kind of similar analogues in BSD-systems I played with
too, but yes -- all of them are very OS/kernel-specific.

>I'm not saying NNCP is bad - far from it!  But basically I want as much
>isolation from every component on my system as possible, and to treat
>everything as untrusted as much as I can, even if I think it's pretty good.

NNCP tries to be dumb and simple :-), but it is really far from, for
example, Postfix'es separated heavily privilege-dropped small daemons.
Basically no privsep and privdrop in mind.

>(/usr/sbin/sendmail is an odd one; setuid root with exim4 and so forth.  I'm
>not fond of this model at all.  Maybe it's better with Postfix.)

When I began to write on C last year, actually I am calmed down about
setuid executables. Basically you just need high (root) privileges for
many syscalls related to privsep-ing and privdrop-ing. Of course, if
developer wrote that code badly -- that could be catastrophic. So all
that stuff requires very high-quality code. And yeah, many OSes has
their specific features allowing you to do high-privileged actions
without necessary setuid-ed root executable, but they are not portable.
Everything here is rather complex :-). And also many things you just can
not do easily (or rather at all!) in Go, that could be done in C, like
using Capsicum framework for example for creating privsep-ed processes.

-- 
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] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-21 18:30     ` Sergey Matveev
@ 2021-08-24  2:31       ` John Goerzen
  2021-08-24  8:35         ` Frank Doepper
  2021-08-24 10:09         ` Sergey Matveev
  0 siblings, 2 replies; 14+ messages in thread
From: John Goerzen @ 2021-08-24  2:31 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel


On Sat, Aug 21 2021, Sergey Matveev wrote:

> Well, technically it should be of course slightly less efficient 
> because
> of PPP, IP and TCP header sizes, but with high MTU it should be 
> not so
> considerable overhead. The main issue is window scaling 
> algorithm and
> TCP on null-modem and similar links is good enough. Also PPP 
> exists in
> OS (*BSD) out of box, comparing to UUCP or ZModem-utilities. And 
> also it
> allows online protocol usage immediately. I am not trying to 
> persuade
> PPP usage, just personally my struggles stopped me at that 
> solution :-)

I totally get it!  I'm also not trying to say it's bad, just for 
the odd circumstances I've found myself in, it's not great.  If a 
person had a 115200bps null-modem serial link and a firewall it 
would be perfect.

So one of my hobbies is radio.  I've worked with 1200bps amateur 
packet radio, across which you can actually run a TCP/IP stack 
using a protocol called AX.25.  It works but it is painful.  Some 
more modern techniques involve LoRA and XBee SX radios (and a 
whole bunch of newer amateur things too).

Virtually every radio channel is half-duplex.  Things like wifi 
simulate full-duplex by using techniques like operating on 
multiple frequencies or having carefully-chosen timing for 
alternating transmit windows, etc.  With low-bandwidth, 
long-distance technologies, generally you can't cover it up.  It 
is still half-duplex.

I was early-on testing things over my LoRA stack and everything 
went fine until I tried to run ssh over it - then the whole thing 
went to pieces with endless collisions and retransmits.  Turns out 
it was all taken down by the fact that both the ssh client and 
server wanted to transmit at the beginning without waiting for 
each other, and the nonexistent collision detection in LoRA, 
combined with its very slow speeds and TCP retransmits, wound up 
taking down the link.  I had to add some collision-prevention 
logic in my code.

Taylor UUCP does still have half-duplex support in various 
protocols!  In fact, I wished the code was more modular, because 
they are some of the best protocols I am aware of for doing file 
transfer over unreliable, slow, half-duplex links.  Someday in my 
Very Limited Free Time (after I learn Go so I can hack on NNCP), I 
would love to implement something like UUCP protocols for socat. 
But alas, my free time is indeed very limited so... unlikely 
anytime soon!

- John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: nncp-sudo
  2021-08-21 19:02     ` nncp-sudo Sergey Matveev
@ 2021-08-24  2:35       ` John Goerzen
  2021-08-25 19:24         ` nncp-sudo Jonathan Lane
  0 siblings, 1 reply; 14+ messages in thread
From: John Goerzen @ 2021-08-24  2:35 UTC (permalink / raw)
  To: Sergey Matveev; +Cc: nncp-devel


On Sat, Aug 21 2021, Sergey Matveev wrote:

>>- More security risks (think of, for instance, a world-readable 
>>set of
>>files in /var/mail).  Users have access to the secret  keys and 
>>could read
>>each other's incoming packets at the very  least.  Or delete 
>>them, etc.
>
> In that case I think that any kind of "sharing" (via 
> permissions, via
> sudo, whatever) should not be done at all. Possibly only an 
> additional
> via-hop should be shared (with intermediate copy/nncp-xfer to 
> transfer
> files to it).

So that's basically what I'm proposing, just with a different 
mechanism.  One could have each user running an nncp-daemon and 
there could be calls to localhost.  There are some downsides to 
that.  nncp-xfer/copy can be tricky to get the permissions right, 
though could be done.

But here, by authorizing one user to run nncp-daemon as another, 
you don't have to have a long-running nncp-daemon process - it 
gets spun up when needed.  It is effectively the same as listening 
on an open port but without having to be up constantly and so 
forth.

Having said all that, it's still theoretical to me; I have yet to 
actually have a case where it would help.

> Personally I just really do not like sudo. If some nncp-exec 
> target
> should be run under some specific user/rules, then I would 
> probably
> create an additional user, with his own spool and make him 
> available
> through the "via". I really have not met situations where sudo 
> was

I'm doing (nncp-exec calling sudo) for privilege separation 
reasons, but that's it.  It's not using sudo to run as root, but 
to run as me.

- John

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-24  2:31       ` John Goerzen
@ 2021-08-24  8:35         ` Frank Doepper
  2021-08-24 10:12           ` Sergey Matveev
  2021-08-24 10:09         ` Sergey Matveev
  1 sibling, 1 reply; 14+ messages in thread
From: Frank Doepper @ 2021-08-24  8:35 UTC (permalink / raw)
  To: John Goerzen; +Cc: Sergey Matveev, nncp-devel

Am 23.08.21 um 21:31 schrieb John Goerzen:

> low-bandwidth, long-distance
> half-duplex

Maybe http://uftp-multicast.sourceforge.net/ is something to have a look 
at. It sends the whole payload and waits then for messages which parts to 
retransmit. Although it's rather designed for high-bandwidth high-latency 
(and maybe half-duplex) links.

Viele Grüße,
Frank

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-24  2:31       ` John Goerzen
  2021-08-24  8:35         ` Frank Doepper
@ 2021-08-24 10:09         ` Sergey Matveev
  1 sibling, 0 replies; 14+ messages in thread
From: Sergey Matveev @ 2021-08-24 10:09 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 1646 bytes --]

*** John Goerzen [2021-08-23 21:31]:
>I've worked with 1200bps amateur packet
>radio, across which you can actually run a TCP/IP stack using a protocol
>called AX.25.  It works but it is painful.

You can still use that communication to chat with the person about the
meeting, where you can share you USB/CD/tape drives with terabytes of
NNCP packets :-)

>Taylor UUCP does still have half-duplex support in various protocols!

I used to use USRobotic Courier with its proprietary HST protocol that
was literally just amazing on bad channels, like nearly the whole
telephone system was in Russia in 90s :-). So those Couriers were some
kind of de-facto hardware to work with and it was worth of it! And here
I got to know that half/full-duplex meant :-). HST protocol was some
kind of half-duplex (it can reverse its "directions", but made it very
slowly) and you could not use bidirectional full-featured transmissions.
In theory NNCP can be used with it with explicit tx/rx directions, where
only small DONE-packets are sent back. Of course I doubt anyone checked
it in practice :-)

>I wished the code was more modular, because they are some of the best
>protocols I am aware of for doing file transfer over unreliable, slow,
>half-duplex links.

Just out of curiosity, do you have experience with Kermit protocol? I
read many articles saying that Kermit is better that UUCP's
protocol-g/whatever, others are saying otherwise. Just interesting. Wish
I had enough time to play with all that things :-(

-- 
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] 14+ messages in thread

* Re: ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp)
  2021-08-24  8:35         ` Frank Doepper
@ 2021-08-24 10:12           ` Sergey Matveev
  0 siblings, 0 replies; 14+ messages in thread
From: Sergey Matveev @ 2021-08-24 10:12 UTC (permalink / raw)
  To: nncp-devel

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

*** Frank Doepper [2021-08-24 10:35]:
>Maybe http://uftp-multicast.sourceforge.net/ is something to have a look at.

Yeah, definitely, exactly that kind of! And I think that I tried it. But
do not remember the results. In all cases all that protocols shows
something like 200-300Mbps transmission speeds over 1Gbps link -- worse
than ordinary TCP connection. But of course they are aimed for
high-delay links, that I just do not have at home.

-- 
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] 14+ messages in thread

* Re: nncp-sudo
  2021-08-24  2:35       ` nncp-sudo John Goerzen
@ 2021-08-25 19:24         ` Jonathan Lane
  2021-08-25 20:31           ` nncp-sudo John Goerzen
  0 siblings, 1 reply; 14+ messages in thread
From: Jonathan Lane @ 2021-08-25 19:24 UTC (permalink / raw)
  To: nncp-devel

I think for SDF the ideal NNCP workflow would be as close to email-like
as possible, which is where needing multiple keys comes in.  For private
email, your GPG keys live in your homedir, and if someone sends you an
encrypted email, only you (or root) can read the raw data from your
spool, and only you (or root su'd to you with your key resident in
memory) can decrypt it.  All delivery goes through the single daemon on
the machine for both user-to-user and Internet-transiting.

The best way to do that from a sysadmin's perspective would be software
that defines key -locations- on the filesystem, relative to ~$USER, and
leaves key management itself up to the user, like PGP.  So for example
in NNCP's configuration it could be something like this:

{
    "userKeyLocation": ".config/nncpgo/keys/"
}­

which would read the file $HOME/.config/nncpgo/keys/private when a user
runs nncp-toss to decrypt delivered packets, and read the file
$HOME/.config/nncpgo/keys/public when encrypting outbound traffic.

This gets a little tricky with NNCP as an IMAP4/SMTP-Submission
replacement since you still need the daemon to talk to Postfix or
whatever, as well as interact with the user's regular mail spools, but
in that case I think SDF would set up NNCP as a system service like UUCP
where everyone interested runs their own node on their laptop or
whatever and uses Syncthing (installed on the MetaArray) for bridging
air gaps, and on SDF's end it's used as a mail gateway and for copying
files.
-- 
tidux@sdf•org
SDF Public Access UNIX System - http://sdf.org

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: nncp-sudo
  2021-08-25 19:24         ` nncp-sudo Jonathan Lane
@ 2021-08-25 20:31           ` John Goerzen
  0 siblings, 0 replies; 14+ messages in thread
From: John Goerzen @ 2021-08-25 20:31 UTC (permalink / raw)
  To: Jonathan Lane; +Cc: nncp-devel

On Wed, Aug 25 2021, Jonathan Lane wrote:

> I think for SDF the ideal NNCP workflow would be as close to 
> email-like
> as possible, which is where needing multiple keys comes in.  For 
> private

What I'm planning to do is run the NNCP-daemon on the metaarray, 
and let people nncp-call over to it.  I ran into so many issues 
with shared dirs that I couldn't resolve without root, plus it 
makes sense to put this on meta anyway.

I actually already have it set up there.  Just needs me to find 
time to finish the auto nodelist updating scripts.


- John

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2021-08-25 20:32 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-20  3:42 ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp) John Goerzen
2021-08-20 10:52 ` Sergey Matveev
2021-08-20 12:36   ` John Goerzen
2021-08-21 18:30     ` Sergey Matveev
2021-08-24  2:31       ` John Goerzen
2021-08-24  8:35         ` Frank Doepper
2021-08-24 10:12           ` Sergey Matveev
2021-08-24 10:09         ` Sergey Matveev
2021-08-20 11:11 ` nncp-sudo Sergey Matveev
2021-08-20 12:30   ` nncp-sudo John Goerzen
2021-08-21 19:02     ` nncp-sudo Sergey Matveev
2021-08-24  2:35       ` nncp-sudo John Goerzen
2021-08-25 19:24         ` nncp-sudo Jonathan Lane
2021-08-25 20:31           ` nncp-sudo John Goerzen