perlsecpolicy - Perl security report handling policy

perlsecpolicy - Perl セキュリティ報告処理ポリシー

(訳注: (TBR)がついている段落は「みんなの自動翻訳@TexTra®」による 機械翻訳です。)


The Perl project takes security issues seriously.

Perlプロジェクトはセキュリティの問題を真剣にとらえています。 (TBR)

The responsibility for handling security reports in a timely and effective manner has been delegated to a security team composed of a subset of the Perl core developers.

セキュリティレポートをタイムリーかつ効果的な方法で処理する責任は、Perlコア開発者のサブセットで構成されるセキュリティチームに委任されています。 (TBR)

This document describes how the Perl security team operates and how the team evaluates new security reports.

この文書では、Perlセキュリティチームの運用方法と、チームが新しいセキュリティレポートを評価する方法について説明します。 (TBR)


If you believe you have found a security vulnerability in the Perl interpreter or modules maintained in the core Perl codebase, email the details to perl-security@perl.org. This address is a closed membership mailing list monitored by the Perl security team.

コアPerlコードベースで管理されているPerlインタプリタまたはモジュールにセキュリティ上の脆弱性を発見したと思われる場合は、詳細を perl-security@perl.orgまで電子メールで送信してください。 このアドレスは、Perlセキュリティチームによって監視されている非公開の会員メーリングリストです。 (TBR)

You should receive an initial response to your report within 72 hours. If you do not receive a response in that time, please contact the Perl Steering Council.

レポートに対する最初の回答は72時間以内に届くはずです。 回答が得られない場合は、Perl Steering Councilまでお問い合わせください。 (TBR)

When members of the security team reply to your messages, they will generally include the perl-security@perl.org address in the "To" or "CC" fields of the response. This allows all of the security team to follow the discussion and chime in as needed. Use the "Reply-all" functionality of your email client when you send subsequent responses so that the entire security team receives the message.

セキュリティチームのメンバーがメッセージに返信する場合、通常、返信の「To」または「CC」フィールドにperl-security@perl.orgアドレスを含めます。 これにより、セキュリティチーム全員がディスカッションに従い、必要に応じて参加できます。 後続の返信を送信する場合は、Eメールクライアントの「全員に返信」機能を使用して、セキュリティチーム全体がメッセージを受信できるようにします。 (TBR)

The security team will evaluate your report and make an initial determination of whether it is likely to fit the scope of issues the team handles. General guidelines about how this is determined are detailed in the "WHAT ARE SECURITY ISSUES" section.

セキュリティチームはレポートを評価し、チームが扱う問題の範囲に適合する可能性が高いかどうかを最初に判断します。 この判断方法に関する一般的なガイドラインについては、"WHAT ARE SECURITY ISSUES" セクションで詳しく説明しています。 (TBR)

If your report meets the team's criteria, an issue will be opened in the team's private issue tracker and you will be provided the issue's ID number. Issue identifiers have the form perl-security#NNN. Include this identifier with any subsequent messages you send.

レポートがチームの基準を満たしている場合、チームのプライベート懸案事項追跡ツールで懸案事項がオープンされ、懸案事項のID番号が提供されます。 懸案事項IDの形式はperl-security#NNNです。 後続の送信メッセージにはこのIDを含めてください。 (TBR)

The security team will send periodic updates about the status of your issue and guide you through any further action that is required to complete the vulnerability remediation process. The stages vulnerabilities typically go through are explained in the "HOW WE DEAL WITH SECURITY ISSUES" section.

セキュリティチームは、お客様の問題のステータスに関する最新情報を定期的に送信し、脆弱性修復プロセスを完了するために必要な追加アクションを案内します。 脆弱性が一般的に経験する段階については、"HOW WE DEAL WITH SECURITY ISSUES" セクションで説明されています。 (TBR)


A vulnerability is a behavior of a software system that compromises the system's expected confidentiality, integrity or availability protections.

脆弱性とは、ソフトウェアシステム期待される機密性、完全性、可用性の保護を損なうソフトウェアシステムの動作のことです。 (TBR)

