I came across this term recently in a mail chain. Google tells me there is a term zero-day bug and that Microsoft and Adobe are the frontrunners :)
Is there such a term as day one bug? What might that mean?
A day-one bug is a defect that is not a regression. The defect was there from day one when the feature was implemented. It is used to argue that a defect is low priority, because it has been shipped in previous releases without many complaints from customers.
Neohapsis > Archives > Compaq Product Updates> 2001-q4
date - Nov 2001 or earlier
This day-one bug was dormant until the latest release of PATHWORKS. With an older version of PATHWORKS, conditions were such that the routine was never entered simultaneously. However, the new release has a different set of calls into PWIP and the bug is now exposed...
CSCsl27236... is a day one bug that just surfaced. The customer found this under heavy stress conditions...
[security-dev 01487]: OCSP Issues in JDK6 - OpenJDK mail archive
date - Jan 2010
Changeset: 95e9083cf4a7... Summary: This day one bug is caused by missing memory barriers in various Parker::park() paths that can result in lost wakeups and hangs...
A "zero day" attack occurs on or before the first or "zeroth" day of developer awareness
By this definition, would a day one bug would one where an exploit is developed the second day of developer awareness?
However, from Infoworld.com
Zero-day bugs are vulnerabilities that have not been patched or made public.
They further quote Justine Aitel, CEO of Immunity as stating
"Bugs die when they go public, and they die when they get patched,"
I suppose you could infer from this definition that a "one day bug" would be a meaningless term, or I guess you could say it's one for which a patch exists in the public, but which the user has not applied the patch to.
A "day one" bug is simply a bug that has been around a long time (day one being the software's creation date), as compared to a "regression", or recently introduced bug. When analyzing a problem which has just been reported for the first time, it is general practice to focus on recent changes to the software as the most likely source of the problem. Some bugs however, lead a charmed life and lay dormant for years (or even decades) without being noticed. In my experience as a developer, day one bugs generally are masked by other software that repairs the damage or prevents the bug from being exercised; seemingly unrelated changes can remove one of these "compensating factors" which allow the original bug to finally manifest and be noticed. I found a bug in 2012 in code that I wrote in 1986 and which had processed billions if not trillions of transactions at hundreds of installations before its first crash. I spent several days convincing myself (by constructing elaborate tests) that the bug was truly day one.
The term "zero day" is totally unrelated to the much older "day one".
Ask the person who used the expression. It is not widely-enough used for a generally-agreed-upon definition to exist.
A "zero day exploit" is a security exploit that the developer of the software (or the security community in general) has known about for 0 days (i.e. not yet) so that there can't be a fix. Extrapolating from that, a "one day exploit" would be one that has become publically known today, so if the developer and the users act fast, a few systems may already be patched.
But that extrapolation is not necessarily correct, the expression may not have anything to do with zero-day exploits. Brian's answer actually sounds more likely. Which leads us back to my first paragraph.