NetTalk Central

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Bruce

Pages: [1] 2 3 ... 9
NetTalk 10.48 , 11.56 , 12.57.

I've taken the step of making a new build for NetTalk 10, 11 and 12. This build solves a possible problem in the NetAcme code, the code that gets a certificate from LetsEncrypt.

An issue arose last week when it was noted that after the call to Finalize, an immediate call to get GetCertificate was made. However in some cases the certificate can take a few seconds to generate, and the call to GetCertificate will fail (with an error "Blank URL for Fetch".) An interim poll is required to know when the certificate is ready.


News And Views / Security is a Process, not an Event.
« on: November 28, 2022, 09:53:09 PM »
If I've had a slogan this year, it's been the above heading. As Desktop developers we are not always security conscious, and many of us grew up in a programming-age when security was not a big deal. But, especially for web apps, security is very important - something we really do need to make time for.

To this end, I am releasing updates to NetTalk 10, NetTalk 11 and NetTalk 12 today all in the interests of improving security.
This is an important update, and if you are making web apps with any of these then please take a time-out sometime today, grab the update, compile your apps, and move on. I know you have other important things to do, and this is a task you don't necessarily plan for, but this update is Important - and strongly recommended.

It incorporates the latest build of OpenSSL, an updated CAROOT.PEM certificate file, updates to the NetAcme class, and more.

There is no charge for these updates, and I consider them serious enough to roll back into NetTalk 10 and NetTalk 11 in addition to NetTalk 12. It takes real work to back-port them, and test the updates, so treat that as a valuable signal that you should make use of them.

Please note that these updates use StringTheory 3.40 or later (so grab that update if you are old there as well.) And (for NT10 users) the new OpenSSL DLL's make use of the VC 2017 Runtime - see

I know updates, especially unplanned updates, can be scary, but there are security reasons not to skip this one.

News And Views / OpenSSL 3.0.0 vulnerability
« on: November 01, 2022, 09:13:34 PM »
There's a fair amount of chatter going on about two OpenSSL vulnerabilities;

I'm posting this to let you know that NetTalk apps are not affected. We are currently on OpenSSL build, which predates these issues (which are version 3.0.0 specific.)

For non-NetTalk sites you also shouldn't panic - as per the second link above, only about 1.5% of OpenSSL deployments are on 3.x - 65% are like us on 1.1.1 and just over 30% are on an older version.

Incidentally the bugs have also been down-rated from Critical to High as the conditions under which they could be exploited are extremely narrow (and also wouldn't affect a typical NetTalk server.)


Morning All.

I've had a report that a new runtime error (Error: no openssl_applink) has appeared when compiling a NetTalk Server application using Clarion 10 build 12567.
The error appears to be caused by the following;

(from the release notes)
- AppBroker: Renamed ipds_libeay32.dll  to libeay32.dll and ipds_ssleay32.dll to ssleay32.dll
- moved AppBroker to use OpenSSL version 1.0.2k

As can be seen from the above notes the DLL's are now using their default names (a good thing, because it makes them easier to replace as OpenSSL updates) and they're using version 1.0.2.k (also a good thing.)

Unfortunately the LibSSL32.DLL is not included in the shipping set.

The error occurs in a NetTalk program because there is now a mix of versions (1.0.2k for the 2 mentioned above - and currently 1.0.2j for the LibSSL being shipped by NetTalk.)

There are a number of possible solutions;
a) SV should ideally ship a complete set of the OpenSSL DLL's - by shipping LibSSL as well as the other 2. This completely removes the possibility of 2 versions of OpenSSL being "mixed".  (logged as PTSS: 42457)

b) Delete libeay32.dll and ssleay32.dll from the \clarion\bin folder. (Appbroker will then use the ones in \accessory\bin). This is less ideal, but may be necessary for this build.


Web Server - Share Knowledge / MS Sql Recommended Driver Strings
« on: May 17, 2017, 10:14:43 PM »
A summary of recommendations for SQL Driver strings when used in a NetTalk Web Server context.

If you are using MsSql with your web server, and you have more than one user using the server, then you will likely run into the STMT Connection Busy error.

see here for a fuller explanation;

In our experience here we've found that turning MARS on does completely eliminate the error. We're using Ms SQL 2005, and Clarion 6.3.9058. You may have similar success with earlier builds of Clarion, we haven't back-checked to see exactly which build works the best.

The key issue though is "turning MARS on". Despite what the SV post above says, it does not appear to be automatic. In essence, the _first_ file opened in the database must have the driver setting


If you are using FM3 then the first file that connects is none of the ones in your dictionary, but rather the FM3 connection file. In order to set the driver string for that, you'll need a recent build of FM3.

You may also want to set the /ISOLATIONLEVEL to a specific value - do not just assume the default value is as documented in the Clarion Help. There are suggestions that it defaults to level 2, although the documentation suggests it defaults to 1.


this is a continuation of

>> I've looked at the jFiles class a little trying to improve performance and can't really tell what's making it slower

the key to improving performance is to use a Profiler to show where it is going slow. I'm using this;  -  Trying to do it by "eye" is a waste of time.

>> In itself the json is roughly a factor 1.2 to 1.5 slower than xml (for the tests I'v run) that's fine/acceptable. but when the requests come in randomly serving json becomes really troublesome. My production server will have to server even larger result sets and I can't hope that there will be no "collisions".

Clearly collisions will be happening so it needs to cope with that. I haven't managed to get back to testing yet, but there are a variety of approaches that can be taken. I've also got some suggestions for reducing memory usage, so that's good.

>> So I'm still looking for a way to produce and serve json fast Maybe a really stupid question: but is there a chance of producing JSON with the xFiles class (in the end it goes through the same structures and I can see "some" resemblence between xml and json <g>)?

some years back I looked into that - indeed there are some remnants of that in the xfiles.clw file, but it becomes somewhat limited quite quickly. It's possible that for edge cases there are approaches like that, but I would likely extend jFiles to handle edge cases rather than tweak xFiles at this point.

But there are a number of other options to try first before going down that road.


Web Server - Ask For Help / jFiles - List Arrays
« on: July 31, 2015, 10:17:28 AM »
start a new thread here Willie - the old thread is "blank" to me. (you'll need to repeat your last post.)

Web Server - Share Knowledge / Security alert : FREAK bug
« on: March 04, 2015, 06:35:21 AM »
Just a quick update for those paying attention to SSL errors;

A new bug called FREAK has been reported. It attacks servers that allow
EXPORT level ciphers for SSL. EXPORT ciphers are very weak (by design) but
some servers still offer them as a viable option when making an SSL


If you are using NetTalk 5.30 or later, and you haven't specifically changed
the .CiphersAllowed property, then this does not affect you.

Longer version;
The levels of SSL are discussed here;
Specifically the issue with FREAK is the CiphersAllowed property. NetTalk
has included !EXPORT (meaning EXPORT ciphers are explicitly not allowed) in
the default value of this property for a long time now - since at least
version 5.30.

<plug> So once again NetTalk users are safe because it's designed not to
rely on each programmer to get the security right. We default to secure, and
we often tweak the defaults to make things more and more secure. As long as
you stay up to date you benefit from that. </plug>

A good way to test your site to see if it is vulnerable is to use the online
service at

We'll likely chat about this a bit more during the User Group webinar on


Pages: [1] 2 3 ... 9