A security issue is a bug in one or more specific components of a software system that creates a vulnerability.

セキュリティ問題とは、ソフトウェアシステムの1つまたは複数の特定コンポーネントに存在するバグで、脆弱性を引き起こすものです。 (TBR)

Software written in the Perl programming language is typically composed of many layers of software written by many different groups. It can be very complicated to determine which specific layer of a complex real-world application was responsible for preventing a vulnerable behavior, but this is an essential part of fixing the vulnerability.

Perlプログラミング言語で書かれたソフトウェアは、一般に、多くの異なるグループによって書かれたソフトウェアの多くの層から構成されています。 複雑な実世界アプリケーションのどの特定の層が脆弱な動作を防止したのかを判断するのは非常に複雑な場合がありますが、これは脆弱性を修正するために不可欠な部分です。 (TBR)

Software covered by the Perl security team

The Perl security team handles security issues in:

Perlセキュリティチームは、次のセキュリティ問題を処理します。 (TBR)

  • The Perl interpreter

    Perlインタープリター (TBR)

  • The Perl modules shipped with the interpreter that are developed in the core Perl repository

    インタープリターに同梱され、コアPerlリポジトリーで開発されたPerlモジュール (TBR)

  • The command line tools shipped with the interpreter that are developed in the core Perl repository

    インタープリターに付属し、コアPerlリポジトリーで開発されたコマンドラインツール (TBR)

Files under the cpan/ directory in Perl's repository and release tarballs are developed and maintained independently. The Perl security team does not handle security issues for these modules.

Perlのリポジトリーおよびリリースtarball内のcpan/ディレクトリー下のファイルは、独立して開発および保守されています。 Perlセキュリティチームは、これらのモジュールのセキュリティ問題を処理しません。 (TBR)

Bugs that may qualify as security issues in Perl

Perl is designed to be a fast and flexible general purpose programming language. The Perl interpreter and Perl modules make writing safe and secure applications easy, but they do have limitations.

Perlは、高速で柔軟な汎用プログラミング言語として設計されています。 PerlインタープリターとPerlモジュールによって、安全でセキュアなアプリケーションを簡単に作成することができますが、制限があります。 (TBR)

As a general rule, a bug in Perl needs to meet all of the following criteria to be considered a security issue:

一般的な規則として、Perlのバグがセキュリティ問題と見なされるためには、次の基準をすべて満たす必要があります。 (TBR)

  • The vulnerable behavior is not mentioned in Perl's documentation or public issue tracker.

    脆弱性の振る舞いについては、Perlのドキュメントや公開問題追跡ツールには記載されていません。 (TBR)

  • The vulnerable behavior is not implied by an expected behavior.

    脆弱な振る舞いは、期待される振る舞いによって暗示されるものではない。 (TBR)

  • The vulnerable behavior is not a generally accepted limitation of the implementation.

    脆弱な振る舞いは、一般的に受け入れられている実装の制限ではありません。 (TBR)

  • The vulnerable behavior is likely to be exposed to attack in otherwise secure applications written in Perl.

    Perlで作成されたセキュアなアプリケーションでは、脆弱な振る舞いが攻撃にさらされる可能性があります。 (TBR)

  • The vulnerable behavior provides a specific tangible benefit to an attacker that triggers the behavior.

    脆弱な動作は、その動作をトリガーする攻撃者に具体的な利益を提供します。 (TBR)

Bugs that do not qualify as security issues in Perl

There are certain categories of bugs that are frequently reported to the security team that do not meet the criteria listed above.

上記の基準を満たさない、セキュリティチームに頻繁に報告される特定のカテゴリのバグがあります。 (TBR)

The following is a list of commonly reported bugs that are not handled as security issues.

一般的に報告され、セキュリティ問題として扱われないバグのリストを以下に示します。 (TBR)

Feeding untrusted code to the interpreter

The Perl parser is not designed to evaluate untrusted code. If your application requires the evaluation of untrusted code, it should rely on an operating system level sandbox for its security.

Perlパーサーは、信頼できないコードを評価するようには設計されていません。 アプリケーションで信頼できないコードの評価が必要な場合は、セキュリティをオペレーティングシステムレベルのサンドボックスに依存する必要があります。 (TBR)

