Hi All,
This may be stupid question, but I'll pose it anyway!
We use stunnel to encrypt communications between library self-service kiosks and a cloud-based library system. Since switching to this cloud-based library system, the self-service kiosks have been rendering the year in item due dates as "4019" instead of "2019" printed and emailed patron library account statements. Items will actually have been checked out to the correct due date in library system, with the year displayed correctly, which library staff and patrons can see is so when they access the system directly.
We have fixed the problem with a work-around by configuring the kiosk software to only display the last two digits of the year.
So could it be the stunnel encryption algorithms that are causing "2019" to display as "4019"?
Many thanks!
Alex
Alex Birchall Library Systems Manager The Sheppard Library Middlesex University London NW4 4BT UK
Tel: +44 (0)20 8411 5235 Mob: 07765 237 570
On Wed, Jan 09, 2019 at 10:03:09AM +0000, Al Birchall wrote:
Hi All,
This may be stupid question, but I'll pose it anyway!
We use stunnel to encrypt communications between library self-service kiosks and a cloud-based library system. Since switching to this cloud-based library system, the self-service kiosks have been rendering the year in item due dates as "4019" instead of "2019" printed and emailed patron library account statements. Items will actually have been checked out to the correct due date in library system, with the year displayed correctly, which library staff and patrons can see is so when they access the system directly.
We have fixed the problem with a work-around by configuring the kiosk software to only display the last two digits of the year.
So could it be the stunnel encryption algorithms that are causing "2019" to display as "4019"?
Once the connection is established, stunnel does not attempt to modify the data passing through it in any way. So if one of your applications gets data from another application and then displays a wrong value, the problem is in one (or both) of these applications, but only you can examine them and figure out where.
Is it possible that before switching to the cloud-based library system the library data was stored somewhere in a different way and fetched in a different way? Is it further possible that before, the dates were stored relative to the year 2000, e.g. today's date would be encoded as (19, 1, 9) or 190109 (or 190901 for some crazy people living abroad), and the kiosk software (or some middleware) knew that it had to add 2000 to the year? If so, and if the current library system stores the year in full (2019), but the kiosk (or some middleware) still adds 2000, that would account for what you are seeing.
TBH, I have heard about some - and seen some - really, really crazy bugs in software, hardware, or both, that may sometimes cause "impossible" things to happen, but in this case Occam's razor would tend to suggest that you look for a misunderstanding between the kiosk software and the cloud library system as to how dates are stored before starting to look for things that really, really ought not to happen, like stunnel modifying the data.
G'luck, Peter