本次Qtum量子鏈賞金計劃為了更好的借助社區(qū)的力量參與到QTUM主網(wǎng)及周邊應(yīng)用的開發(fā)建設(shè)中，讓QTUM持續(xù)地保持安全、高效的運行，同時能滿足更多用戶的需求。

Bug分級與獎勵體系

1、如果已經(jīng)有類似的Issue或者Qtum團隊已經(jīng)知道并在解決該問題的情況將不適用于該賞金計劃。

2、如果在解決前將問題公開，并造成危害的將不會獲得賞金。

3、修復(fù)時，請fork代碼到自己的倉庫中進行修復(fù)，然后提交pull request在Qtum成員review之后正式合入主干。

4、Qtum團隊成員是受雇于Qtum基金會，Qtum成員直接或間接的參與Bug修復(fù)的情況將不會獲得賞金。

5、賞金計劃以解決Qtum核心產(chǎn)品的技術(shù)，提升產(chǎn)品健壯性，Qtum網(wǎng)站、論壇、組織架構(gòu)等不在賞金計劃之列。

6、賞金計劃的獎金與眾多因素有關(guān)、工作量、影響范圍、嚴(yán)重程度等，賞金計劃的具體賞金數(shù)額以QTUM安全團隊的結(jié)論為準(zhǔn)且對于賞金計劃QTUM安全團隊有最終解釋權(quán)。

范圍

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

這里的范圍只是我們現(xiàn)在關(guān)注的重點產(chǎn)品，如果有未被列在上面，但是同樣是被驗證的軟件漏洞，我們也歡迎通過漏洞上報的方式進行上報和賞金申請，Qtum團隊將會對此作出評定并及時給予反饋。

這些漏洞可能會造成以下問題：

• 損失、盜取用戶資產(chǎn)

• 拒絕服務(wù)攻擊

• 引起共識機制的失敗

• 無法控制的通貨膨脹

• 允許未經(jīng)授權(quán)的訪問

漏洞等級分類

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

需要注意的是：

1、 對于在比特幣、以太坊等網(wǎng)絡(luò)上已上報的問題，賞金會相應(yīng)的折算。

2、 以上獎勵數(shù)額為該級別漏洞的最高獎勵數(shù)額，具體的獎勵發(fā)放數(shù)額會由QTUM安全團隊決定。

對于獎勵的發(fā)放我們還會參照其中幾項來進行評審，如僅上報漏洞者，只需要關(guān)注上報材料一項。

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

代碼修復(fù)（40%）：完成代碼修復(fù)，并不引入新的問題，如果有新的問題被引入，需要在同一次提交中解決該問題。

自動化測試腳本覆蓋或手動測試方法說明（15%）：自動化測試腳本對代碼的持續(xù)集成、快速迭代下的質(zhì)量控制有極其重要的作用，所以自動測試腳本的完善會作為一項重要的考核指標(biāo)：

提供自動化測試腳本

100%

提供手動測試說明

60%

修復(fù)時間與效率（20%）：修復(fù)時間指Issue上報被確認(rèn)后到修復(fù)代碼被review過后合到代碼庫間的時間，該時間會在Issue上報后QTUM安全團隊確認(rèn)漏洞的反饋郵件中明確期望修復(fù)時間，該時間會與開發(fā)者協(xié)商。

該部分獎勵說明：

期望時間內(nèi)完成

100%

超過期望時間50%內(nèi)70%

70%

超過期望時間50%外

50%

修復(fù)思路及方法介紹與文檔完善（15%）：對于修復(fù)完的漏洞，希望完成技術(shù)材料的整理與文檔的提交，具體請參見：Bug修復(fù)后提交材料模板

漏洞的上報與修復(fù)流程

報告階段

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

處理階段

1.一個工作日內(nèi)，QTUM安全團隊會確認(rèn)收到的漏洞報告并跟進開始評估問題， 同時將情報反饋給上報者(狀態(tài)：審核中)

2. 三個工作日內(nèi)，QTUM技術(shù)團隊處理問題、給出結(jié)論與期望完成時間(狀態(tài)：已確認(rèn)/已忽略)。必要時會與報告者溝通確認(rèn)，請報告者予以協(xié)助，評估完成后會將評估結(jié)果告知開發(fā)者。

修復(fù)階段

1. 提交者著手修復(fù)該安全漏洞(狀態(tài)：修復(fù)中)

2. 對于修復(fù)完成的問題，提交者可以將狀態(tài)改為（狀態(tài)：待復(fù)查）修復(fù)時間根據(jù)問題的嚴(yán)重程度及修復(fù)難度而定，一般來說，嚴(yán)重和高危問題 24 小時內(nèi)，中危問題七個工作日內(nèi)，低危問題十五個工作日內(nèi)。客戶端安全問題受版本發(fā)布限制，修復(fù)時間根據(jù)實際情況確定

3. QTUM安全團隊對問題進行復(fù)查，確認(rèn)修復(fù)后會告知提交者結(jié)論和漏洞得分(狀態(tài)：已復(fù)查/復(fù)查異議)

材料整理階段

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

賞金發(fā)放階段

QTUM安全團隊對提交人的材料完整性和修復(fù)完成度進行審核并發(fā)布獎勵(狀態(tài)：已結(jié)束)

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修復(fù)后提交材料模板

###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

總結(jié)

以上是生活随笔為你收集整理的Qtum量子链漏洞赏金计划正式开启的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。