Stack overflows due to excessive recursion

Excessive recursion is often caused by code that does not enforce limits on inputs. The Perl interpreter assumes limits on recursion will be enforced by the application.

過度の再帰は、多くの場合、入力に制限を適用しないコードによって引き起こされます。 Perlインタプリタは、アプリケーションによって再帰の制限が適用されることを想定しています。 (TBR)

Out of memory errors

Common Perl constructs such as pack, the x operator, and regular expressions accept numeric quantifiers that control how much memory will be allocated to store intermediate values or results. If you allow an attacker to supply these quantifiers and consume all available memory, the Perl interpreter will not prevent it.

packx演算子、正規表現などの一般的なPerl構文では、中間値または結果を格納するために割り当てられるメモリーの量を制御する数値限定子を使用できます。 攻撃者がこれらの限定子を提供し、使用可能なメモリーをすべて消費することを許可した場合、Perlインタプリタはこれを防止できません。 (TBR)

Escape from a Safe compartment

Opcode restrictions and Safe compartments are not supported as security mechanisms. The Perl parser is not designed to evaluate untrusted code.

Opcode制限およびSafeコンパートメントはセキュリティメカニズムとしてサポートされていません。 Perlパーサーは、信頼できないコードを評価するようには設計されていません。 (TBR)

Use of the p and P pack templates

These templates are unsafe by design.

これらのテンプレートは、設計上安全ではありません。 (TBR)

Stack not reference-counted issues

These bugs typically present as use-after-free errors or as assertion failures on the type of a SV. Stack not reference-counted crashes usually occur because code is both modifying a reference or glob and using the values referenced by that glob or reference.

これらのバグは通常、use-after-freeエラーやSV型のアサーションエラーとして存在する。 参照カウントされないスタックのクラッシュは通常、コードが参照またはglobを修正し、そのglobまたはreferenceによって参照される値を使用しているために発生する。 (TBR)

This type of bug is a long standing issue with the Perl interpreter that seldom occurs in normal code. Examples of this type of bug generally assume that attacker-supplied code will be evaluated by the Perl interpreter.

この種のバグは、通常のコードではめったに発生しないPerlインタープリターの長年の問題です。 この種のバグの例では、攻撃者が提供したコードがPerlインタープリターによって評価されることが一般的に想定されています。 (TBR)

Thawing attacker-supplied data with Storable

Storable is designed to be a very fast serialization format. It is not designed to be safe for deserializing untrusted inputs.

Storableは、非常に高速なシリアライゼーションフォーマットとして設計されています。 信頼できない入力をデシリアライゼーションするために安全に設計されていません。 (TBR)

Using attacker supplied SDBM_File databases

The SDBM_File module is not intended for use with untrusted SDBM databases.

SDBM_Fileモジュールは、信頼できないSDBMデータベースで使用することを意図していません。 (TBR)

Badly encoded UTF-8 flagged scalars

This type of bug occurs when the :utf8 PerlIO layer is used to read badly encoded data, or other mechanisms are used to directly manipulate the UTF-8 flag on an SV.

このタイプのバグは、:utf8PerlIOレイヤーが不正にエンコードされたデータを読み取るために使用される場合、または他のメカニズムがSV上のUTF-8フラグを直接操作するために使用される場合に発生します。 (TBR)

A badly encoded UTF-8 flagged SV is not a valid SV. Code that creates SV's in this fashion is corrupting Perl's internal state.

正しくエンコードされていないUTF-8フラグ付きSVは有効なSVではありません。 このようにSVを作成するコードは、Perlの内部状態を破壊しています。 (TBR)

Issues that exist only in blead, or in a release candidate

The blead branch and Perl release candidates do not receive security support. Security defects that are present only in pre-release versions of Perl are handled through the normal bug reporting and resolution process.

BleadブランチおよびPerlリリース候補はセキュリティサポートを受けていません。 Perlのプレリリースバージョンにのみ存在するセキュリティ上の欠陥は、通常のバグ報告および解決プロセスによって処理されます。 (TBR)

CPAN modules or other Perl project resources

The Perl security team is focused on the Perl interpreter and modules maintained in the core Perl codebase. The team has no special access to fix CPAN modules, applications written in Perl, Perl project websites, Perl mailing lists or the Perl IRC servers.

Perlセキュリティチームは、コアPerlコードベースで管理されているPerlインタープリターとモジュールに重点を置いています。 CPANモジュール、Perlで作成されたアプリケーション、PerlプロジェクトのWebサイト、Perlメーリングリスト、またはPerl IRCサーバーを修正するための特別なアクセス権はありません。 (TBR)

Emulated POSIX behaviors on Windows systems

The Perl interpreter attempts to emulate fork, system, exec and other POSIX behaviors on Windows systems. This emulation has many quirks that are extensively documented in Perl's public issue tracker. Changing these behaviors would cause significant disruption for existing users on Windows.

Perlインタプリタは、Windowsシステム上でforksystemexecおよびその他のPOSIX動作をエミュレートしようとします。 このエミュレーションには、Perlのpublic issue trackerに詳細に記述されている多くの癖があります。 これらの挙動を変更すると、Windows上の既存ユーザーに重大な混乱を引き起こす可能性があります。 (TBR)

Bugs that require special categorization

Some bugs in the Perl interpreter occur in areas of the codebase that are both security sensitive and prone to failure during normal usage.

Perlインタープリターのバグの中には、セキュリティに敏感であり、通常の使用中に障害を起こしやすいコードベースの領域で発生するものがあります。 (TBR)

Regular expressions

Untrusted regular expressions are generally safe to compile and match against with several caveats. The following behaviors of Perl's regular expression engine are the developer's responsibility to constrain.

信頼できない正規表現は一般的に安全にコンパイルし、いくつかの警告を付けてマッチさせることができます。 Perlの正規表現エンジンの以下の動作は、開発者が制約する責任があります。 (TBR)

The evaluation of untrusted regular expressions while use re 'eval'; is in effect is never safe.

use re 'eval';が有効な状態で信頼できない正規表現を評価することは、決して安全ではありません。 (TBR)

Regular expressions are not guaranteed to compile or evaluate in any specific finite time frame.

正規表現は、特定の有限時間フレームでコンパイルや評価を行うことが保証されていません。 (TBR)

Regular expressions may consume all available system memory when they are compiled or evaluated.

正規表現は、コンパイル時または評価時に使用可能なシステムメモリをすべて消費する可能性があります。 (TBR)

Regular expressions may cause excessive recursion that halts the perl interpreter.

正規表現は、Perlインタプリタを停止させる過度の再帰を引き起こす可能性があります。 (TBR)

As a general rule, do not expect Perl's regular expression engine to be resistant to denial of service attacks.

一般的なルールとして、Perlの正規表現エンジンがサービス拒否攻撃に対して耐性があると期待しないでください。 (TBR)

DB_File, ODBM_File, or GDBM_File databases

These modules rely on external libraries to interact with database files.

これらのモジュールは、外部ライブラリに依存してデータベースファイルを操作します。 (TBR)

Bugs caused by reading and writing these file formats are generally caused by the underlying library implementation and are not security issues in Perl.

これらのファイルフォーマットの読み書きによって引き起こされるバグは、一般的に基礎となるライブラリー実装によって引き起こされ、Perlにおけるセキュリティ問題ではありません。 (TBR)

Bugs where Perl mishandles unexpected valid return values from the underlying libraries may qualify as security issues in Perl.

Perlが基礎となるライブラリーから予期しない有効な戻り値を誤って処理するバグは、Perlのセキュリティ問題と見なされる可能性があります。 (TBR)

Algorithmic complexity attacks

The perl interpreter is reasonably robust to algorithmic complexity attacks. It is not immune to them.

Perlインタープリターは、アルゴリズムの複雑さによる攻撃に対して適度に堅牢であり、それらに免疫がないわけではありません。 (TBR)

Algorithmic complexity bugs that depend on the interpreter processing extremely large amounts of attacker supplied data are not generally handled as security issues.

