Repository navigation
Request a safe private follow-up path for pending security reports #4073
Description
Activity
리뷰 · 우선순위 78 / 80
설명
이 이슈는 코드 버그 신고가 아니라, 이미 넣어 둔 GitHub 비공개 보안 제보에 대한 안전한 후속 창구를 공개 이슈로만 짧게 확인해 달라는 요청이다. 작성자 luvs01, 라벨
documentation. 본문에는 취약점 재현·시크릿·타깃이 없고, “몇 주째 비공개 채널에서 보이는 메인테이너 응답이 없다”는 조율만 적혀 있다. 지금 로컬devHEAD는8026405d9(#4067), package 2.49.0이다. types/config 분할·preview·구현 PR과는 무관하다.저장소 정책과 맞는지부터 보면, 루트
SECURITY.md가 정확히 이 상황을 안내한다. 미공개 취약점은 공개 이슈에 쓰지 말고 GitHub private vulnerability reporting(.../security/advisories/new)만 쓰라고 적혀 있다. 전용 보안 메일 주소는 없다. 그리고 “폼에 닿지 못할 때”만이 아니라, 조율이 막혔을 때도 최소 공개 이슈로 안전한 경로만 물어보라고 한다. 기술 토론은 비공개 제보 안에 남기라고 했고, 이 이슈 본문은 그 규칙을 지키고 있다. 즉 작성자 행동은 정책 준수이고, 막힌 쪽은 메인테이너 쪽 응답 SLA/확인이다.왜 우선순위가 높은가. 공개 버그 백로그(#3719 등)와 달리, 이미 들어온 비공개 제보가 응답 없이 쌓이면 (1) 제보자가 공개 이슈로 기술 내용을 옮기려는 유혹이 생기고, (2) 공개 전 수정 창이 줄어들며, (3)
SECURITY.md의 “best-effort 검토” 약속이 문서만으로 남는다. 이 이슈 자체에 패치 코드는 없다. 필요한 산출물은 코드가 아니라 비공개 채널에서의 수신 확인 + 담당/다음 창구 한 줄이다. 공개 댓글에도 기술 세부·advisory 번호·재현을 적지 않는 편이 맞다. “비공개 제보 쪽에서 확인했다 / Security 탭 advisory로만 이어가자” 정도가 공개에 남길 말의 상한이다.문서 개선이 필요한지도 같이 보면 좋다. 지금
SECURITY.md의 Response Expectations는 검토 단계(버전 확인·재현·영향·공개 시점)만 있고, 첫 응답까지 대략 며칠을 목표로 하는지, 제보자가 기다리다 막혔을 때 공개 이슈에 무엇을 적어도 되는지가 한 문단으로 더 있으면 같은 조율 이슈가 반복되지 않는다. 다만 그 문서 보강은 이번 조율과 별개로 작은 follow-up이면 충분하고, 지금 당장 막힌 일은 “대기 중인 비공개 제보를 누가 열어볼지”다.라인 - 이게 무슨 문제다
경로
SECURITY.mdReporting a Vulnerability - private advisory 폼이 유일한 채널이라고 명시한다. 작성자는 이미 그 채널을 썼고, 공개 이슈에는 조율만 남겼다. 정책 위반 아님.경로
SECURITY.mdResponse Expectations - 검토 단계는 있으나 첫 응답 목표 시간·막혔을 때 공개 이슈 문구 예시가 없다. 문서 보강 후보.경로 공개 이슈 본문 - 기술 세부 없음. 유지해야 한다. 공개 댓글에도 advisory ID·PoC·시크릿을 붙이지 말 것.
경로 구현/패치 - 이 번호로는 코드 PR이 없다. 닫을 조건은 “비공개에서 수신 확인 + 후속 경로 합의”이지 머지가 아니다.
경로 관련 백로그 - #4069 콘솔 스팸, usage 하드닝 PR 등과 축이 다르다. 보안 조율 이슈를 일반 documentation 배치에 묻지 말 것.
메인테이너의 판단이 필요한 지점
- 대기 중인 private advisory를 지금 누가 열어보고 첫 응답을 할지(메인테이너 본인 / 위임).
- 공개 이슈에 남길 문구 수준: “비공개에서 확인함”만인지, 문서에 첫 응답 목표 일수를 추가할지.
- 이 공개 이슈를 조율 완료 후 close할지,
SECURITY.md보강 PR이 올라올 때까지 열어 둘지.
너의 추천
코드 리뷰가 아니라 메인테이너 액션 아이템이다. 오늘 안에 GitHub Security 탭의 해당 private report(들)를 열고, 비공개 스레드에 수신 확인과 담당/다음 단계를 짧게 남기세요. 공개 이슈에는 기술 내용 없이 “비공개 채널에서 이어가겠다” 한 줄만 답한 뒤, 조율이 붙으면 close하세요. 같은 막힘이 반복되면
SECURITY.md에 “첫 응답 best-effort 목표”와 “공개 이슈에는 조율만” 문장을 보강하는 작은 docs PR을 받으면 됩니다. 중복 close·types/config 무관.이 댓글은 grok-bot이 작성했습니다
Update: I reassessed the security impact and the need for confidential handling of the items behind this request. In light of the repository's public guidance and existing review practice, I concluded that public fixes are appropriate; they are now tracked in #4074, #4081 and #4082. Their normal CI and review requirements still apply.
I am keeping this issue open. As grok-bot noted, the broader coordination and documentation need remains: explicit acknowledgment and ownership for private reports, a concrete best-effort expectation for the initial response, and a clearly documented safe follow-up path when triage stalls. Making the criteria for public versus private handling more explicit would also help avoid this ambiguity in future reports.
Moving these particular fixes to public review resolves their immediate handling route; it does not resolve that process/documentation gap. Maintainer clarification on those points is still useful. No private report identifiers or technical details are needed in this issue.
Acknowledging the coordination request as a maintainer. I have confirmed that I can access the repository's private reporting queue; that is an access check, not a claim that every pending report has been technically triaged or answered privately.
Please keep any still-confidential material and follow-up in its existing GitHub private report, using the Security tab's reporting channel from SECURITY.md if needed. Do not copy private identifiers, technical details or attachments here. Public review of the already-published patches does not by itself close the corresponding private review or establish a disclosure decision for other reports.
I have reviewed the current public #4074 patch separately. #4081 and #4082 still need their own exact-head reviews; I am not marking this coordination issue resolved based on those PRs existing.
@lidge-jun please confirm ownership of the remaining private follow-ups and agree a realistic best-effort first-response target before we publish an SLA or close this issue. The current policy states best-effort triage but does not specify a response deadline. I am not inventing a dedicated email address or promising a turnaround that has not been agreed.
I will take this issue. Please assign it to me.
The problem is the lack of guidance on how to follow up on pending security reports. I will first review the current SECURITY.md file to see if there is any mention of follow-up procedures. Then, I will propose adding a section that explains how to request acknowledgment and confirmation of a private follow-up path for pending reports. This will ensure clear communication without exposing technical details.
Thanks for offering to help. A documentation-only draft is welcome; please keep it limited to the existing private GitHub reporting channel, what a coordination-only public follow-up may contain, and the distinction between receipt acknowledgment and completed technical triage.
Please do not request access to pending reports, copy their identifiers/details into the draft, or move confidential attachments into an issue/PR. Private-report ownership remains with the current maintainers. A proposed response-time target needs @lidge-jun's agreement before it becomes a project commitment; the current policy is best-effort and we should not invent an SLA.
I am not assigning the private-review responsibility through this public documentation issue. You can propose the wording here or in a small draft PR without that access. This issue should stay open until the maintainer coordination/process decision is actually settled.
- added a commit that references this issue
on Sep 9, 2026 - added a commit that references this issue
on Sep 9, 2026 Addressed on by #4133 (merge f982af4). SECURITY.md and its locale mirrors now state that GitHub private vulnerability reporting is the only technical channel, that public issues may carry coordination only, and that receipt is not triage. No response SLA was published. Closing manually because PRs here target .
Documentation problem type
Missing documentation
Documentation location
SECURITY.md — reporting and response expectations
What is wrong or missing?
I have existing reports in GitHub's private reporting channel that have been awaiting a visible maintainer response for several weeks. This is a coordination-only follow-up, consistent with the security policy's request to keep technical details private.
What should the documentation explain instead?
Could a maintainer acknowledge the pending reports privately and confirm who can review them, or which safe private follow-up path I should use? A brief confirmation of the coordination route here is sufficient; technical discussion should remain in the private reports.
Checks