Jellemzők:
- CSÓK;
- önálló házigazda;
- nincs díj (például a bountysource és a gitcoin a fizetés 10%-át veszi fel);
- számos kriptovaluta támogatása (jelenleg Bitcoin, Ethereum és Cardano);
- a jövőben várhatóan (és biztosított) a GitLab, a Gitea és más Git hosting szolgáltatások támogatása.
- globális feladatok listája az összes (vagyis a hír írásakor egy) példányból donate.dumpstack.io.
A GitHub működési mechanizmusa az adattár tulajdonosa részéről:
- (opcionális) telepítenie kell a szolgáltatást, használhatja kész konfiguráció a NixOS számára;
- hozzá kell adni GitHub-akció - belül egy segédprogramot hívnak meg, amely átvizsgálja a projekt feladatait és megjegyzést ad/frissít az adománytárcák aktuális állapotáról, míg a pénztárcák privát része csak az adományszerveren tárolódik (a jövőben átvételi lehetőséggel offline nagy adományok esetén a fizetés kézi megerősítéséhez);
- az összes aktuális feladatnál (és az újakban) megjelenik egy üzenet github-actions[bot] pénztárca címekkel az adományokhoz (példa).
A feladatot ellátó személy munkamechanizmusa:
- a véglegesítéshez fűzött megjegyzés pontosan jelzi, hogy ez a véglegesítés milyen problémát old meg (lásd. problémák lezárása kulcsszavak használatával);
- a lekérési kérés törzse meghatározott formátumban adja meg a pénztárcacímeket (például BTC{cím}).
- A lehívási kérelem elfogadásakor a fizetés automatikusan megtörténik.
- ha a pénztárcák nincsenek megadva, vagy nincs megadva az összes, akkor a nem meghatározott pénztárcákért fizetendő összeg az alapértelmezett pénztárcákra történik (például ez lehet egy általános projekttárca).
Biztonság:
- a támadási felület általában kicsi;
- A működési mechanizmusok alapján a szolgáltatásnak képesnek kell lennie önálló pénzküldésre, így a szerverhez való hozzáférés minden esetben a pénzeszközök feletti ellenőrzést jelenti – a megoldás csak a nem automatizált üzemmódban (pl. manuális fizetés), ami valószínű (ha a projekt elég sikeres ahhoz, hogy valaki adományozzon erre a funkcióra, akkor nem valószínű, de mindenképpen), hogy egyszer megvalósul;
- A kritikus részek egyértelműen elkülönülnek (valójában ez egy 200 soros pay.go fájl), ezáltal leegyszerűsítve a biztonsági kódok áttekintését;
- a kód független biztonsági kód felülvizsgálaton esett át, ami nem jelenti a sebezhetőségek hiányát, de csökkenti azok előfordulásának valószínűségét, különös tekintettel a felülvizsgálatok tervezett rendszerességére;
- vannak olyan részek is, amelyek nem ellenőrzöttek (például API GitHub/GitLab/stb.), míg a harmadik féltől származó API esetleges sebezhetőségeit további ellenőrzésekkel tervezik lezárni, azonban általában véve a probléma a jelenlegi Az ökoszisztéma megoldhatatlan és nem hatóköre (az esetleges sebezhetőség például azzal a képességgel, hogy bezárják mások lehívási kérelmeit, és ezáltal kódot adnak mások projektjéhez - sokkal globálisabb következményekkel jár).
Forrás: linux.org.ru