Bekendgestel skenk - 'n skenkingsdiens wat self aangebied word vir take


Bekendgestel skenk - 'n skenkingsdiens wat self aangebied word vir take

Kenmerke:

  • SOEN;
  • self aangebied;
  • geen fooie nie (byvoorbeeld bountysource en gitcoin neem 10% van die betaling);
  • ondersteuning vir baie kripto-geldeenhede (tans Bitcoin, Ethereum en Cardano);
  • dit word verwag (en verskaf) om GitLab, Gitea en ander Git-gasheerdienste in die toekoms te ondersteun.
  • globale lys van take van alle (dit is een, ten tyde van die skryf van die nuus) gevalle op skenk.dumpstack.io.

Die werkmeganisme vir GitHub vanaf die kant van die bewaarplekeienaar:

  • (opsioneel) wat jy nodig het om die diens te ontplooi, kan jy gebruik klaargemaakte konfigurasie vir NixOS;
  • bygevoeg moet word GitHub Aksie β€” 'n hulpprogram word binne geroep wat die projek se take skandeer en 'n opmerking oor die huidige stand van skenkingsbeursies byvoeg/opdateer, terwyl die private deel van die beursies slegs op die skenkingsbediener gestoor word (in die toekoms, met die vermoΓ« om dit te neem vanlyn vir groot skenkings, vir handmatige bevestiging van betaling);
  • in alle huidige take (en nuwes) verskyn 'n boodskap van github-aksies[bot] met beursie-adresse vir skenkings (Byvoorbeeld).

Die meganisme van werk aan die kant van die persoon wat die taak verrig:

  • die kommentaar by die commit dui presies aan watter probleem hierdie commit oplos (sien. kwessies af te sluit deur sleutelwoorde te gebruik);
  • die liggaam van die trekversoek spesifiseer beursie-adresse in 'n spesifieke formaat (byvoorbeeld, BTC{adres}).
  • Wanneer 'n trekversoek aanvaar word, word die betaling outomaties gemaak.
  • as die beursies nie gespesifiseer is nie, of nie almal gespesifiseer is nie, dan word die betaling van fondse vir die ongespesifiseerde beursies aan die verstekbeursies gemaak (dit kan byvoorbeeld 'n algemene projekbeursie wees).

sekuriteit:

  • die aanvaloppervlak is oor die algemeen klein;
  • Gebaseer op die bedryfsmeganismes, behoort die diens fondse onafhanklik te kan stuur, dus sal toegang tot die bediener in elk geval beheer oor die fondse beteken - die oplossing kan slegs wees om in 'n nie-outomatiese modus te werk (byvoorbeeld om te bevestig betalings met die hand), wat waarskynlik is (as die projek suksesvol genoeg is vir iemand om vir hierdie funksionaliteit te skenk, dan is dit nie waarskynlik nie, maar beslis) dat dit eendag geΓ―mplementeer sal word;
  • kritieke dele is duidelik geskei (in werklikheid is dit 'n enkele pay.go-lΓͺer van 200 reΓ«ls), wat die hersiening van sekuriteitskodes vereenvoudig;
  • die kode het 'n onafhanklike sekuriteitskode-hersiening geslaag, wat nie die afwesigheid van kwesbaarhede beteken nie, maar die waarskynlikheid van hul teenwoordigheid verminder, veral in die lig van die beplande gereeldheid van resensies;
  • daar is ook daardie dele wat nie beheer word nie (byvoorbeeld API GitHub/GitLab/ens.), terwyl moontlike kwesbaarhede in die derdeparty-API beplan word om gesluit te word met bykomende kontrole, maar in die algemeen is die probleem in die huidige ekosisteem is onoplosbaar en buite omvang (moontlike kwesbaarheid met byvoorbeeld die vermoΓ« om ander mense se trekversoeke te sluit en daardeur kode by ander mense se projekte te voeg – het baie meer globale gevolge).

Bron: linux.org.ru

Voeg 'n opmerking