Yesterday (on the 29th of February) you could have experienced connectivity problems, caused by erroneous handling of this leap year date in the internals of our components. A certain share of users of VCL, C++, PHP and NG editions were affected, while users of .NET and Java editions were not. Due to unfortunate combination of factors the issue slipped past our automated tests and exposed itself in the worst possible manner, blocking client-side HTTP functionality and everything else that relied on that functionality.
We fully understand and share the anger and frustration that both you and your customers had to experience. We received a multitude of blames and curses yesterday, each and every of which we believe is totally justified.
As you probably know, we started delivering the fixes for the most recent and widespread version, SecureBlackbox 14, as soon as we have become aware of the issue. Unfortunately the computing resources available at our disposal, as well as compiler speeds were not sufficient to deliver the updates instantly due to very large scope of supported targets. Still, we tried to address the issue at the fastest speed technically and technologically possible. The source code patch had been also provided for those customers of VCL and NG editions who compile the library themselves, so that they could have started integrating the fix without waiting for the official update.
Much later that day, a torn off calendar page has closed the curtains behind the issue in natural way by marking the arrival of the 1st of March. The issue went into hibernation for another four years (for unpatched versions), and forever (for the patched ones) - but not for us here at EldoS, where the issue is far from being treated as closed. I'd like to say about how we are going to handle the situation now.
First of all, we will assess carefully how could it happen that the issue so small affected the operability of the whole module. This is in order to find out which exactly processes went wrong and how we could improve or fix them.
Next, we plan to devote the next month (at least) to reviewing our test routines and improving error handling in SecureBlackbox code in order to reduce the risks of small failures bringing down large blocks of functionality in future.
Finally, we will consider designing and implementing a fault tolerance mechanism that would allow us to provide fixes and workarounds to our customers without the need to recompile the patched libraries. While it's nearly impossible to make such mechanism applicable to the whole scope of possible scenarios, we could probably come up with a scheme that would work in the majority of cases.
Thank you for your help, patience and encouragement.
Sincerely yours Eugene Mayevski CEO