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