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: 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: 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: 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 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: 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: 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: 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: 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: 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