Jellemzők:
- KISS;
- önállóan üzemeltetett;
- díjak hiánya (például, a bountysource és a gitcoin 10%-ot vonnak le a kifizetésből);
- több kriptovaluta támogatása (jelenleg Bitcoin, Ethereum és Cardano);
- a GitLab, Gitea és más Git-tárhelyek támogatása várható (és tervezett) a jövőben.
- globális feladatlista az összes (jelenleg egy, a hír írásakor) példányról a donate.dumpstack.io.
A GitHub működési mechanizmusa a repository tulajdonosa részéről:
- (opcionális) a szolgáltatás telepítése, használható kész NixOS konfiguráció;;
- hozzá kell adni GitHub Action-t — belül egy segédeszköz hívódik meg, amely beolvassa a projekt feladatait és hozzáadja/frissíti a kifizetések jelenlegi állapotáról szóló megjegyzést, miközben a pénztárcák privát része csak a jótékonysági szerveren tárolódik (a jövőben lehetőség lesz offline kivitelre nagyobb adományok esetén, a kifizetések manuális megerősítése érdekében);
- minden aktuális feladatban (és az újakban) üzenet jelenik meg a github-actions[bot] adományozási pénztárcák címével (példám).
A feladat végrehajtója részéről a működési mechanizmus:
- a commit megjegyzésében fel kell tüntetni, hogy pontosan melyik feladatot oldja meg az a commit (lásd: záró kérdések kulcsszavakkal);
- a pull request szövegében a pénztárcák címét egy meghatározott formátumban kell megadni (például, BTC{address}).
- a pull request elfogadása esetén a kifizetés automatikusan megtörténik.
- ha a pénztárcák nincsenek megadva, vagy nem mindegyik, akkor a kifizetés a nem megadott pénztárcák esetén az alapértelmezett pénztárcákra történik (például ez lehet a projekt közös pénztárcája).
Biztonság:
- az általános támadási felület viszonylag kicsi;
- a működési mechanizmusok alapján a szolgáltatásnak képesnek kell lennie saját magának a források eljuttatására, így a szerverhez való hozzáférés megnyerése a források feletti ellenőrzést is jelenteni fog — megoldás lehet a nem automatizált módú működés, (például a kifizetések manuális megerősítése), amely valószínűleg (ha a projekt sikeres lesz ahhoz, hogy valaki adományozzon ennek a funkcionalitásnak) idővel megvalósul;
- a kritikus részek egyértelműen el vannak választva (lényegében ez az egyetlen 200 soros fájl, a pay.go), ezzel megkönnyítve a biztonsági kódellenőrzést;
- A kód egy független biztonsági kódellenőrzésen esett át, ami nem jelenti a sebezhetőségek hiányát, de csökkenti az előfordulásuk valószínűségét, különösen a tervezett rendszeres felülvizsgálatok fényében.
- Vannak olyan részek is, amelyeket nem ellenőriznek (pl. GitHub/GitLab stb. API), ahol a külső API-ban felfedezett esetleges sebezhetőségeket további ellenőrzésekkel tervezik kezelni, mindazonáltal a problémát a jelenlegi ökoszisztémában nem lehet megoldani, és kívül esik a hatókörön (például a mások pull requestjeinek zárolása és ezzel kód hozzáadása más projektekhez – sokkal globálisabb következményekkel jár).
Forrás: linux.org.ru
