Koodin uudelleenkäytettävyys vs. vahingossa tapahtuva yleisyys

Yksi hienoimmista, konsensuskriittisistä virheistä (CVE-2018–17144) on äskettäin löydetty Bitcoin Core-ohjelmistosta, jolla oli siihen mennessä lähes virheellinen historia. Jimmy Song on kirjoittanut erinomaisen erittelyn tästä virheestä.

Lyhyt yhteenveto virheestä on, että on 4 tapausta, joissa Bitcoin Core -ohjelmiston on tarkistettava kaksinkertainen kulutus. Kaikilla 4 tapauksella oli alun perin sama koodin suorittamisvirta. Koodin joidenkin hienovaraisten toistojen jälkeen usean vuoden ajan, yksi 4: stä tapauksesta (”yhden tx-kaksinkertainen viettäminen in-a-block”) ohitettiin, minkä ansiosta kaivostyöntekijä voi potkaista jotkut solmut hyväksymään lohkon. joka lisää Bitcoinin tarjontaa.

Tämän virheen luonne muistuttaa minua jatkuvasta ristiriidasta seuraavien välillä:

(a) koodin uudelleenkäytettävyyden ja optimoinnin tarve

b) putoamisvaara, jota kutsun vahingossa tapahtuvaksi tavallisuudeksi: asiat, jotka eivät ole samanlaisia ​​kuin rakenteellisesti vaan vahingossa

Tahattomuus luo hedelmällisen tavan painajaisten ja mahdollisten virheiden, kuten CVE-2018–17144, reagoimiseksi.

Tahattomuus

Jotain taustaa, jos et ole perehtynyt ohjelmistosuunnitteluun:
 
Ohjelmistoissa on tämä suuri visio siitä, että ohjelmistokomponentit ovat täydellisesti modulaarisia - samanlaisia ​​kuin niiden fysikaaliset suunnittelukumppanit. On hyvä syy, että sinun ei tarvitse kuljettaa muun tyyppistä laturia tai USB-johtoa minne tahansa.

Joten koodin uudelleenkäytettävyyttä on aina vaadittu voimakkaasti. Tarpeettoman koodin kirjoittaminen usein paheksutaan. Miksi tehdä saman työn kahdesti, kun voit tehdä sen kerran?

Ohjelmistossa on myös pitkä historia keksimästä pyörää, mikä antaa koodin uudelleenkäytettävyydelle jopa korkeamman prioriteetin prioriteettiluettelossa. Koodien uudelleenkäytettävyyttä pidetään usein yhtenä alan parhaista käytännöistä. Tavoitteleva nuorempi ohjelmistokehittäjä saattaa olla taipuvainen ajattelemaan, että koodin uudelleenkäytettävyys on nolla.

Mutta on piilotettu vaara - ja en usko, että näitä tavaroita opetetaan koskaan kunnolla kouluissa - äärimmäistä koodin uudelleenkäytettävyyttä.

Äärimmäinen uudelleenkäytettävyys tarkoittaa minkä tahansa kahden samankaltaisen koodin kappaleen romahtamista yhdeksi käyttötapauksistaan ​​ja alkuperäisestä tarkoituksestaan ​​riippumatta.

Mikä monta kertaa päätyy koodiin, jolla on vahingossa yleisyys.

Ei ehkä ole selvää, miksi vahingossa tapahtuva yleisyys on huonoa, mutta on vain pidettävä yllä riittävän suuri ohjelmistoprojekti pitkään ymmärtääksesi miksi.

Se on huono, koska tuotevaatimukset muuttuvat ja ohjelmisto on jatkuvasti kehittyvä, ei koskaan täysin valmis tuote.

Tämä jatkuvasti liikkuva tavoiteongelma on jotain varsin ainutlaatuista ohjelmistoille. Jos olet rakennusinsinööri, sinun ei odoteta muuttavan talosta 20-kerroksista kerrostaloa tai autoa lentäväksi lautanen. Mutta ohjelmissa teemme sitä jatkuvasti.

Kun tuotevaatimukset ja käyttötapaukset muuttuvat, taustalla olevat oletukset, joille ohjelmisto alun perin kirjoitettiin, eivät ehkä enää ole sovellettavissa.

Joten se ylpeä pala yhteistä koodia, jonka uudelleen suunnittelet (mutta olet nyt täysin unohtanut), ei enää toimi niin kuin luulet.

Olen menettänyt lukumäärän siitä, kuinka monta tuskallista uudelleenkehittämisprojektia tai ilkeää virhettä olen nähnyt ennenaikaisen optimoinnin tai vahingossa tapahtuneen tavallisuuden seurauksena - siihen pisteeseen, että vältän nyt perinnöllisiä asioita kuten rutto.

Asiat, joilla on tahattomuus, paljastavat nopeasti eronsa, kun ne kehittyvät alkuperäisen tilansa ulkopuolelle. Mikä tahansa jäykkyys koodinmukaisuudessa olisi silloin massiivinen rulla, josta päästä eroon.

Mitä enemmän kerroksia vahingossa tapahtuvaa yhteistä on koodissa, sitä enemmän miinakentällä on navigointi. CVE-2018–17144 on täydellinen esimerkki siitä.