Ez az oldal a közösségért készül. 
Kövess minket máshol is: 
Ha hasznosnak találod, és szeretnéd, hogy folytatódjon, támogasd a munkát 
GitHub új várakozási mechanizmust jelentett be a Dependabotban. A változtatás lehetővé teszi, hogy az eszköz legalább három napot várjon egy release közzététele után, mielőtt pull requestet nyitna.
„A cooldown beállítási lehetőség a dependabot.yml fájlban továbbra is szabályozza a működést, így beállíthatsz másik várakozási időt is, ami jobban illik a projekthez” – közölte a Microsoft tulajdonában lévő leányvállalat bejelentésében.
GitHub szerint a háromnapos alapértelmezett várakozás csak a verziófrissítésekre vonatkozik, amelyek célja, hogy a szoftverfüggőségek naprakészek maradjanak. A biztonsági frissítéseket továbbra is azonnal küldi a rendszer, így a Dependabot rögtön riasztást adhat, és pull requestet nyithat, hogy a projekt a javított verzióra váltson.
A frissítés célja, hogy kezelje azokat a helyzeteket, amikor egy támadó mérgezett verziót tud feltölteni egy népszerű csomagból, amelyet azután a függő projektek gyorsan beemelnek, mielőtt ezt a verziót eltávolítanák a registryből. Bár az ilyen trójai csomagok általában rövid ideig érhetők el, ez az idő is elég ahhoz, hogy jelentősen megnövelje egy ellátási lánc elleni támadás hatókörét.
GitHub szerint a háromnapos alapértelmezett értéket azért választották, mert ez esik a „pont jó” tartományba. „A három napos alapértelmezés két célt egyensúlyoz: túllépsz azon az időablakon, amelyben a legtöbb ilyen támadás zajlik, és közben nem tartod vissza a függőségeidet a szükségesnél tovább” – tették hozzá.
A fejlesztői platform ugyanakkor hangsúlyozta, hogy ez a kontroll csak egy védelmi réteg a sok közül. Emellett érdemes lockfile-okkal rögzíteni a függőségeket, letiltani a telepítési scripteket CI-ben, szűkíteni a tokenek jogosultságait a build pipeline-okban, és átnézni a frissítéseket, mielőtt összeolvasztják őket.
„A cooldown egy konkrét mintára készült: egy rosszindulatú verzióra, amely megjelenik, gyorsan elterjed, majd hamar lebukik” – fogalmazott GitHub. „Keveset ér az olyan támadások ellen, amelyek hosszabb távra játszanak, például a release-ekbe rejtett, szunnyadó hátsó kapuk, a karbantartók szabotázsa vagy egy kompromittált build rendszer esetén.”
Érdemes megjegyezni, hogy hasonló várakozási mechanizmusokat az elmúlt évben több csomag-ökoszisztémában is bejelentettek, köztük a Microsoft Visual Studio Code (VS Code), Ruby, Bun, npm, pnpm és Yarn esetében.
GitHub időalapú védelmi megközelítése egybeesik azzal, hogy a Python Package Index (PyPI) karbantartói bejelentették: a jövőben megakadályozzák, hogy a karbantartók új fájlokat adjanak egy csomag release-éhez, ha annak közzététele óta 14 nap eltelt.
„Az intézkedés célja, hogy megakadályozza azokat a támadókat, akik publikálási tokeneket vagy workflow-kat kompromittálnak, és így régi, már megbízható release-eket mérgeznek meg” – közölte a PyPI.
Hozzászólások
Én az egész mostani
Beküldte Linuxminter -
Értékelés:
Én az egész mostani programozási kultúrát problémásnak gondolom.
Nem volt népszerű a véleményem (pedig szép lassan beigazolódnak az aggodalmaim), de én mindig is azon az állásponton voltam, hogy káros, ha egy produktum másoktól függ. Értem én, hogy kényelmes dolog mások komponenseire hagyatkozni, és azért a ló másik oldalára sem érdemes átesni, nyilván egy printf-et nem fogok nulláról újraírni, csak hogy sajátnak mondhassam, meg tényleg vannak olyan komponensek, amiket irreálisan sok idő lenne újraimplementálni, de ésszerű keretek között mindig is azt mondtam, és továbbra is azt mondom, hogy az ember abban bízhat meg, amit saját maga alkot. (Feltéve persze, ha képes rá...) Értem én, hogy kényelmes és gyors más munkájára hagyatkozni, de ugyanakkor ennek megvan a maga veszélye is. A tapasztalatom pedig az, hogy a legtöbben nem csak tényleg komoly, nagy horderejű feladatok esetén hagyatkoznak külső összetevőkre, hanem elképesztően piszlicsáré dolgokban is. És lehet, hogy megspórolnak pár óra munkát, de cserébe elveszítik a kontrollt a projekt felett.
A másik dolog, amivel szintén nem tudok egyetérteni és azonosulni, ez az eszeveszett kapkodás. Értem én, hogy felgyorsult világ blablabla, meg hogy jól marketingelhető, hogy "folyamatosan fejlesztünk mindent, és minden állandóan naprakész, friss, stb, stb", de a valóság meg az, hogy ez leginkább az instabilitást és a megbízhatatlanságot növeli. Mint ahogy mostanság sok példa is mutatja. Aztán meg megy a hiszti, ha a projektben felhasznált 28 külső komponens valamelyikének a legújabb verziója kompromitálódott, vagy egyszerűen csak elszúrtak benne valamit. Különösen "szép", amikor egyik komponens függ a másiktól, ami függ a harmadiktól, ami függ a negyediktől, amiben ha elszúrnak valamit, akkor mindenki szív a sorban. A valódi megoldás a programozási kultúra változása lenne, de nyilván erre rövid távon nincs esély.