ANNOUNCE: nats-tcl release 2.0

[Petro Kazmirchuk]

Hi all,
After many months of extensive work, version 2.0 of the Tcl client for the NATS message broker is finally out :)
https://github.com/Kazmirchuk/nats-tcl/releases/tag/v2.0
and special thanks to ANT Solutions for their contributions!

What is NATS?
NATS is an open-source lightweight message bus with high performance, clear documentation and very easy to use. The server is written in Go, and client libraries are available in many languages. You can learn more about NATS at https://nats.io

The new nats-tcl release comes with extensive JetStream support that provides at-least-once and exactly-once delivery guarantees.
Also, if you are looking for a replacement for MQTT, NATS supports MQTT out of the box and can be used as a drop-in replacement.

I believe that nats-tcl can be especially useful in integrating legacy Tcl components with newer software written in other languages, e.g. in the industrial monitoring domain.

I am also planning to write a blog post somewhere (probably medium.com, unless anyone has better suggestions?) about my findings and impressions of working with Tcl in 2023. To be honest, I was particularly annoyed by 2 bugs:
- in core Tcl: https://core.tcl-lang.org/tcl/tktview/ea69b0258a9833cb61ada42d1fc742d90aec04d0
- and in TclTLS (9y old!) : https://core.tcl-lang.org/tcltls/tktview/3c42b2ba11
If somebody could take a look at them, it would be great.

Petro

[Petro Kazmirchuk]

Forgot to mention that now it's available also as a Tcl module. I've noticed that the 1.0 release got included in some Tcl distributions (thanks a lot!), so now you can include a single .tm file instead of the whole repo with tests, docs etc.

[Harald Oehlmann]

Post by Petro Kazmirchuk
Hi all,
After many months of extensive work, version 2.0 of the Tcl client for the NATS message broker is finally out :)
https://github.com/Kazmirchuk/nats-tcl/releases/tag/v2.0
and special thanks to ANT Solutions for their contributions!
What is NATS?
NATS is an open-source lightweight message bus with high performance, clear documentation and very easy to use. The server is written in Go, and client libraries are available in many languages. You can learn more about NATS at https://nats.io
The new nats-tcl release comes with extensive JetStream support that provides at-least-once and exactly-once delivery guarantees.
Also, if you are looking for a replacement for MQTT, NATS supports MQTT out of the box and can be used as a drop-in replacement.
I believe that nats-tcl can be especially useful in integrating legacy Tcl components with newer software written in other languages, e.g. in the industrial monitoring domain.
- in core Tcl: https://core.tcl-lang.org/tcl/tktview/ea69b0258a9833cb61ada42d1fc742d90aec04d0
- and in TclTLS (9y old!) : https://core.tcl-lang.org/tcltls/tktview/3c42b2ba11
If somebody could take a look at them, it would be great.
Petro

Dear Petro,
thank you for that, great !

For the two bugs, I see no current wizards, which may look to them.

Channel transforms is deep Wizard stuff, with 0 to 1 people knowing
about the details.

And the TLS package is highly unsupported. There is no really
development, because many Wizards have moved away from it, to TWAPI on
Windows and Alex has another TLS package.

Sorry, it is as it it,
Harald

[Petro Kazmirchuk]

I see...
I find channel transforms a unique concept that is immensely useful for testing of network protocols with its ability to sniff/inject/intercept data going through a socket. Don't know of any other programming language having such feature.

I haven't heard of the "other" TLS package (based on OpenSSL I suppose?) where can I find it?

[Harald Oehlmann]

Post by Petro Kazmirchuk
I see...
I find channel transforms a unique concept that is immensely useful for testing of network protocols with its ability to sniff/inject/intercept data going through a socket. Don't know of any other programming language having such feature.

Yes ! Then you are one of the 5 Wizards understanding it a bit ...
If you want to get the fix advanced, a first step would be to create a
test in the tcl test suite for it.
Do you know the test suite in tcl (folder test in the core distribution)?
https://core.tcl-lang.org/tcl/
But a full crash is normally untestable, so this is not a way to go...

Post by Petro Kazmirchuk
I haven't heard of the "other" TLS package (based on OpenSSL I suppose?) where can I find it?

https://fossil.sowaswie.de/nacl/index

Enjoy,
Harald

[Petro Kazmirchuk]

thanks, I've seen the nacl package, but AFAICS it doesn't provide TLS, so can't be a replacement for the old TclTLS

re. the crash - the workaround is a simple "update" call, so not a big deal (and I'm not keen on figuring out Fossil, sorry :) ). Now that the bug is reported, at least other people can find it in Google, if they encounter the same problem.

[Ashok]

Post by Petro Kazmirchuk
Hi all,
After many months of extensive work, version 2.0 of the Tcl client for the NATS message broker is finally out :)
https://github.com/Kazmirchuk/nats-tcl/releases/tag/v2.0
and special thanks to ANT Solutions for their contributions!
What is NATS?
NATS is an open-source lightweight message bus with high performance, clear documentation and very easy to use. The server is written in Go, and client libraries are available in many languages. You can learn more about NATS at https://nats.io
The new nats-tcl release comes with extensive JetStream support that provides at-least-once and exactly-once delivery guarantees.
Also, if you are looking for a replacement for MQTT, NATS supports MQTT out of the box and can be used as a drop-in replacement.
I believe that nats-tcl can be especially useful in integrating legacy Tcl components with newer software written in other languages, e.g. in the industrial monitoring domain.
- in core Tcl: https://core.tcl-lang.org/tcl/tktview/ea69b0258a9833cb61ada42d1fc742d90aec04d0
- and in TclTLS (9y old!) : https://core.tcl-lang.org/tcltls/tktview/3c42b2ba11
If somebody could take a look at them, it would be great.
Petro