アルゴリズムの複雑さのバグは、攻撃者から提供された非常に大量のデータを処理するインタプリタに依存しており、一般にセキュリティ問題として扱われません。 (TBR)

See "Algorithmic Complexity Attacks" in perlsec for additional information.

詳細については、"Algorithmic Complexity Attacks" in perlsecを参照してください。 (TBR)


The Perl security team follows responsible disclosure practices. Security issues are kept secret until a fix is readily available for most users. This minimizes inherent risks users face from vulnerabilities in Perl.

Perlセキュリティチームは、責任ある情報開示慣行に従います。 セキュリティ問題は、ほとんどのユーザーが修正プログラムをすぐに入手できるようになるまで秘密にされます。 これにより、Perlの脆弱性によってユーザーが直面する固有のリスクを最小限に抑えることができます。 (TBR)

Hiding problems from the users temporarily is a necessary trade-off to keep them safe. Hiding problems from users permanently is not the goal.

ユーザーから一時的に問題を隠すことは、ユーザーを安全に保つために必要なトレードオフです。 ユーザーから問題を永久に隠すことが目的ではありません。 (TBR)

When you report a security issue privately to the perl-security@perl.org contact address, we normally expect you to follow responsible disclosure practices in the handling of the report. If you are unable or unwilling to keep the issue secret until a fix is available to users you should state this clearly in the initial report.

セキュリティ問題をperl-security@perl.org連絡先アドレスに非公開で報告する場合、通常、報告の処理において責任ある開示慣行に従うことが求められます。 ユーザーが修正を入手できるようになるまで問題を非公開にすることができない、またはする意思がない場合は、最初の報告でそのことを明確に述べる必要があります。 (TBR)

The security team's vulnerability remediation workflow is intended to be as open and transparent as possible about the state of your security report.

セキュリティチームの脆弱性修復ワークフローは、セキュリティレポートの状態について可能な限りオープンで透明性のあるものにすることを目的としています。 (TBR)

Perl's vulnerability remediation workflow

Initial contact

New vulnerability reports will receive an initial reply within 72 hours from the time they arrive at the security team's mailing list. If you do not receive any response in that time, contact the Perl Steering Council.

新しい脆弱性レポートは、セキュリティチームのメーリングリストに到着してから72時間以内に最初の返信を受け取ります。 その間に返信がない場合は、Perl Steering Councilに連絡してください。 (TBR)

The initial response sent by the security team will confirm your message was received and provide an estimated time frame for the security team's triage analysis.

セキュリティチームから送信された最初の応答は、メッセージが受信されたことを確認し、セキュリティチームのトリアージ分析のための推定時間枠を提供します。 (TBR)

Initial triage

The security team will evaluate the report and determine whether or not it is likely to meet the criteria for handling as a security issue.

セキュリティチームはレポートを評価し、セキュリティ問題として処理するための基準を満たす可能性があるかどうかを判断します。 (TBR)

The security team aims to complete the initial report triage within two weeks' time. Complex issues that require significant discussion or research may take longer.

セキュリティチームは、2週間以内に最初のレポートトリアージを完了することを目指しています。 重要な議論や調査を必要とする複雑な問題には、さらに時間がかかる場合があります。 (TBR)

If the security report cannot be reproduced or does not meet the team's criteria for handling as a security issue, you will be notified by email and given an opportunity to respond.

セキュリティレポートを複製できない場合、またはセキュリティ問題として処理するチームの基準を満たしていない場合は、電子メールで通知され、回答する機会が与えられます。 (TBR)

Issue ID assignment

Security reports that pass initial triage analysis are turned into issues in the security team's private issue tracker. When a report progresses to this point you will be provided the issue ID for future reference. These identifiers have the format perl-security#NNN or Perl/perl-security#NNN.

初期トリアージ分析に合格したセキュリティレポートは、セキュリティチームのプライベートな問題追跡ツールで問題に変換されます。 この時点までレポートが進行すると、後で参照できるように問題IDが提供されます。 これらの識別子のフォーマットはperl-security#NNNまたはPerl/perl-security#NNNです。 (TBR)

