Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

When patching packages, design how to track modifications

オープン
#158 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

@devansh6107 がすでに取り組んでいます。

2026年10月10日 から。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
領域
security

調査の方向性

まず、issue で挙げられている追跡場所の候補である ABOUT ファイル、DejaCode、PurlDB を確認し、次に、それらが影響を及ぼす下流の脆弱性処理およびバージョンマッチングのプロセスを追跡します。合意された設計によって、通常、セキュリティ、機能、メタデータ、名前変更、バージョンの変更を区別でき、誤検出や見逃しを生じさせる lookup を導入しなければ完了です。

索引モデルが issue の本文から書いたものです。

説明

When a package is modified locally in a codebase, we should be able track these modifications and how to identify them.

Why? Because a package may have been:

  1. patched for a regular bug
  2. patched for a security vulnerability
  3. patched for a new or altered feature
  4. updated for corrected metadata (such as origin, license, dependencies)
  5. renamed or its version changed (or not :] )

In all these cases, we may have some problems if we do not known about this:

  • we may report it as vulnerable when this is not the case
  • we may not report it as vulnerable when this is the case
  • we may match it it incorrectly to an upstream version or an altered version

Tracking could be done in ABOUT files, in DejaCode and the PurlDB and be used by downstream processes to avoid false negative and false positive lookups. This is especially important when we have renamed packages that are patched but where the original unpatched package and the patched version could be both vulnerable.

主要言語
Batchfile
スター
310
フォーク
255
平均マージ
10時間 5分
マージ済み PR(30日)
1

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

aboutcode-org/aboutcode のほかの issue

aboutcode-org/aboutcode の issue をすべて見る

似ている issue

Security の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。