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