The assignment of an issue ID does not confirm that a security report represents a vulnerability in Perl. Many reports require further analysis to reach that determination.

イシューIDの割り当ては、セキュリティレポートがPerlの脆弱性を表していることを確認するものではありません。 多くのレポートでは、その決定に到達するためにさらなる分析が必要です。 (TBR)

Issues in the security team's private tracker are used to collect details about the problem and track progress towards a resolution. These notes and other details are not made public when the issue is resolved. Keeping the issue notes private allows the security team to freely discuss attack methods, attack tools, and other related private issues.

セキュリティチームのプライベートトラッカー内の問題は、問題の詳細を収集し、解決に向けた進捗を追跡するために使用されます。 これらのメモおよびその他の詳細は、問題が解決されたときに公開されません。 問題のメモを非公開にすると、セキュリティチームは攻撃方法、攻撃ツールおよびその他の関連する非公開の問題について自由に議論できます。 (TBR)

Development of patches

Members of the security team will inspect the report and related code in detail to produce fixes for supported versions of Perl.

セキュリティチームのメンバーは、レポートと関連コードを詳細に調査し、サポートされているバージョンのPerlに対する修正を作成します。 (TBR)

If the team discovers that the reported issue does not meet the team's criteria at this stage, you will be notified by email and given an opportunity to respond before the issue is closed.

報告された問題がこの段階でチームの基準を満たしていないことをチームが発見した場合は、問題が解決される前に電子メールで通知され、回答する機会が与えられます。 (TBR)

The team may discuss potential fixes with you or provide you with patches for testing purposes during this time frame. No information should be shared publicly at this stage.

この期間中、チームは潜在的な修正についてお客様と話し合うか、テスト目的のパッチをお客様に提供する場合があります。 現段階では、情報を公に共有すべきではない。 (TBR)

CVE ID assignment

Once an issue is fully confirmed and a potential fix has been found, the security team will request a CVE identifier for the issue to use in public announcements.

問題が完全に確認され、潜在的な修正が発見されると、セキュリティチームは、公式発表で使用するために、問題のCVE識別子を要求する。 (TBR)

Details like the range of vulnerable Perl versions and identities of the people that discovered the flaw need to be collected to submit the CVE ID request.

CVE IDリクエストを送信するためには、脆弱なPerlバージョンの範囲や、脆弱性を発見した人物の身元などの詳細を収集する必要がある。 (TBR)

The security team may ask you to clarify the exact name we should use when crediting discovery of the issue. The "Vulnerability credit and bounties" section of this document explains our preferred format for this credit.

セキュリティチームは、問題が発見されたことを証明する際に使用すべき正確な名前を明確にするようお願いする場合があります。 このドキュメントの"Vulnerability credit and bounties"セクションでは、このクレジットの推奨形式について説明しています。 (TBR)

Once a CVE ID has been assigned, you will be notified by email. The vulnerability should not be discussed publicly at this stage.

CVE IDが割り当てられると、メールで通知されます。 現段階では、この脆弱性について公に議論すべきではない。 (TBR)

Pre-release notifications

When the security team is satisfied that the fix for a security issue is ready to release publicly, a pre-release notification announcement is sent to the major redistributors of Perl.

セキュリティチームがセキュリティ問題の修正を公開する準備ができていると判断した場合、Perlの主要な再配布者にリリース前の通知が送信されます。 (TBR)

This pre-release announcement includes a list of Perl versions that are affected by the flaw, an analysis of the risks to users, patches the security team has produced, and any information about mitigations or backporting fixes to older versions of Perl that the security team has available.

このプレリリース発表には、脆弱性の影響を受けるPerlバージョンのリスト、ユーザーに対するリスクの分析、セキュリティチームが作成したパッチ、セキュリティチームが入手可能な旧バージョンのPerlへの緩和策やバックポート修正に関する情報などが含まれている。 (TBR)

The pre-release announcement will include a specific target date when the issue will be announced publicly. The time frame between the pre-release announcement and the release date allows redistributors to prepare and test their own updates and announcements. During this period the vulnerability details and fixes are embargoed and should not be shared publicly. This embargo period may be extended further if problems are discovered during testing.

