Che cosa significa il termine giorno un bug?

Un bug di un giorno è un difetto che non è una regressione . Il difetto era lì dal primo giorno quando la funzione è stata implementata. Viene utilizzato per sostenere che un difetto ha bassa priorità, perché è stato spedito nelle versioni precedenti senza molti reclami da parte dei clienti.

Citazioni:

• Neohapsis > Archivi > Aggiornamenti del prodotto Compaq > 2001-Q4
  data - Nov 2001 o precedente

  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...

• Note sulla versione multipiattaforma per Cisco IOS versione 12.2SR: avvertenze per 12.2 (33) SRB ...
  data - maggio 2008?

  CSCsl27236... is a day one bug that just surfaced. The customer found this under heavy stress conditions...

• [security-dev 01487]: Problemi OCSP in JDK6 - OpenJDK archivio della posta
  data - gen 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...

Stati di Wikipedia

A "zero day" attack occurs on or before the first or "zeroth" day of developer awareness

Con questa definizione, sarebbe un errore di un giorno quello in cui viene sviluppato un exploit il secondo giorno di sensibilizzazione degli sviluppatori?

Tuttavia, da Infoworld.com

Zero-day bugs are vulnerabilities that have not been patched or made public.

Essi citano ulteriormente Justine Aitel, CEO di Immunity come affermato

"Bugs die when they go public, and they die when they get patched,"

Suppongo che da questa definizione si possa dedurre che un "bug di un giorno" sarebbe un termine privo di significato, o immagino si possa dire che è uno per il quale esiste una patch nel pubblico, ma che l'utente non ha applicato la patch a.

Un bug di "primo giorno" è semplicemente un bug che è in circolazione da molto tempo (il primo giorno è la data di creazione del software), rispetto a una "regressione" o un bug introdotto di recente. Quando si analizza un problema che è stato appena segnalato per la prima volta, è prassi generale concentrarsi sulle recenti modifiche al software come la fonte più probabile del problema. Alcuni bug, tuttavia, conducono una vita incantata e rimangono dormienti per anni (o anche decenni) senza essere notati. Nella mia esperienza di sviluppatore, i bug del primo giorno sono generalmente mascherati da altri software che riparano il danno o impediscono l'esercizio del bug; modifiche apparentemente non correlate possono rimuovere uno di questi "fattori di compensazione" che permettono al bug originale di manifestarsi e di essere notato. Ho trovato un bug nel 2012 nel codice che ho scritto nel 1986 e che aveva elaborato miliardi se non miliardi di transazioni su centinaia di installazioni prima del suo primo crash. Ho passato diversi giorni a convincermi (con la costruzione di test elaborati) che il bug era davvero il primo giorno.

Il termine "zero day" non ha nulla a che vedere con il "primo giorno" molto più antico.

Chiedi alla persona che ha usato l'espressione. Non è usato abbastanza ampiamente per esistere una definizione generalmente concordata.

Un "exploit zero day" è un exploit di sicurezza di cui lo sviluppatore del software (o la security community in generale) conosce da 0 giorni (vale a dire non ancora) in modo che non possa esserci una correzione. Estrapolando da questo, un "exploit di un giorno" sarebbe uno che è diventato pubblicamente noto oggi, quindi se lo sviluppatore e gli utenti agiscono velocemente, alcuni sistemi potrebbero già essere corretti.

Ma questa estrapolazione non è necessariamente corretta, l'espressione potrebbe non avere nulla a che fare con gli exploit zero-day. La risposta di Brian sembra davvero più probabile. Il che ci riconduce al mio primo paragrafo.