Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Accuracy improvements for py/clear-text-logging-sensitive-data

未關閉
#21,595 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
52/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
冷清
技術堆疊
python
領域
security

研究方向

從 py/clear-text-logging-sensitive-data 查詢及其 taint-tracking 設定開始,接著追蹤 sanitizer 和 propagator 的定義方式。使用 issue 中的範例作為回歸案例,確認記錄 SecretStr 不會被標記,而記錄包含 secret 的例外會被標記。

由索引模型根據 Issue 內容生成。

描述

question

Description of the issue
Hey, I found two common cases where the rule doesn't match in my codebase. One creates noise, the other misses a real leak.

First, SecretStr masks text automatically (e.g., prints '**********'). Logging these objects is safe, but the rule flags them.

from pydantic import SecretStr

password = SecretStr("super_secret")
logging.info("Login: %s", password) # Flagged, but actually safe
  1. Logging an exception object leaks its message (via str), but the rule misses this if the secret is inside the exception.
secret_token = "secret_123"
# logging.error("Auth failed: %s", secret_token)  # Detected ✅
try:
    raise ValueError("Auth failed: {}".format(secret_token))
except ValueError as e:
    # Currently NOT flagged, but leaks 'secret_123' via __str__ ❌
    logging.error("Auth failed: %s", e)  

Maybe we should add the first pattern to the sanitizers and add the second one as a propagator in the taint tracking config.

主要語言
CodeQL
星號
10.1k
分支
2.1k
平均合併
2 天 16 小時
30 天內合併 PR
143

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

github/codeql 的其他 Issue

查看 github/codeql 的全部 Issue

相似的 Issue

更多 Security Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。