プレリリースの発表には、問題が公式に発表される具体的な目標日が含まれます。 プレリリースの発表からリリース日までの時間枠により、再配布者は独自のアップデートと発表を準備してテストすることができます。 この期間中、脆弱性の詳細と修正は禁止され、公開されません。 テスト中に問題が発見された場合は、この禁止期間がさらに延長されることがあります。 (TBR)

You will be sent the portions of pre-release announcements that are relevant to the specific issue you reported. This email will include the target release date. Additional updates will be sent if the target release date changes.

お客様が報告された特定の問題に関連するプレリリース発表の一部がお客様に送信されます。 このEメールには、リリース予定日が記載されます。 リリース予定日が変更された場合は、追加の更新情報が送信されます。 (TBR)

Pre-release testing

The Perl security team does not directly produce official Perl releases. The team releases security fixes by placing commits in Perl's public git repository and sending announcements.

Perlセキュリティチームは、公式のPerlリリースを直接作成することはありません。 チームは、Perlの公開gitリポジトリにコミットを配置し、アナウンスを送信することによってセキュリティ修正をリリースします。 (TBR)

Many users and redistributors prefer using official Perl releases rather than applying patches to an older release. The security team works with Perl's release managers to make this possible.

多くのユーザーや再配布者は、古いリリースにパッチを適用するよりも、正式なPerlリリースを使用したいと考えています。 セキュリティチームは、Perlのリリースマネージャーと協力して、これを可能にしています。 (TBR)

New official releases of Perl are generally produced and tested on private systems during the pre-release embargo period.

Perlの新しい公式リリースは、一般的に、リリース前の禁輸期間中にプライベートシステムで作成され、テストされます。 (TBR)

Release of fixes and announcements

At the end of the embargo period the security fixes will be committed to Perl's public git repository and announcements will be sent to the perl5-porters and oss-security mailing lists.

禁輸期間の終わりに、セキュリティ修正はPerlの公開gitリポジトリにコミットされ、発表は perl5-portersoss-securityメーリングリストに送られます。 (TBR)

If official Perl releases are ready, they will be published at this time and announced on the perl5-porters mailing list.

Perlの公式リリースが準備できていれば、この時点で公開され、perl5-portersメーリングリストで発表されます。 (TBR)

The security team will send a follow-up notification to everyone that participated in the pre-release embargo period once the release process is finished. Vulnerability reporters and Perl redistributors should not publish their own announcements or fixes until the Perl security team's release process is complete.

セキュリティチームは、リリースプロセスが完了すると、リリース前の禁輸期間に参加したすべての人にフォローアップ通知を送信します。 脆弱性レポーターとPerl再配布者は、Perlセキュリティチームのリリースプロセスが完了するまで、独自の発表や修正を公開しないでください。 (TBR)

Publicly known and zero-day security issues

The security team's vulnerability remediation workflow assumes that issues are reported privately and kept secret until they are resolved. This isn't always the case and information occasionally leaks out before a fix is ready.

セキュリティチームの脆弱性修復ワークフローでは、問題がプライベートに報告され、解決されるまで秘密に保持されることを前提としています。 必ずしもそうとは限りませんが、修正の準備が整う前に情報が漏れることがあります。 (TBR)

In these situations the team must decide whether operating in secret increases or decreases the risk to users of Perl. In some cases being open about the risk a security issue creates will allow users to defend against it, in other cases calling attention to an unresolved security issue will make it more likely to be misused.

このような状況では、チームはシークレットで操作することがPerlユーザーのリスクを増加させるのか減少させるのかを決定しなければなりません。 セキュリティ問題が引き起こすリスクについてオープンであることで、ユーザーがそれを防御できる場合もあれば、未解決のセキュリティ問題に注意を喚起することで、悪用される可能性が高くなる場合もあります。 (TBR)

Zero-day security issues

If an unresolved critical security issue in Perl is being actively abused to attack systems the security team will send out announcements as rapidly as possible with any mitigations the team has available.

