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