[stunnel-users] Could stunnel encryption be responsible for rendering the year as "4019" instead of "2019"?

Wed Jan 9 14:16:54 CET 2019

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

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20190109/46486ffd/attachment.sig>