Perlの未解決の重大なセキュリティ問題が攻撃システムに積極的に悪用されている場合、セキュリティチームは、チームが利用可能な緩和策とともに、できるだけ迅速にアナウンスを送信します。 (TBR)

Perl's public defect tracker will be used to handle the issue so that additional information, fixes, and CVE IDs are visible to affected users as rapidly as possible.

Perlの公開欠陥追跡ツールを使用してこの問題を処理し、影響を受けたユーザーが追加情報、修正、CVE IDをできるだけ早く確認できるようにします。 (TBR)

Other leaks of security issue information

Depending on the prominence of the information revealed about a security issue and the issue's risk of becoming a zero-day attack, the security team may skip all or part of its normal remediation workflow.

セキュリティ問題について明らかにされた情報の重要性と、その問題が0デイ攻撃になるリスクに応じて、セキュリティチームは通常の修復ワークフローの全部または一部を省略する場合があります。 (TBR)

If the security team learns of a significant security issue after it has been identified and resolved in Perl's public issue tracker, the team will request a CVE ID and send an announcement to inform users.

セキュリティチームは、Perlのパブリックイシュートラッカーで特定され解決された後に重大なセキュリティ問題を知った場合、CVE IDを要求し、ユーザに通知するアナウンスを送信します。 (TBR)

Vulnerability credit and bounties

The Perl project appreciates the effort security researchers invest in making Perl safe and secure.

Perlプロジェクトは、セキュリティ研究者がPerlを安全でセキュアなものにするために投資した努力を高く評価しています。 (TBR)

Since much of this work is hidden from the public, crediting researchers publicly is an important part of the vulnerability remediation process.

この作業の多くは一般に公開されていないため、研究者への公的な信用供与は、脆弱性修復プロセスの重要な部分である。 (TBR)

Credits in vulnerability announcements

When security issues are fixed we will attempt to credit the specific researcher(s) that discovered the flaw in our announcements.

セキュリティ問題が修正された場合、我々は、我々の発表でこの欠陥を発見した特定の研究者を信用するよう試みる。 (TBR)

Credits are announced using the researcher's preferred full name.

クレジットは研究者のフルネームで発表されます。 (TBR)

If the researcher's contributions were funded by a specific company or part of an organized vulnerability research project, we will include a short name for this group at the researcher's request.

研究者の貢献が特定の企業または組織された脆弱性研究プロジェクトの一部から資金提供を受けた場合は、研究者の要請に応じて、このグループの略称を含める。 (TBR)

Perl's announcements are written in the English language using the 7bit ASCII character set to be reproducible in a variety of formats. We do not include hyperlinks, domain names or marketing material with these acknowledgments.

Perlの発表は、さまざまなフォーマットで再現できるように、7ビットASCII文字セットを使用して英語で書かれています。 ハイパーリンク、ドメイン名、マーケティング資料は、これらの謝辞に含まれていません。 (TBR)

In the event that proper credit for vulnerability discovery cannot be established or there is a disagreement between the Perl security team and the researcher about how the credit should be given, it will be omitted from announcements.

脆弱性発見のための適切なクレジットが確立できない場合や、クレジットをどのように与えるべきかについてPerlセキュリティチームと研究者の間で意見の相違がある場合には、発表から除外されます。 (TBR)

Bounties for Perl vulnerabilities

The Perl project is a non-profit volunteer effort. We do not provide any monetary rewards for reporting security issues in Perl.

Perlプロジェクトは非営利のボランティア活動です。 Perlでセキュリティ問題を報告することに対して金銭的な報酬は提供しません。 (TBR)

The Internet Bug Bounty offers monetary rewards for some Perl security issues after they are fully resolved. The terms of this program are available at HackerOne.

Internet Bug Bountyは、Perlのセキュリティ問題が完全に解決された後に金銭的な報酬を提供します。 このプログラムの条件はHackerOneで入手できます。 (TBR)

This program is not run by the Perl project or the Perl security team.

このプログラムは、PerlプロジェクトやPerlセキュリティチームによって実行されるものではありません。 (TBR)