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