Looking forward to your article. I'd be definitely interested.

Regarding tls, what version were you using? With 1.22, I don't see the
bug described in that report:

% tls::socket -require 1 wrong.host.badssl.com 443
sock00000196A5963950
% tls::handshake sock00000196A5963950
handshake failed: certificate verify failed

With respect to the Tcl transform crash, hopefully someone will take a
look soon as currently the focus is on getting 8.7/9.0 betas out.

/Ashok

[Petro Kazmirchuk]

Ashok, your book has been my go-to reference all the time :)

Regarding TLS, if you add the -command option, you'll see a more detailed error: "unable to get local issuer certificate". I get the same error also when connecting to valid hosts under badssl.com. So, it doesn't even begin checking SAN.
TBH I'm not sure how to get CA of badssl.com properly. I tried downloading from Firefox and using them with "openssl s_client" with no luck either.
Anyway, what I did use for my experiments was mkcert:
https://github.com/FiloSottile/mkcert
Then I pass -cafile to TclTLS and connect to a local "openssl s_server"

[Ashok]

Some experiments...

Get the badssl.com "good" certificate

% set so [tls::socket -autoservername 1 -require 1 -cafile
d:/tcl/lib/cacert.pem badssl.com 443]
sock000002EAE4CC0570
% tls::handshake $so
1
% set so [tls::socket -servername badssl.com -require 1 -cafile
d:/tcl/lib/cacert.pem badssl.com 443]
sock000002EAE4D009C0
% tls::handshake $so
1


So that works correctly. Note the -autoservername 1 option or
-servername option. Without one of those I don't think badssl.com will
return the correct valid certificate:

set so [tls::socket -require 1 -cafile d:/tcl/lib/cacert.pem
badssl.com 443]
sock000002EAE4CC0EF0
% tls::handshake $so
handshake failed: certificate verify failed

To check whether name is being verified,

% set so [tls::socket -servername foo.com -require 1 -cafile
d:/tcl/lib/cacert.pem badssl.com 443]
sock000002EAE48D8360
% tls::handshake $so
handshake failed: certificate verify failed

That seems right, but

% set so [tls::socket -servername foo.com -require 1 -cafile
d:/tcl/lib/cacert.pem www.example.com 443]
sock000002EAE4B276A0
% tls::handshake $so
1

which, as you described, is odd. I would expect that to fail.

And your actual example also fails

% set so [tls::socket -autoservername 1 -require 1 -cafile
d:/tcl/lib/cacert.pem wrong.host.badssl.com 443]
sock000002EAE4CD39C0
% tls::handshake $so

So I don't know what's going on. Seems like a bug in tls or openssl
verification.

On Windows, twapi seems to work correctly

% set so [twapi::tls_socket wrong.host.badssl.com 443]
The target principal name is incorrect.
% set so [twapi::tls_socket badssl.com 443]
rc2

Not sure all that helps you a lot but it seems there is some name
checking going on but not complete. Definitely looks like a bug and one
that has not been addressed for years :-(

/Ashok

Post by Petro Kazmirchuk
Ashok, your book has been my go-to reference all the time :)
Regarding TLS, if you add the -command option, you'll see a more detailed error: "unable to get local issuer certificate". I get the same error also when connecting to valid hosts under badssl.com. So, it doesn't even begin checking SAN.
TBH I'm not sure how to get CA of badssl.com properly. I tried downloading from Firefox and using them with "openssl s_client" with no luck either.
https://github.com/FiloSottile/mkcert
Then I pass -cafile to TclTLS and connect to a local "openssl s_server"

[Petro Kazmirchuk]

I had no doubts that twapi works correctly :) but I guess Tcl user base on Linux is much larger than on Windows? given how many people on Github ignore TIP 477

AFAICS the -servername option is used only for SNI, so that a server knows which certificate to provide.

I suspect, fixing the bug may be a matter of calling
SSL_set1_host(ssl, "expected.host.name")
(which is not done yet in the sources)

If I send a patch, would someone be able to go thru all formalities in Fossil? I'm not keen on setting it up TBH.
The question is, do we want it to be a new default with an option to disable, or vice versa?

[Harald Oehlmann]

Post by Petro Kazmirchuk
I had no doubts that twapi works correctly :) but I guess Tcl user base on Linux is much larger than on Windows? given how many people on Github ignore TIP 477
AFAICS the -servername option is used only for SNI, so that a server knows which certificate to provide.
I suspect, fixing the bug may be a matter of calling
SSL_set1_host(ssl, "expected.host.name")
(which is not done yet in the sources)
If I send a patch, would someone be able to go thru all formalities in Fossil? I'm not keen on setting it up TBH.
The question is, do we want it to be a new default with an option to disable, or vice versa?

Petro,
Great! I can care to put it into fossil. Could you include it into a
ticket to have a reference?.

Take care,
Harald

[Ashok]

TIP 477? What's that? :-)

Post by Petro Kazmirchuk
I had no doubts that twapi works correctly :) but I guess Tcl user base on Linux is much larger than on Windows? given how many people on Github ignore TIP 477
AFAICS the -servername option is used only for SNI, so that a server knows which certificate to provide.
I suspect, fixing the bug may be a matter of calling
SSL_set1_host(ssl, "expected.host.name")
(which is not done yet in the sources)
If I send a patch, would someone be able to go thru all formalities in Fossil? I'm not keen on setting it up TBH.
The question is, do we want it to be a new default with an option to disable, or vice versa?

[Petro Kazmirchuk]

so ironic... I've just got a PR showing my fundamental misunderstanding of non-blocking gets, so here's v2.0.1
https://github.com/Kazmirchuk/nats-tcl/releases/tag/v2.0.1