취약점 보고

모든 알려진 그리고 드러난 curl 또는 libcurl 관련 취약점은 curl 웹 사이트 보안 페이지에 나열되어 있다.

보안 취약점은 보고자와 프로젝트의 보안 팀에게만 이슈에 대한 액세스를 제한하기 위해서 필요한 구성이 마련되지 않은 경우 프로젝트의 공용 버그 추적기에 입력해서는 안된다.

취약점 처리

새로운 보안 취약점을 처리하는 일반적인 프로세스는 다음과 같다.

이 프로세스가 끝날 때 정식으로 발표될 때까지 취약점에 대한 정보를 공개해서는 안된다. 이것은 예를 들어, 버그 트래커 항목은 이슈를 공개해야 하기 때문에 이슈를 추적하기 위해서 만들어져서는 안되며, 프로젝트의 공개 메일링 리스트에서 논의해서는 안된다. 또한 커밋과 관련된 메시지는 공개 발표 이전에 커밋의 보안 특성에 대해 언급하지 않아야 한다.

The person discovering the issue, the reporter, reports the vulnerability privately to [email protected]. That's an e-mail alias that reaches a handful of selected and trusted people.

Messages that do not relate to the reporting or managing of an undisclosed security vulnerability in curl or libcurl are ignored and no further action is required.

A person in the security team sends an e-mail to the original reporter to acknowledge the report.

The security team investigates the report and either rejects it or accepts it.

If the report is rejected, the team writes to the reporter to explain why.

If the report is accepted, the team writes to the reporter to let him/her know it is accepted and that they are working on a fix.

The security team discusses the problem, works out a fix, considers the impact of the problem and suggests a release schedule. This discussion should involve the reporter as much as possible.

The release of the information should be "as soon as possible" and is most often synced with an upcoming release that contains the fix. If the reporter, or anyone else, thinks the next planned release is too far away then a separate earlier release for security reasons should be considered.

Write a security advisory draft about the problem that explains what the problem is, its impact, which versions it affects, any solutions or workarounds and when the fix was released, making sure to credit all contributors properly.

Request a CVE number from distros@openwall when also informing and preparing them for the upcoming public security vulnerability announcement?attach the advisory draft for information. Note that 'distros' won't accept an embargo longer than 19 days.

Update the "security advisory" with the CVE number.

The security team commits the fix in a private branch. The commit message should ideally contain the CVE number. This fix is usually also distributed to the 'distros' mailing list to allow them to use the fix prior to the public announcement.

At the day of the next release, the private branch is merged into the master branch and pushed. Once pushed, the information is accessible to the public and the actual release should follow suit immediately afterwards.

The project team creates a release that includes the fix.

The project team announces the release and the vulnerability to the world in the same manner we always announce releases?it gets sent to the curl-announce, curl-library and curl-users mailing lists.

The security web page on the web site should get the new vulnerability mentioned.

[email protected]

이 리스트에 있는 사람은 누구인가? 몇 가지 기준을 충족시켜야 하며, 그 다음 우리는 리스트에 가입하기 위해서 당신에게 질문을 하거나 당신이 갑입하기 위해서 질문 할 수 있다. 정말 공식적인 것은 아니다. 우리는 단지 기본적으로 curl 프로젝트에 장기간 존재할 것을 요구하고 프로젝트와 그 작업 방식에 대한에 대한 이해를 보여주었다. 당신은 좋은 시간 동안 주변에 있었음에 틀림 없으며, 근 시일내에 사라질 계획이 없어야 한다.

우리는 참가자들의 리스트를 공개하지 않는다. 왜냐하면, 시간이 지남에 따라 다소 다양하며, 어딘가의 리스트는 구식이 될 위험이 있기 때문이다.