Rich Freeman via plug on 4 Jan 2022 06:15:22 -0800

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Microsoft Exchange year 2022 bug in FIP-FS breaks email delivery

On Tue, Jan 4, 2022 at 6:09 AM Walt Mankowski via plug
<> wrote:
> Arstechnica had a report on this bug yesterday, and it's an even worse
> bug than the original report made it seem. Turns out that 32-bit
> number wasn't being used for the date, but as a version number where
> the first 2 digits were the year! And they pushed it out on New Year's Eve!

Looking at the article it sounds like the version numbers were based
in part on a date.  As in "debian-archive-keyring_2021.1.1" or
"wireguard-tools-1.0.20210424".  That isn't too uncommon (those are
both real-world examples).

Pushing out daily updates on New Year's Eve doesn't seem too
unreasonable.  It sounds like these are spam detection signatures.
Unless spammers are going to take off on holidays I can't imagine that
you're going to want to stop updating your filters on holidays.

If this is a version number then it sounds like they don't actually
need to do any kind of date processing on it - the number probably
exists mainly to determine if an update should be applied or not.  So,
a numeric type probably isn't a big problem.  I'd still object to the
two-digit year and of course anytime you use a numeric type you need
to give thought to the largest value you will be storing.

Tangential story - I was dealing with an application that stores
currency values.  Whoever designed it didn't appreciate that some
countries have a lot of zeros in their currency conversion rates.  If
you have a 10M USD invoice and you need to express that in South
Korean Won (KRW) you need to be mindful of data types and field

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --