Qtum量子鏈漏洞賞金計劃正式開啓

本次Qtum量子鏈賞金計劃爲了更好的藉助社區的力量參與到QTUM主網及周邊應用的開發建設中，讓QTUM持續地保持安全、高效的運行，同時能知足更多用戶的需求。

Bug分級與獎勵體系

一、若是已經有相似的Issue或者Qtum團隊已經知道並在解決該問題的狀況將不適用於該賞金計劃。

二、若是在解決前將問題公開，並形成危害的將不會得到賞金。

三、修復時，請fork代碼到本身的倉庫中進行修復，而後提交pull request在Qtum成員review以後正式合入主幹。

四、Qtum團隊成員是受僱於Qtum基金會，Qtum成員直接或間接的參與Bug修復的狀況將不會得到賞金。

五、賞金計劃以解決Qtum核心產品的技術，提高產品健壯性，Qtum網站、論壇、組織架構等不在賞金計劃之列。

六、賞金計劃的獎金與衆多因素有關、工做量、影響範圍、嚴重程度等，賞金計劃的具體賞金數額以QTUM安全團隊的結論爲準且對於賞金計劃QTUM安全團隊有最終解釋權。

範圍

請在如下Github開源項目中查找漏洞：https://github.com/qtumproject/qtum

這裏的範圍只是咱們如今關注的重點產品，若是有未被列在上面，可是一樣是被驗證的軟件漏洞，咱們也歡迎經過漏洞上報的方式進行上報和賞金申請，Qtum團隊將會對此做出評定並及時給予反饋。

這些漏洞可能會形成如下問題：

• 損失、盜取用戶資產

• 拒絕服務攻擊

• 引發共識機制的失敗

• 沒法控制的通貨膨脹

• 容許未經受權的訪問

漏洞等級分類

漏洞的等級與分類咱們會參照OWASP 模型，咱們將漏洞氛圍嚴重、高危、中危、低危、改進，具體定義方法請參考：http://www.owasp.org.cn/owasp-project/fengxian

須要注意的是：

一、 對於在比特幣、以太坊等網絡上已上報的問題，賞金會相應的折算。

二、 以上獎勵數額爲該級別漏洞的最高獎勵數額，具體的獎勵發放數額會由QTUM安全團隊決定。

對於獎勵的發放咱們還會參照其中幾項來進行評審，如僅上報漏洞者，只須要關注上報材料一項。

上報材料（15%）：完整填寫上報材料，具體請參考申報模板link，全部上報材料均爲英文版本。

代碼修復（40%）：完成代碼修復，並不引入新的問題，若是有新的問題被引入，須要在同一次提交中解決該問題。

自動化測試腳本覆蓋或手動測試方法說明（15%）：自動化測試腳本對代碼的持續集成、快速迭代下的質量控制有極其重要的做用，因此自動測試腳本的完善會做爲一項重要的考覈指標：

提供自動化測試腳本

100%

提供手動測試說明

60%

修復時間與效率（20%）：修復時間指Issue上報被確認後到修復代碼被review事後合到代碼庫間的時間，該時間會在Issue上報後QTUM安全團隊確認漏洞的反饋郵件中明確指望修復時間，該時間會與開發者協商。

該部分獎勵說明：

指望時間內完成

100%

超過時望時間50%內70%

70%

超過時望時間50%外

50%

修復思路及方法介紹與文檔完善（15%）：對於修復完的漏洞，但願完成技術材料的整理與文檔的提交，具體請參見：Bug修復後提交材料模板

漏洞的上報與修復流程

報告階段

報告者訪問「Bug上報」頁面(URL：https://qtum.org/zh/developer/long-term/bugs) 提交漏洞詳情(狀態：待審覈)

處理階段

1.一個工做日內，QTUM安全團隊會確認收到的漏洞報告並跟進開始評估問題， 同時將情報反饋給上報者(狀態：審覈中)

2. 三個工做日內，QTUM技術團隊處理問題、給出結論與指望完成時間(狀態：已確認/已忽略)。必要時會與報告者溝通確認，請報告者予以協助，評估完成後會將評估結果告知開發者。

修復階段

1. 提交者着手修復該安全漏洞(狀態：修復中)

2. 對於修復完成的問題，提交者能夠將狀態改成（狀態：待複查）修復時間根據問題的嚴重程度及修復難度而定，通常來講，嚴重和高危問題 24 小時內，中危問題七個工做日內，低危問題十五個工做日內。客戶端安全問題受版本發佈限制，修復時間根據實際狀況肯定

3. QTUM安全團隊對問題進行復查，確認修復後會告知提交者結論和漏洞得分(狀態：已複查/複查異議)

材料整理階段

根據要求完成測試腳本、手動測試說明、修復思路與文檔完善等信息

賞金髮放階段

QTUM安全團隊對提交人的材料完整性和修復完成度進行審覈併發布獎勵(狀態：已結束)

Bug上報模板

<!--- Remove sections that do not apply -->

This issue tracker is only for technical issues related to Qtum.

### Describe the issue

### Can you reliably reproduce the issue?

#### If so, please list the steps to reproduce below:

1.

2.

### Expected behavior

Tell us what should happen

### Actual behavior

Tell us what happens instead

### Screenshots.

If the issue is related to the GUI, screenshots can be added to this issue via drag & drop.

### What version of Qtum are you using?

List the version number/commit ID

### Machine specs:

- OS:

- CPU:

- RAM:

- Disk size:

### Any extra information that might be useful in the debugging process.

This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred.

模板舉例

Title: DoS of stakers possible by sending a large transaction.

Description

An attacker can publish a very big transaction. This transaction will be accepted into the mempool, however, upon attempting to include that transaction in a block stakers will produce an invalid block that is not accepted by its peers.

Impact

It is possible for an attacker to cause a denial of service attack against all stakers on the network, effectively bringing block production to a halt.

Affected software

The core qtumd client.

Reproduction

• Start qtumd in regtest mode on a clean chain in staking mode: qtumd -regtest -staking=1

• Get some mature coins to enable staking: qtum-cli -regtest generate 600

• Publish a really big transaction: qtum-cli -regtest sendtocontract ...

• Wait for a minute while the staker loop runs.

• Inspect the debug log

Expected result

The tx should have been rejected by AcceptToMemoryPoolWorker in step 3.

Actual result

• The transaction is accepted into the mempool.

• The debug.log has several entries of a block being rejected at each 16 second interval due to it including a transaction that exceeds the maximum transaction size.

Fix

Make sure that no transactions exceeding the maximum size are allowed into the mempool. This check should be implemented in AcceptToMemoryPoolWorker.

Files

Full debug.log

Bug修復後提交材料模板

###Fault cause

###Solution

###Resulting changes

###Resulting Document change

###Verify method

# Backwords compatible: (yes /no)

#Planned for version : (which version to deliver)

#New test case update/add/Manual testing:

References

• https://docs.qtum.site

• https://github.com/qtumproject