public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed

* [EN] NNCP 8.2.0 release announcement
@ 2022-01-20 18:50 Sergey Matveev
  2022-01-20 21:45 ` John Goerzen
  0 siblings, 1 reply; 5+ messages in thread
From: Sergey Matveev @ 2022-01-20 18:50 UTC (permalink / raw)
  To: nncp-devel


[-- Attachment #1.1: Type: text/plain, Size: 2563 bytes --]

I am pleased to announce NNCP 8.2.0 release availability!

NNCP (Node to Node copy) is a collection of utilities simplifying
secure store-and-forward files and mail exchanging.

This utilities are intended to help build up small size (dozens of
nodes) ad-hoc friend-to-friend (F2F) statically routed darknet
delay-tolerant networks for fire-and-forget secure reliable files, file
requests, Internet mail and commands transmission. All packets are
integrity checked, end-to-end encrypted (E2EE), explicitly authenticated
by known participants public keys. Onion encryption is applied to
relayed packets. Each node acts both as a client and server, can use
push and poll behaviour model. Also there is multicasting areas support.

Out-of-box offline sneakernet/floppynet, dead drops, sequential and
append-only CD-ROM/tape storages, air-gapped computers support. But
online TCP daemon with full-duplex resumable data transmission exists.

------------------------ >8 ------------------------

The main improvements for that release are:

* Yggdrasil uses pure-Go IPv6+TCP network stack, instead of naked μTP
  transport protocol, making it able to work as an ordinary TCP
  server inside overlay network.

* Yggdrasil’s "prv;bind1,bind2;pub..."-like configuration strings are
  replaced with URL-like ones
  ("yggdrasils://PRV?bind=BIND1&bind=BIND2&pub=PUB").

* Ability to pass multicast-related parameters to Yggdrasil
  configuration.

* "nncp-daemon" is able to listen on both TCP and Yggdrasil-driven
  sockets simultaneously.

* "nncp-daemon"’s listening on peering endpoint socket is optional –
  you can be reached through the peers.

------------------------ >8 ------------------------

NNCP's home page is: http://www.nncpgo.org/

Source code and its signature for that version can be found here:

    http://www.nncpgo.org/download/nncp-8.2.0.tar.xz (1669 KiB)
    http://www.nncpgo.org/download/nncp-8.2.0.tar.xz.sig

SHA256 hash: 59B0D6E2 48D30289 29395B63 5D4E0CF1 14BC4DE0 F4F9F105 2E049284 980EEADD
GPG key ID: 0x2B25868E75A1A953 NNCP releases <releases@nncpgo•org>
Fingerprint: 92C2 F0AE FE73 208E 46BF  F3DE 2B25 868E 75A1 A953

There are mirrors where you can also get the source code tarballs:
http://www.nncpgo.org/Mirrors.html

Please send questions regarding the use of NNCP, bug reports and patches
to mailing list: http://lists.cypherpunks.ru/nncp_002ddevel.html

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

[-- Attachment #1.2: nncp-8.2.0.tar.xz.meta4 --]
[-- Type: application/metalink4+xml, Size: 1270 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

• * Re: [EN] NNCP 8.2.0 release announcement
    2022-01-20 18:50 [EN] NNCP 8.2.0 release announcement Sergey Matveev
  @ 2022-01-20 21:45 ` John Goerzen
    2022-01-21  8:24   ` gvisor's 32-bit compatibility Sergey Matveev
    0 siblings, 1 reply; 5+ messages in thread
  From: John Goerzen @ 2022-01-20 21:45 UTC (permalink / raw)
    To: Sergey Matveev; +Cc: nncp-devel
  
  Hi Sergey!
  
  This is very cool!  I'll be working to try this out as soon as I can.
  
  One concern I have right now is about the new dependency on gvisor.  Of
  course you're not using it as the environment it was built for, but
  nonetheless it is a pretty huge piece of software with quite a few
  dependencies.  And according to the FAQ [1] , it is only supported on
  Linux on x86_64 (with "preliminary" support for arm64).
  
  To try it out, I thought I'd build NNCP 8.2.0 on my Raspberry Pi: Linux,
  but 32-bit.  Didn't work:
  
  PREFIX=/usr/local/nncp contrib/do all
  do: Incremental mode. Use -c for clean rebuild.
  do  all
  do    bin/all
  do      bin/hjson-cli
  do      bin/nncp-bundle
  # gvisor.dev/gvisor/pkg/tcpip/transport/tcp
  vendor/gvisor.dev/gvisor/pkg/tcpip/transport/tcp/snd.go:326:16: constant 9223372036854775807 overflows int
  
  That doesn't bode well..  It wouldn't surprise me at all if there are
  other issues that would keep it from working on 32-bit platforms, or
  non-Linux ones.
  
  I don't know if there are other TCP implementations for Go that are
  usable.
  
  I'm sorry for asking for something that went in this direction - I
  didn't quite realize what I was asking for, I guess. I'd much rather
  have a uTP/TCP mismatch than sacrifice platform support in NNCP for
  sure.  I use ARM32 quite a bit around here, and actively with NNCP.
  
  I do have NNCP 8.2.0 compiling on NetBSD, but whether it will work
  correctly, or keep working over time given the gvisor FAQ, is another
  question I guess (I don't have the environment to try that part yet).
  
  [1] https://gvisor.dev/docs/user_guide/faq/
  
  John
  
  On Thu, Jan 20 2022, Sergey Matveev wrote:
  
  > I am pleased to announce NNCP 8.2.0 release availability!
  >
  > NNCP (Node to Node copy) is a collection of utilities simplifying
  > secure store-and-forward files and mail exchanging.
  >
  > This utilities are intended to help build up small size (dozens of
  > nodes) ad-hoc friend-to-friend (F2F) statically routed darknet
  > delay-tolerant networks for fire-and-forget secure reliable files, file
  > requests, Internet mail and commands transmission. All packets are
  > integrity checked, end-to-end encrypted (E2EE), explicitly authenticated
  > by known participants public keys. Onion encryption is applied to
  > relayed packets. Each node acts both as a client and server, can use
  > push and poll behaviour model. Also there is multicasting areas support.
  >
  > Out-of-box offline sneakernet/floppynet, dead drops, sequential and
  > append-only CD-ROM/tape storages, air-gapped computers support. But
  > online TCP daemon with full-duplex resumable data transmission exists.
  >
  > ------------------------ >8 ------------------------
  >
  > The main improvements for that release are:
  >
  > * Yggdrasil uses pure-Go IPv6+TCP network stack, instead of naked μTP
  >   transport protocol, making it able to work as an ordinary TCP
  >   server inside overlay network.
  >
  > * Yggdrasil’s "prv;bind1,bind2;pub..."-like configuration strings are
  >   replaced with URL-like ones
  >   ("yggdrasils://PRV?bind=BIND1&bind=BIND2&pub=PUB").
  >
  > * Ability to pass multicast-related parameters to Yggdrasil
  >   configuration.
  >
  > * "nncp-daemon" is able to listen on both TCP and Yggdrasil-driven
  >   sockets simultaneously.
  >
  > * "nncp-daemon"’s listening on peering endpoint socket is optional –
  >   you can be reached through the peers.
  >
  > ------------------------ >8 ------------------------
  >
  > NNCP's home page is: http://www.nncpgo.org/
  >
  > Source code and its signature for that version can be found here:
  >
  >     http://www.nncpgo.org/download/nncp-8.2.0.tar.xz (1669 KiB)
  >     http://www.nncpgo.org/download/nncp-8.2.0.tar.xz.sig
  >
  > SHA256 hash: 59B0D6E2 48D30289 29395B63 5D4E0CF1 14BC4DE0 F4F9F105 2E049284 980EEADD
  > GPG key ID: 0x2B25868E75A1A953 NNCP releases <releases@nncpgo•org>
  > Fingerprint: 92C2 F0AE FE73 208E 46BF  F3DE 2B25 868E 75A1 A953
  >
  > There are mirrors where you can also get the source code tarballs:
  > http://www.nncpgo.org/Mirrors.html
  >
  > Please send questions regarding the use of NNCP, bug reports and patches
  > to mailing list: http://lists.cypherpunks.ru/nncp_002ddevel.html
  
  ^ permalink raw reply	[flat|nested] 5+ messages in thread

• • * Re: gvisor's 32-bit compatibility
      2022-01-20 21:45 ` John Goerzen
    @ 2022-01-21  8:24   ` Sergey Matveev
      2022-01-21 14:45     ` John Goerzen
      0 siblings, 1 reply; 5+ messages in thread
    From: Sergey Matveev @ 2022-01-21  8:24 UTC (permalink / raw)
      To: nncp-devel
    
    [-- Attachment #1: Type: text/plain, Size: 4721 bytes --]
    
    Greetings!
    
    *** John Goerzen [2022-01-20 15:45]:
    >And according to the FAQ [1] , it is only supported on
    >Linux on x86_64 (with "preliminary" support for arm64).
    
    And indeed its latest commit even does not build on FreeBSD, so I used
    one that was mentioned in golang.zx2c4.com/wireguard/tun/netstack.
    
    >vendor/gvisor.dev/gvisor/pkg/tcpip/transport/tcp/snd.go:326:16: constant 9223372036854775807 overflows int
    >
    >That doesn't bode well..  It wouldn't surprise me at all if there are
    >other issues that would keep it from working on 32-bit platforms, or
    >non-Linux ones.
    
    Probably and I won't be surprised too. But I would change constant in
    snd.go from MaxInt64 to MaxInt32 and try to build it again. NNCP
    requires relatively small part of gvisor's overall code, so I think
    there is high probability that everything will work fine after.
    
    Personally I do not try to support 32-bit systems too, as also many
    other software. For example ZFS officially is not supported on non
    64-bit systems. Even in Go 32-bit support is not so trivial thing to
    reach: it is not only about "int" width expectations (as I thought some
    years before), but for example sync/atomic clearly states that you have
    to manually align fields in structure on 64-bit boundaries, otherwise
    those atomic instructions may painfully fail. With 64-bit code you do
    not care much about that alignment, because int, int64 and pointers are
    all 64-bit and "automatically" aligned. It is just much easier to write
    64-bit code. I try to make no expectations about "int" width and clearly
    define int32/int64 where it is appropriate and important, but I do not
    know how many other potential differences (like sync/atomic) there are.
    
    >I don't know if there are other TCP implementations for Go that are
    >usable.
    
    I do not know too. I heard about gvisor from the comment in my blog :-)
    
    >I do have NNCP 8.2.0 compiling on NetBSD, but whether it will work
    >correctly, or keep working over time given the gvisor FAQ, is another
    >question I guess (I don't have the environment to try that part yet).
    
    I test in on FreeBSD. But pay attention that I use its some months older
    version, mentioned in Wireguard (probably because of the same reasons).
    Its latest one does not build on FreeBSD at all. But it does not make
    its older version buggy on unable to work :-)
    
    >I'd much rather
    >have a uTP/TCP mismatch than sacrifice platform support in NNCP for
    >sure.
    
    I can add some kind of build switch (GO_CFLAGS="-tags XXX") and add
    support of μTP as a replacement of TCP/IP. Yggdrasil-related code will
    stay the same, but it will just use utp-code for Listen/Dial functions,
    instead of gvisor's tcpip-code. Of course with returned drawback of
    inability to deal with other nodes over TCP/IP, just only with the same
    NNCP-μTP nodes.
    
    I definitely do not wish to remove/revert tcpip, because it works faster
    and honestly acts as real host with IPv6+TCP network stack. I do not
    like utp-implementation at least because it depends on
    github.com/anacrolix/sync library, having no information about its
    acceptable usage, that actually has to be treated as non-free software.
    It is pretty small and one can rewrite/replace its usage with something
    clearly free, but someone has to do it (I do not want). And it is not
    clear in what state is github.com/neilalexander/utp's code, that
    explicitly notes that you should use libutp-wrapper library instead
    (depending on github.com/anacrolix/sync again), that is also not an
    option, because requires linking with C++ code, instead of pure-Go one.
    
    When I searched for transport implementation libraries a year ago, I did
    not find anything like simple TCP-like protocol implementation. Of
    course one can write very simple transport protocol with trivial headers
    and ACKing of every segment, but that will have awful performance. I did
    not find anything with sliding window support, something like Zmodem at
    least. With direct TCP connection between the nodes there are no
    questions about transport protocol, because all of them are guaranteed
    to be delivered in order, but although Yggdrasil uses TCP between the
    peers, packets still can have various routes (can be reordered) without
    actual delivery guarantees. Simple protocol without sliding window will
    be slow. Probably I searched badly.
    
    I met pure-Go QUIC implementation, but as far as I remember TLS can not
    be turned off in it. I won't accept that TLS complication and huge
    unneeded overhead.
    
    So I hope replacing "s.sndSsthresh = math.MaxInt64" with MaxInt32 will
    solve the issue.
    
    -- 
    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] 5+ messages in thread

  • • * Re: gvisor's 32-bit compatibility
        2022-01-21  8:24   ` gvisor's 32-bit compatibility Sergey Matveev
      @ 2022-01-21 14:45     ` John Goerzen
        2022-01-23 14:15       ` Sergey Matveev
        0 siblings, 1 reply; 5+ messages in thread
      From: John Goerzen @ 2022-01-21 14:45 UTC (permalink / raw)
        To: Sergey Matveev; +Cc: nncp-devel
      
      Hi Sergey, and thanks for all your work on this stuff!
      
      On Fri, Jan 21 2022, Sergey Matveev wrote:
      
      > Greetings!
      >
      > *** John Goerzen [2022-01-20 15:45]:
      >>And according to the FAQ [1] , it is only supported on
      >>Linux on x86_64 (with "preliminary" support for arm64).
      >
      > And indeed its latest commit even does not build on FreeBSD, so I used
      > one that was mentioned in golang.zx2c4.com/wireguard/tun/netstack.
      
      I saw that as I was working to package up Yggdrasil for Debian (both for
      its own sake and for the sake of being able to package the newer NNCP)
      and specifically had to exclude netstack because it was going to be
      incompatible.
      
      >
      >>vendor/gvisor.dev/gvisor/pkg/tcpip/transport/tcp/snd.go:326:16: constant 9223372036854775807 overflows int
      >>
      >>That doesn't bode well..  It wouldn't surprise me at all if there are
      >>other issues that would keep it from working on 32-bit platforms, or
      >>non-Linux ones.
      >
      > Probably and I won't be surprised too. But I would change constant in
      > snd.go from MaxInt64 to MaxInt32 and try to build it again. NNCP
      > requires relatively small part of gvisor's overall code, so I think
      > there is high probability that everything will work fine after.
      
      So I've got really four problems here:
      
      1) How I use NNCP for personal purposes;
      
      2) How I maintain NNCP for Debian (+ Ubuntu and all the other Debian
      derivatives, including Raspberry Pi OS and Raspbian)
      
      3) The level of effort required to maintain NNCP for #1 and #2 on an
      ongoing basis
      
      4) I'm not a Go programmer, though it is similar enough to C and Rust
      that I can understand things like an int overflow :-)
      
      So perhaps that tweak would be good enough, for now, to get NNCP running
      on my Raspberry Pis again.  But then I have to think about:
      
      - Is this patch going to break things on 64-bit systems?  (It would be
        an unusual challenge to patch something only on 32-bit systems in
        Debian.  Possible but not simple)
      
      - Are there going to be future gvisor problems on any of my platforms,
        or any of Debian's?  (which are vast)
      
      - Debian likes to have one version of each library in the repo, so if
        something else needs a version of gvisor that breaks, then we get
        stuck.
      
      > Personally I do not try to support 32-bit systems too, as also many
      > other software. For example ZFS officially is not supported on non
      > 64-bit systems. Even in Go 32-bit support is not so trivial thing to
      > reach: it is not only about "int" width expectations (as I thought some
      > years before), but for example sync/atomic clearly states that you have
      > to manually align fields in structure on 64-bit boundaries, otherwise
      > those atomic instructions may painfully fail. With 64-bit code you do
      > not care much about that alignment, because int, int64 and pointers are
      > all 64-bit and "automatically" aligned. It is just much easier to write
      > 64-bit code. I try to make no expectations about "int" width and clearly
      > define int32/int64 where it is appropriate and important, but I do not
      > know how many other potential differences (like sync/atomic) there are.
      
      I can understand that perspective, certainly, and it's unfortunate that
      Go makes you think about that stuff at that level.  I do think that
      32-bit systems are *IDEAL* NNCP nodes.  For instance, projects like
      FreedomBox [1] are all about many of the same goals NNCP has, derive
      from Debian, and typically run on embedded hardware which is usually
      32-bit.  Of course, NNCP is also ideal for Raspberry Pi.  Most Pis are
      32-bit, and even the ones that are 64-bit typically run a pure 32-bit
      userland.  I personally use it to back up my collection of Pis that do
      various things; it is absolutely ideal for that!
      
      [1] https://www.freedombox.org/
      
      >>I'd much rather
      >>have a uTP/TCP mismatch than sacrifice platform support in NNCP for
      >>sure.
      >
      > I can add some kind of build switch (GO_CFLAGS="-tags XXX") and add
      > support of μTP as a replacement of TCP/IP. Yggdrasil-related code will
      > stay the same, but it will just use utp-code for Listen/Dial functions,
      > instead of gvisor's tcpip-code. Of course with returned drawback of
      > inability to deal with other nodes over TCP/IP, just only with the same
      > NNCP-μTP nodes.
      
      That would work for me (if the sync issue can be resolved).  I would
      probably set this flag on all Debian platforms to avoid the gvisor mess.
      
      To give you an idea of the requirements for platform support in Debian,
      see:
      
      https://buildd.debian.org/status/package.php?p=nncp
      
      Basically all the platforms with the white background are "release"
      platforms and, in general, a package is required to build and work on
      all those platforms if it's going to be included in the archive.  Nearly
      half of them are 32-bit (armel, armhf, i386, and mipsel).
      
      The gray platforms are ones that are active in Debian but don't meet the
      requirements for an official stable release, and thus packages aren't
      required to work on them.  Most of them don't have NNCP because
      golang-go doesn't work on them.  You'll note that Debian GNU/FreeBSD is
      a thing!  Some of them are former release platforms (alpha, ia64, m68k,
      and powerpc) while others will probably be release platforms in the
      future (riscv64).  Some will probably never see a release (hurd-i386).
      
      > I definitely do not wish to remove/revert tcpip, because it works faster
      > and honestly acts as real host with IPv6+TCP network stack. I do not
      > like utp-implementation at least because it depends on
      > github.com/anacrolix/sync library, having no information about its
      > acceptable usage, that actually has to be treated as non-free software.
      
      That is a good catch and also a showstopper for Debian.  I will contact
      the author to see if he could add a copyright statement and reasonable
      license.
      
      > It is pretty small and one can rewrite/replace its usage with something
      > clearly free, but someone has to do it (I do not want). And it is not
      > clear in what state is github.com/neilalexander/utp's code, that
      > explicitly notes that you should use libutp-wrapper library instead
      > (depending on github.com/anacrolix/sync again), that is also not an
      > option, because requires linking with C++ code, instead of pure-Go one.
      
      That would be fine with me.  neilalexander is active in the Yggdrasil
      Matrix channel and I asked him about the state of the utp code:
      
      His reply:
      
      "Well, it *works*, but I'm not sure it's a glowing implementation or is
      it perfect"
      
      I also mentioned the anacrolix license issue.  He added:
      
      "Be warned that a lot of anacrolix's code is a horrendous mess of
      dependencies and weird wrappers around things (like the god-awful
      missinggo library). So you may find there are further steps to that
      problem."
      
      But, I could email anacrolix and see if he's willing to adjust the
      license if you'd like me to.
      
      Neil also mentioned quic-go.  I took a look at it, and there is an
      example at
      https://github.com/lucas-clemente/quic-go/blob/master/example/echo/echo.go
      that is a fairly basic echo server and client.  Although the TLS layer
      isn't disabled there, there is no key validation done
      (InsecureSkipVerify: true).  This would be fine for NNCP since it does
      its own security.  It is, in fact, common to run Yggdrasil inside TLS -
      providing no real addition security, but the performance impact seems
      to be minimal.
      
      quic-go is already in Debian which implies something good about platform
      support for it.
      
      So there are maybe some options:
      
      1) Stick with TCP and have a big, carefully documented, Yggdrasil on/off
      switch.  People that want Yggdrasil on 32-bit platforms could still use
      a standalone Yggdrasil node and it would be compatible.  I would disable
      Yggdrasil in the Debian build to provide uniform experience across the
      Debian platforms.
      
      2) Try to support uTP and TCP with compile-time options (here I would
      have to resolve the uTP license issue before this could be included in Debian)
      
      3) Switch to quic-go
      
      It seems to me that #3 would be the easiest from a platform support
      perspective.  Maybe there is a marginal performance hit, but really with
      NNCP being asynchronous and the overhead of Yggdrasil already, I would
      certainly live with that.
      
      > and ACKing of every segment, but that will have awful performance. I did
      > not find anything with sliding window support, something like Zmodem at
      > least. With direct TCP connection between the nodes there are no
      
      This is at least the third time in the past year I've wanted to
      reimplement a UUCP protocol in a more general way :-)
      
      > I met pure-Go QUIC implementation, but as far as I remember TLS can not
      > be turned off in it. I won't accept that TLS complication and huge
      > unneeded overhead.
      
      Do you mean "overhead" in terms of compiled program size, performance
      impact, code complexity, or something else?
      
      It seems code complexity would be reasonable.  The only way to really
      know the other two would be to try.
      
      FWIW, on NetBSD, nncp-caller 7.5.1 was 6MB and 8.2.0 is 10MB.  Adding
      Yggdrasil+gvisor didn't add all that much to its size.  (both
      unstripped).  After stripping, the sizes are 4.3MB and 7.6MB.
      
      John
      
      ^ permalink raw reply	[flat|nested] 5+ messages in thread

    • • * Re: gvisor's 32-bit compatibility
          2022-01-21 14:45     ` John Goerzen
        @ 2022-01-23 14:15       ` Sergey Matveev
          0 siblings, 0 replies; 5+ messages in thread
        From: Sergey Matveev @ 2022-01-23 14:15 UTC (permalink / raw)
          To: nncp-devel
        
        [-- Attachment #1: Type: text/plain, Size: 5178 bytes --]
        
        Greetings!
        
        *** John Goerzen [2022-01-21 08:45]:
        >- Is this patch going to break things on 64-bit systems?
        >- Are there going to be future gvisor problems on any of my platforms,
        >or any of Debian's?  (which are vast)
        
        Leah Neukirchen pointed me to https://github.com/google/gvisor/issues/1446
        issue related to 32-bit systems compatibility. As I expected, there were
        problems with sync/atomic library. All of that issues seems to be fixed
        in fresher gvisor's releases. Also I found https://pkg.go.dev/inet.af/netstack
        fork of gvisor, having no complexities with gvisor's building and has a
        magnitude less dependencies recorded in go.sum. As I can see, Brad Fitzpatrick
        is one of its maintainers, that is a good sign. So I moved to that fork
        and tested on FreeBSD-i386 -- no build problems anymore.
        
        So I hope there should not be any problems more with 32-bits
        compatibility in 8.3.0 release. As Brad mentioned in some tickets and as
        I can see in gvisor's .buildkite/pipeline.yaml, they build and use it
        not only on GNU/Linux systems, but on a pretty wide range of platforms.
        
        >To give you an idea of the requirements for platform support in Debian, see:
        
        I see, thanks for the information. Mainly everything depends on Go
        support of those platforms.
        
        >You'll note that Debian GNU/FreeBSD is a thing!
        
        Cool! :-)
        
        >Some of them are former release platforms (alpha, ia64, m68k,
        >and powerpc)
        
        Yeah, unfortunately (at least for Alpha) those platforms can be
        considered completely dead for general usage.
        
        >> github.com/anacrolix/sync library, having no information about its
        >> acceptable usage, that actually has to be treated as non-free software.
        >
        >That is a good catch and also a showstopper for Debian.  I will contact
        >the author to see if he could add a copyright statement and reasonable
        >license.
        
        I hope that updated gvisor should solve issues with 32-bit platforms.
        So there will be no need in his libraries.
        
        >That would be fine with me.  neilalexander is active in the Yggdrasil
        >Matrix channel and I asked him about the state of the utp code: [...]
        >"Be warned that a lot of anacrolix's code is a horrendous mess of
        >dependencies and weird wrappers around things (like the god-awful
        >missinggo library). So you may find there are further steps to that
        >problem."
        
        I am in solidarity with that opinion, especially when I saw missinggo
        too :-)
        
        >So there are maybe some options: [...]
        
        Since 8.3.0 I expect 32-bit platforms won't be problematic anymore. So
        no need to think about μTP at all. Yggdrasil disable can be done through
        GO_CFLAGS="-tags noyggdrasil" during the build, as noted in
        http://www.nncpgo.org/Build_002dinstructions.html
        
        I definitely do not want to use QUIC at all. It is just... plain wrong
        :-). You have got Yggdrasil's secure encrypted and authenticated
        transport, then you would have TLS and then Noise-based NNCP's sync
        protocol. Yes, encryption is relatively cheap, but that is horrible
        unacceptable mess in my opinion. I saw that all of that happens all the
        time in modern software development (WebSockets as example) and
        "Matryoshka of protocols" means something went wrong or someone was too
        lazy :-). I actually think about ability to turn off encryption in
        NNCP's sync protocol when it is used over Yggdrasil, to leave only
        participants authentication, to remove unnecessary overhead at all.
        
        >This is at least the third time in the past year I've wanted to
        >reimplement a UUCP protocol in a more general way :-)
        
        Me too :-).
        
        >> I met pure-Go QUIC implementation, but as far as I remember TLS can not
        >> be turned off in it. I won't accept that TLS complication and huge
        >> unneeded overhead.
        >
        >Do you mean "overhead" in terms of compiled program size, performance
        >impact, code complexity, or something else?
        
        Mainly -- resulting protocol complexity, overall code complexity. Noise
        protocol, with all encryption/authentication algorithms can be
        implemented relatively easily from the ground. TLS, even its 1.3
        version (which is heavily simplified in comparison to 1.2), is way much
        more complex thing, that will take huge amounts of the code! QUIC, being
        the transport protocol -- could be useful indeed, but its TLS-requirement
        makes it useless where TLS is just not appropriate.
        
        In ideal world, where IPv6 is accessible enough for end-users, IPsec
        should rule the world -- there should not be any use-case to TLS at all.
        IPv6 gives many addresses, that you can see for IPsec ESP protocol
        between two addresses. We live in far from the ideal world, but it does
        not mean I can accept injecting of TLS everywhere.
        
        >FWIW, on NetBSD, nncp-caller 7.5.1 was 6MB and 8.2.0 is 10MB.  Adding
        >Yggdrasil+gvisor didn't add all that much to its size.  (both
        >unstripped).  After stripping, the sizes are 4.3MB and 7.6MB.
        
        Some time ago I saw that even more compact code can be achieved with
        "go build -ldflags=s" -- it creates much more compact binaries than
        strip-ed ones. NNCP can be build with: GO_LDFLAGS="-s" redo 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] 5+ messages in thread

end of thread, other threads:[~2022-01-23 14:15 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-20 18:50 [EN] NNCP 8.2.0 release announcement Sergey Matveev
2022-01-20 21:45 ` John Goerzen
2022-01-21  8:24   ` gvisor's 32-bit compatibility Sergey Matveev
2022-01-21 14:45     ` John Goerzen
2022-01-23 14:15       ` Sergey Matveev