Карактеристике:
- КИСС;
- селф-хостед;
- без накнада (на пример, боунтисоурце и гитцоин узимају 10% плаћања);
- подршка за многе криптовалуте (тренутно Битцоин, Етхереум и Цардано);
- очекује се (и обезбеђено) да ће у будућности подржавати ГитЛаб, Гитеа и друге Гит хостинг услуге.
- глобална листа задатака из свих (односно једне, у време писања вести) инстанци даље донате.думпстацк.ио.
Механизам рада за ГитХуб од стране власника спремишта:
- (опционо) морате да примените услугу, можете да користите готова конфигурација за НикОС;
- треба додати ГитХуб Ацтион — унутра се позива услужни програм који скенира задатке пројекта и додаје/ажурира коментар о тренутном стању новчаника за донације, док се приватни део новчаника чува само на серверу за донације (убудуће, са могућношћу преузимања). ван мреже за велике донације, за ручну потврду плаћања);
- у свим тренутним задацима (и новим) појављује се порука од гитхуб-ацтионс[бот] са адресама новчаника за донације (пример).
Механизам рада особе која обавља задатак:
- коментар на урезивање означава тачно који проблем решава ово урезивање (види. затварање питања помоћу кључних речи);
- тело захтева за повлачење наводи адресе новчаника у одређеном формату (на пример, БТЦ{адреса}).
- Када се прихвати захтев за повлачење, плаћање се врши аутоматски.
- ако новчаници нису наведени или нису сви наведени, онда се исплата средстава за неодређене новчанике врши у подразумеване новчанике (на пример, ово може бити новчаник општег пројекта).
Сигурност:
- површина напада је углавном мала;
- На основу механизама рада, сервис би требало да буде у могућности да самостално шаље средства, тако да ће приступ серверу у сваком случају значити контролу над средствима – решење може бити само рад у неаутоматизованом режиму (нпр. потврђивање ручно плаћање), што је вероватно (ако је пројекат довољно успешан да неко донира за ову функционалност, онда није вероватно, али дефинитивно) да ће једног дана бити спроведен;
- критични делови су јасно раздвојени (у ствари, ово је једна паи.го датотека од 200 линија), чиме се поједностављује преглед безбедносног кода;
- код је прошао независну проверу безбедносног кода, што не значи одсуство рањивости, али смањује вероватноћу њиховог присуства, посебно у светлу планиране регуларности прегледа;
- постоје и они делови који се не контролишу (на пример АПИ ГитХуб/ГитЛаб/итд.), док се могуће рањивости у АПИ-ју треће стране планирају да се затворе додатним проверама, међутим, генерално, проблем у тренутном екосистем је нерешив и ван домета (могућа рањивост са, на пример, могућношћу затварања туђих захтева за повлачењем и тиме додавања кода у туђе пројекте – има много глобалније последице).
Извор: линук.орг.ру