From: Yunseong Kim <[email protected]>
This is a Documentation/process/cve korean version.
Reviewed-by: Jinwoo Park <[email protected]>
Signed-off-by: Yunseong Kim <[email protected]>
---
.../translations/ko_KR/process/cve.rst | 108 ++++++++++++++++++
1 file changed, 108 insertions(+)
create mode 100644 Documentation/translations/ko_KR/process/cve.rst
diff --git a/Documentation/translations/ko_KR/process/cve.rst b/Documentation/translations/ko_KR/process/cve.rst
new file mode 100644
index 000000000000..9daacba8d445
--- /dev/null
+++ b/Documentation/translations/ko_KR/process/cve.rst
@@ -0,0 +1,108 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+:원문: Documentation/process/cve.rst
+:역자: 김윤성 <[email protected]>
+:감수: 박진우 <[email protected]>
+
+==========
+CVE 항목들
+==========
+
+공통 취약점 및 노출(CVE®) 번호는 공개적으로 발표된 보안 취약점을 식별, 정의 및
+목록화하기 위한 명확한 방법으로 개발되었습니다. 시간이 지남에 따라 커널
+프로젝트와 관련하여서는 그 유용성이 감소했으며, CVE 번호는 부적절한 방식과
+부적절한 이유로 할당되는 경우가 매우 많았습니다. 이로 인하여 커널 개발
+커뮤니티에서는 이를 기피하는 경향이 있었습니다. 그러나 커널 커뮤니티 외부의
+개인과 회사가 CVE 및 기타 형태의 보안 식별자를 할당하라는 지속적인 압박과
+지속적인 남용이 결합되면서 커널 커뮤니티가 이러한 할당에 대한 통제권을 가져야
+한다는 것이 분명해졌습니다.
+
+Linux 커널 개발자 팀은 잠재적인 Linux 커널 보안 문제에 대해 CVE를 할당할 수
+있는 권한이 있습니다. 여기서 할당은 :doc:`일반 Linux 커널 보안 버그 보고
+절차<../process/security-bugs>`와는 별개입니다.
+
+Linux 커널에 할당된 모든 CVE 목록은
+https://lore.kernel.org/linux-cve-announce/ 에 있는 Linux-CVE 메일링 리스트의
+아카이브에서 확인할 수 있습니다. 할당된 CVE에 대한 알림을 받으려면 다음의
+메일링 리스트를 `구독
+<https://subspace.kernel.org/subscribing.html>`_ 하세요.
+
+절차
+====
+
+일반적인 안정 릴리스 절차의 일부로, 잠재적으로 보안 문제가 될 수 있는 커널
+변경 사항은 CVE 번호 할당을 담당하는 개발자가 식별하여 CVE 번호를 자동으로
+할당합니다. 이러한 할당은 linux-cve-announce 메일링 리스트에 공지사항으로
+수시로 게시됩니다.
+
+리눅스 커널이 시스템에 있는 계층으로 인해 거의 모든 버그가 커널의 보안을
+손상시키는 데 악용될 수 있지만 버그가 수정되면 악용 가능성이 명확하게 드러나지
+않는 경우가 많습니다. 이 때문에 CVE 할당 팀은 지나치게 조심스럽게 버그 수정이
+확인되는 모든 버그에 CVE 번호를 할당합니다.
+이것이 리눅스 커널 팀에서 발행하는 겉으로 보기에 많은 수의 CVE를 설명합니다.
+
+사용자가 CVE를 지정해야 한다고 생각하는 특정 수정 사항을 CVE 할당 팀이 놓친
+경우에는 <[email protected]>로 이메일을 보내 주시면 커널 CVE 할당 팀에서 함께
+작업할 것입니다. 이 별칭은 이미 릴리스된 커널 트리에 있는 수정 사항에 대한
+CVE 할당 전용이므로 잠재적인 보안 문제는 이 별칭으로 보내서는 안 됩니다.
+수정되지 않은 보안 문제를 발견했다고 생각되면 :doc:`일반 Linux 커널 보안
+버그 보고 절차<../process/security-bugs>`를 따르세요.
+
+Linux 커널에서 수정되지 않은 보안 이슈에 대해서는 CVE가 자동으로 할당되지
+않으며, 수정이 제공되고 안정적인 커널 트리에 적용된 후에만 자동으로 할당되며,
+기존 수정의 git 커밋 ID로 추적할 수 있습니다. 커밋으로 문제가 해결되기 전에
+CVE를 할당받고자 하는 사람은 커널 CVE 할당 팀<[email protected]>에 문의하여
+예약된 식별자 항목들에서 식별자를 할당받으시기 바랍니다.
+
+현재 Stable/LTS 커널 팀에서 적극적으로 지원하지 않는 커널 버전에서 발견된
+문제에 대해서는 CVE가 할당되지 않습니다.
+현재 지원되는 커널 브랜치 목록은 https://kernel.org/releases.html 에서 확인할
+수 있습니다.
+
+할당된 CVE 항목들의 분쟁
+=========================
+
+특정 커널 변경에 대해 할당된 CVE에 대해 이의를 제기하거나 수정할 권한은
+전적으로 영향을 받는 관련 하위 시스템의 유지 관리자에게 있습니다.
+이 원칙은 취약점 보고에 있어 높은 수준의 정확성과 책임성을 보장합니다.
+하위 시스템에 대한 깊은 전문 지식과 친밀한 지식을 갖춘 사람만이 보고된
+취약점의 유효성과 범위를 효과적으로 평가하고 적절한 CVE 지정을 결정할 수
+있습니다. 이 지정된 기관 외부에서 CVE를 수정하거나 이의를 제기하려는 시도는
+혼란, 부정확한 보고, 궁극적으로 시스템 손상으로 이어질 수 있습니다.
+
+잘못된 CVE 항목들
+=================
+
+특정 배포판에서 변경된 사항 적용한 배포판은 더 이상 kernel.org 지원 릴리스가
+아닌 커널 버전을 지원합니다. 때문에 Linux 배포판에서만 지원되는 Linux 커널에서
+보안 문제가 발견되는 경우 Linux 커널 CVE 팀에서 CVE를 할당할 수 없습니다.
+변경된 사항을 적용한 특정 Linux 배포판 자체에 요청해야 합니다.
+
+커널 할당 CVE 팀이 아닌 다른 그룹에서 적극적으로 지원되는 커널 버전에 대해
+Linux 커널에 대해 할당된 CVE는 유효한 CVE로 취급해서는 안 됩니다.
+CNA 수정 절차를 통해 특정 배포판에서 적용한 항목을 무효화할 수 있도록
+커널 CVE 할당 팀<[email protected]>으로 알려주시기 바랍니다.
+
+특정 CVE의 적용 가능성
+======================
+
+Linux 커널은 외부 사용자가 다양한 방법으로 접근하거나 전혀 접근하지 않는
+등 다양한 방식으로 사용될 수 있으므로 특정 CVE의 적용 여부는 Linux 사용자가
+결정할 사항이며 CVE 할당 팀의 권한이 아닙니다. 특정 CVE의 적용 가능성을
+판단하기 위해 우리에게 문의하지 마시기 바랍니다.
+
+또한 소스 트리가 매우 방대하고 어떤 시스템도 소스 트리의 작은 하위 집합만
+사용하므로 Linux 사용자는 할당된 많은 수의 CVE가 자신의 시스템과 관련이 없다는
+사실을 알고 인지해야 합니다.
+
+즉, 우리는 사용자의 사용 사례를 알지 못하며 사용자가 커널의 어떤 부분을
+사용하는지 알 수 없으므로 특정 CVE가 사용자의 시스템과 관련이 있는지 판단할 수
+있는 방법이 없습니다.
+
+항상 그렇듯이 커널 변경 사항은 개별적으로 선별된 변경 사항이 아니라 많은
+커뮤니티 구성원이 통합된 전체에서 함께 테스트하는 것이므로 릴리스된 모든 커널
+변경 사항을 적용하는 것이 가장 좋습니다. 또한 많은 버그의 경우 전체 문제에
+대한 해결책은 단일 변경 사항이 아니라 여러 수정 사항을 모아놓고 보아야 찾을 수
+있다는 점에 유의하세요. 이상적으로는 모든 문제에 대한 모든 수정 사항에 CVE가
+할당되지만, 때로는 수정 사항을 발견하지 못하는 경우가 있으므로 CVE가 할당되지
+않은 일부 변경 사항이 관련성이 있을 수 있다고 가정합니다.
--
2.34.1
[email protected] writes:
> From: Yunseong Kim <[email protected]>
>
> This is a Documentation/process/cve korean version.
Thank you for working to improve our documentation. A couple of
questions, though:
> Reviewed-by: Jinwoo Park <[email protected]>
> Signed-off-by: Yunseong Kim <[email protected]>
1) Why do I have three versions of it in my mailbox, sent over a period
of 13 minutes? What changed between the versions?
Normally, you want to wait for reviews to come in on one version
before posting the next, and you should put a comment after the "---"
line saying what changed.
2) When did this review from Jinwoo Park happen? I was not copied on
that.
Thanks,
jon
On 5/27/24 9:43 오후, Jonathan Corbet wrote:
> [email protected] writes:
>
>> From: Yunseong Kim <[email protected]>
>>
>> This is a Documentation/process/cve korean version.
>
> Thank you for working to improve our documentation. A couple of
> questions, though:
Hi Jonathan, Thank you for the review.
>> Reviewed-by: Jinwoo Park <[email protected]>
>> Signed-off-by: Yunseong Kim <[email protected]>
>
> 1) Why do I have three versions of it in my mailbox, sent over a period
> of 13 minutes? What changed between the versions?
Sorry, I forgot the name of the reviewer when I first sent the
documentation content related patch version 2.
> Normally, you want to wait for reviews to come in on one version
> before posting the next, and you should put a comment after the "---"
> line saying what changed.
>
> 2) When did this review from Jinwoo Park happen? I was not copied on
> that.
> Thanks,
>
> jon
Thank you for your comment.
I have updated the content from version 2 to version 1 from
Jinwoo's review.
In version 3, I added the name of the reviewer I forgot in version 2.
> ---
> .../translations/ko_KR/process/cve.rst | 108 ++++++++++++++++++
> 1 file changed, 108 insertions(+)
> create mode 100644 Documentation/translations/ko_KR/process/cve.rst
>
> diff --git a/Documentation/translations/ko_KR/process/cve.rst
b/Documentation/translations/ko_KR/process/cve.rst
> new file mode 100644
> index 000000000000..9daacba8d445
> --- /dev/null
> +++ b/Documentation/translations/ko_KR/process/cve.rst
> @@ -0,0 +1,108 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +:원문: Documentation/process/cve.rst
> +:역자: 김윤성 <[email protected]>
I added Jinwoo's name here on version 3.
> +:감수: 박진우 <[email protected]>
Warm Regards,
Yunseong Kim
Yunseong Kim <[email protected]> writes:
>> 1) Why do I have three versions of it in my mailbox, sent over a period
>> of 13 minutes? What changed between the versions?
>
> Sorry, I forgot the name of the reviewer when I first sent the
> documentation content related patch version 2.
Which is fine, but...
>> Normally, you want to wait for reviews to come in on one version
>> before posting the next, and you should put a comment after the "---"
>> line saying what changed.
>>
>> 2) When did this review from Jinwoo Park happen? I was not copied on
>> that.
You did not answer this question. Reviews should generally be done in
public, but that does not seem to have happened here?
Thanks,
jon
Yunseong Kim <[email protected]> writes:
> On 5/27/24 10:50 오후, Jonathan Corbet wrote:
>> Yunseong Kim <[email protected]> writes:
>>
>>>> 1) Why do I have three versions of it in my mailbox, sent over a period
>>>> of 13 minutes? What changed between the versions?
>>>
>>> Sorry, I forgot the name of the reviewer when I first sent the
>>> documentation content related patch version 2.
>>
>> Which is fine, but...
>>
>>>> Normally, you want to wait for reviews to come in on one version
>>>> before posting the next, and you should put a comment after the "---"
>>>> line saying what changed.
>>>>
>>>> 2) When did this review from Jinwoo Park happen? I was not copied on
>>>> that.
>>
>> You did not answer this question. Reviews should generally be done in
>> public, but that does not seem to have happened here?
>
> Oops, sorry about that, Jonathan.
>
> Jinwoo Park sent me the review below, and I've updated some of ambiguous
> words in patch version 2.
>
> https://lore.kernel.org/linux-doc/[email protected]/T/#t
It does look like the patch was reviewed, but no Reviewed-by tag was
offered. *Never* apply a Reviewed-by tag that has not been explicitly
given to you.
Jinwoo, would you like to offer that tag for this patch?
Thanks,
jon
On 5/27/24 10:50 오후, Jonathan Corbet wrote:
> Yunseong Kim <[email protected]> writes:
>
>>> 1) Why do I have three versions of it in my mailbox, sent over a period
>>> of 13 minutes? What changed between the versions?
>>
>> Sorry, I forgot the name of the reviewer when I first sent the
>> documentation content related patch version 2.
>
> Which is fine, but...
>
>>> Normally, you want to wait for reviews to come in on one version
>>> before posting the next, and you should put a comment after the "---"
>>> line saying what changed.
>>>
>>> 2) When did this review from Jinwoo Park happen? I was not copied on
>>> that.
>
> You did not answer this question. Reviews should generally be done in
> public, but that does not seem to have happened here?
Oops, sorry about that, Jonathan.
Jinwoo Park sent me the review below, and I've updated some of ambiguous
words in patch version 2.
https://lore.kernel.org/linux-doc/[email protected]/T/#t
>> Thanks for translating new Documentation/process/cve document to Korean
>> Language. Most of the Korean sentences are looks good to me. But only
>> one sentence seemed unnatural.
>
> Thank you for the review Jinwoo.
>
>>> 잘못된 CVE 항목들
>>> =================
>>>
>>> -해당 배포판에서 변경된 사항으로 인해 또는 해당 배포판이 더 이상
>>> kernel.org
>>> +특정 배포판에서 변경된 사항으로 인해 또는 해당 배포판이 더 이상
>>> kernel.org
>>> 지원 릴리스가 아닌 커널 버전을 지원하기 때문에 Linux 배포판에서만
지원되는
>>> Linux 커널에서 보안 문제가 발견되는 경우 Linux 커널 CVE 팀에서 CVE를
할당할
>>> 수 없으며 해당 Linux 배포판 자체에서 요청해야 합니다.
>>
>> When the first modifier "해당" is first used in a Korean sentence, like
>> "the", there needs to be an explanation of what it is targeting.
>
>
> You're right, that phrase was awkward in the direct translation. Thanks
> for catching that.
>
>> However, in the process of literal translation, it seems that "the"
>> became "해당" due to the difference in word order between Korean and
>> English, And since the translated sentence did not describe which "Linux
>> distributor" is being described, it would be very difficult if
>> "특정(specific)" were used instead. It seems natural.
>
> I will send version 2 patch. Thank you!
>
> Warm Regards,
>
> Yunseong Kim
And I added Jinwoo as a reviewer to the documentation on patch version 3.
On 5/27/24 10:21 오후, Yunseong Kim wrote:
> I added Jinwoo's name here on version 3.
>
>> +:감수: 박진우 <[email protected]>
> Warm Regards,
Thank you for guiding me Jonathan.
I'll keep the process in mind and use them to help the next person who
translates to Korean.
> Thanks,
>
> jon
Warn Regards,
Yunseong Kim
On 2024. 5. 27. 오후 11:55, Jonathan Corbet wrote:
> It does look like the patch was reviewed, but no Reviewed-by tag was
> offered. *Never* apply a Reviewed-by tag that has not been explicitly
> given to you.
>
> Jinwoo, would you like to offer that tag for this patch?
Thank you for taking a close look at the content and flow of the patch.
Jon, yes I want to offer and apply Reviewd-by tag for the patch.
Thanks Regards,
Jinwoo Park
From: [email protected]
Hello,
Thank you for this translation.
I think this is much better than nothing, but I doubt if this is well reviewed
by people who having good understanding of the domain. IMHO, this patch still
has many rooms for improvements.
On Mon, 27 May 2024 19:30:04 +0900 [email protected] wrote:
> From: Yunseong Kim <[email protected]>
>
> This is a Documentation/process/cve korean version.
>
> Reviewed-by: Jinwoo Park <[email protected]>
> Signed-off-by: Yunseong Kim <[email protected]>
> ---
> .../translations/ko_KR/process/cve.rst | 108 ++++++++++++++++++
> 1 file changed, 108 insertions(+)
Why don't you link this translation on index.rst of same directory?
> create mode 100644 Documentation/translations/ko_KR/process/cve.rst
>
> diff --git a/Documentation/translations/ko_KR/process/cve.rst b/Documentation/translations/ko_KR/process/cve.rst
> new file mode 100644
> index 000000000000..9daacba8d445
> --- /dev/null
> +++ b/Documentation/translations/ko_KR/process/cve.rst
> @@ -0,0 +1,108 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +:원문: Documentation/process/cve.rst
> +:역자: 김윤성 <[email protected]>
> +:감수: 박진우 <[email protected]>
> +
> +==========
> +CVE 항목들
> +==========
> +
> +공통 취약점 및 노출(CVE®) 번호는 공개적으로 발표된 보안 취약점을 식별, 정의 및
> +목록화하기 위한 명확한 방법으로 개발되었습니다. 시간이 지남에 따라 커널
> +프로젝트와 관련하여서는 그 유용성이 감소했으며, CVE 번호는 부적절한 방식과
> +부적절한 이유로 할당되는 경우가 매우 많았습니다. 이로 인하여 커널 개발
> +커뮤니티에서는 이를 기피하는 경향이 있었습니다. 그러나 커널 커뮤니티 외부의
> +개인과 회사가 CVE 및 기타 형태의 보안 식별자를 할당하라는 지속적인 압박과
> +지속적인 남용이 결합되면서 커널 커뮤니티가 이러한 할당에 대한 통제권을 가져야
> +한다는 것이 분명해졌습니다.
> +
> +Linux 커널 개발자 팀은 잠재적인 Linux 커널 보안 문제에 대해 CVE를 할당할 수
I'd suggest s/개발자 팀/개발팀/
> +있는 권한이 있습니다. 여기서 할당은 :doc:`일반 Linux 커널 보안 버그 보고
> +절차<../process/security-bugs>`와는 별개입니다.
Would the path to the linked doc need to be updated?
> +
> +Linux 커널에 할당된 모든 CVE 목록은
> +https://lore.kernel.org/linux-cve-announce/ 에 있는 Linux-CVE 메일링 리스트의
> +아카이브에서 확인할 수 있습니다. 할당된 CVE에 대한 알림을 받으려면 다음의
> +메일링 리스트를 `구독
> +<https://subspace.kernel.org/subscribing.html>`_ 하세요.
> +
> +절차
> +====
> +
> +일반적인 안정 릴리스 절차의 일부로, 잠재적으로 보안 문제가 될 수 있는 커널
> +변경 사항은 CVE 번호 할당을 담당하는 개발자가 식별하여 CVE 번호를 자동으로
> +할당합니다. 이러한 할당은 linux-cve-announce 메일링 리스트에 공지사항으로
> +수시로 게시됩니다.
> +
> +리눅스 커널이 시스템에 있는 계층으로 인해 거의 모든 버그가 커널의 보안을
I feel "있는" here a little bit difficult to read. What about "위치하는" or
rather making the point clear, e.g., "리눅스 커널은 시스템의 하위 계층에 있기
때문에 ..."?
> +손상시키는 데 악용될 수 있지만 버그가 수정되면 악용 가능성이 명확하게 드러나지
> +않는 경우가 많습니다. 이 때문에 CVE 할당 팀은 지나치게 조심스럽게 버그 수정이
> +확인되는 모든 버그에 CVE 번호를 할당합니다.
I feel "지나치게" might wrongly present the original meaning. What about
"지나치게 조심스러워 보일 수 있는 방식으로"?
> +이것이 리눅스 커널 팀에서 발행하는 겉으로 보기에 많은 수의 CVE를 설명합니다.
I think "겉으로 보기에" might not what really the author wanted to mean. I
think we can simply drop "보기에".
> +
> +사용자가 CVE를 지정해야 한다고 생각하는 특정 수정 사항을 CVE 할당 팀이 놓친
> +경우에는 <[email protected]>로 이메일을 보내 주시면 커널 CVE 할당 팀에서 함께
> +작업할 것입니다. 이 별칭은 이미 릴리스된 커널 트리에 있는 수정 사항에 대한
> +CVE 할당 전용이므로 잠재적인 보안 문제는 이 별칭으로 보내서는 안 됩니다.
s/별칭/주소/?
> +수정되지 않은 보안 문제를 발견했다고 생각되면 :doc:`일반 Linux 커널 보안
> +버그 보고 절차<../process/security-bugs>`를 따르세요.
Again, can you please confirm if the link can work with the path?
> +
> +Linux 커널에서 수정되지 않은 보안 이슈에 대해서는 CVE가 자동으로 할당되지
> +않으며, 수정이 제공되고 안정적인 커널 트리에 적용된 후에만 자동으로 할당되며,
I think translating "stable kernel tree" as "안정적인 커널 트리" makes it
confusing. I think simply calling it "stable 커널 트리" like below paragraph
is better. At least it should be consistent in my opinion.
> +기존 수정의 git 커밋 ID로 추적할 수 있습니다. 커밋으로 문제가 해결되기 전에
> +CVE를 할당받고자 하는 사람은 커널 CVE 할당 팀<[email protected]>에 문의하여
> +예약된 식별자 항목들에서 식별자를 할당받으시기 바랍니다.
> +
> +현재 Stable/LTS 커널 팀에서 적극적으로 지원하지 않는 커널 버전에서 발견된
> +문제에 대해서는 CVE가 할당되지 않습니다.
I again don't think translating "actively supported" as "적극적으로 지원하지
않는" makes readers confused. I think it is better to drop "적극적으로".
> +현재 지원되는 커널 브랜치 목록은 https://kernel.org/releases.html 에서 확인할
> +수 있습니다.
> +
> +할당된 CVE 항목들의 분쟁
> +=========================
> +
> +특정 커널 변경에 대해 할당된 CVE에 대해 이의를 제기하거나 수정할 권한은
> +전적으로 영향을 받는 관련 하위 시스템의 유지 관리자에게 있습니다.
> +이 원칙은 취약점 보고에 있어 높은 수준의 정확성과 책임성을 보장합니다.
> +하위 시스템에 대한 깊은 전문 지식과 친밀한 지식을 갖춘 사람만이 보고된
> +취약점의 유효성과 범위를 효과적으로 평가하고 적절한 CVE 지정을 결정할 수
> +있습니다. 이 지정된 기관 외부에서 CVE를 수정하거나 이의를 제기하려는 시도는
> +혼란, 부정확한 보고, 궁극적으로 시스템 손상으로 이어질 수 있습니다.
> +
> +잘못된 CVE 항목들
> +=================
> +
> +특정 배포판에서 변경된 사항 적용한 배포판은 더 이상 kernel.org 지원 릴리스가
> +아닌 커널 버전을 지원합니다. 때문에 Linux 배포판에서만 지원되는 Linux 커널에서
> +보안 문제가 발견되는 경우 Linux 커널 CVE 팀에서 CVE를 할당할 수 없습니다.
> +변경된 사항을 적용한 특정 Linux 배포판 자체에 요청해야 합니다.
I was unable to understand above paragraph at the first glance. I think some
wordsmithing is needed?
> +
> +커널 할당 CVE 팀이 아닌 다른 그룹에서 적극적으로 지원되는 커널 버전에 대해
> +Linux 커널에 대해 할당된 CVE는 유효한 CVE로 취급해서는 안 됩니다.
Again, "적극적으로 지원되는" sounds odd to me. The overall sentence is
difficult to understand.
> +CNA 수정 절차를 통해 특정 배포판에서 적용한 항목을 무효화할 수 있도록
> +커널 CVE 할당 팀<[email protected]>으로 알려주시기 바랍니다.
"<[email protected]> 이메일을 통해"?
> +
> +특정 CVE의 적용 가능성
> +======================
> +
> +Linux 커널은 외부 사용자가 다양한 방법으로 접근하거나 전혀 접근하지 않는
> +등 다양한 방식으로 사용될 수 있으므로 특정 CVE의 적용 여부는 Linux 사용자가
> +결정할 사항이며 CVE 할당 팀의 권한이 아닙니다. 특정 CVE의 적용 가능성을
I'd suggest using consistent term for "applicability". I think the second one
is better.
> +판단하기 위해 우리에게 문의하지 마시기 바랍니다.
> +
> +또한 소스 트리가 매우 방대하고 어떤 시스템도 소스 트리의 작은 하위 집합만
> +사용하므로 Linux 사용자는 할당된 많은 수의 CVE가 자신의 시스템과 관련이 없다는
> +사실을 알고 인지해야 합니다.
> +
> +즉, 우리는 사용자의 사용 사례를 알지 못하며 사용자가 커널의 어떤 부분을
> +사용하는지 알 수 없으므로 특정 CVE가 사용자의 시스템과 관련이 있는지 판단할 수
> +있는 방법이 없습니다.
> +
> +항상 그렇듯이 커널 변경 사항은 개별적으로 선별된 변경 사항이 아니라 많은
> +커뮤니티 구성원이 통합된 전체에서 함께 테스트하는 것이므로 릴리스된 모든 커널
> +변경 사항을 적용하는 것이 가장 좋습니다. 또한 많은 버그의 경우 전체 문제에
> +대한 해결책은 단일 변경 사항이 아니라 여러 수정 사항을 모아놓고 보아야 찾을 수
> +있다는 점에 유의하세요. 이상적으로는 모든 문제에 대한 모든 수정 사항에 CVE가
> +할당되지만, 때로는 수정 사항을 발견하지 못하는 경우가 있으므로 CVE가 할당되지
> +않은 일부 변경 사항이 관련성이 있을 수 있다고 가정합니다.
The last part is simply wrong in my opinion. It is a suggestion, not an
explanation.
Thanks,
SJ
> --
> 2.34.1
>
>
On 5/30/24 10:43 오전, SeongJae Park wrote:
> From: [email protected]
>
> Hello,
>
>
> Thank you for this translation.
>
> I think this is much better than nothing, but I doubt if this is well reviewed
> by people who having good understanding of the domain. IMHO, this patch still
> has many rooms for improvements.
Thank you for your document review SeongJae!
I'll take your suggestions and incorporate them into the next patch.
Warm Regards,
Yunseong Kim
> On Mon, 27 May 2024 19:30:04 +0900 [email protected] wrote:
>
>> From: Yunseong Kim <[email protected]>
>>
>> This is a Documentation/process/cve korean version.
>>
>> Reviewed-by: Jinwoo Park <[email protected]>
>> Signed-off-by: Yunseong Kim <[email protected]>
>> ---
>> .../translations/ko_KR/process/cve.rst | 108 ++++++++++++++++++
>> 1 file changed, 108 insertions(+)
>
> Why don't you link this translation on index.rst of same directory?
>
>> create mode 100644 Documentation/translations/ko_KR/process/cve.rst
>>
>> diff --git a/Documentation/translations/ko_KR/process/cve.rst b/Documentation/translations/ko_KR/process/cve.rst
>> new file mode 100644
>> index 000000000000..9daacba8d445
>> --- /dev/null
>> +++ b/Documentation/translations/ko_KR/process/cve.rst
>> @@ -0,0 +1,108 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +:원문: Documentation/process/cve.rst
>> +:역자: 김윤성 <[email protected]>
>> +:감수: 박진우 <[email protected]>
>> +
>> +==========
>> +CVE 항목들
>> +==========
>> +
>> +공통 취약점 및 노출(CVE®) 번호는 공개적으로 발표된 보안 취약점을 식별, 정의 및
>> +목록화하기 위한 명확한 방법으로 개발되었습니다. 시간이 지남에 따라 커널
>> +프로젝트와 관련하여서는 그 유용성이 감소했으며, CVE 번호는 부적절한 방식과
>> +부적절한 이유로 할당되는 경우가 매우 많았습니다. 이로 인하여 커널 개발
>> +커뮤니티에서는 이를 기피하는 경향이 있었습니다. 그러나 커널 커뮤니티 외부의
>> +개인과 회사가 CVE 및 기타 형태의 보안 식별자를 할당하라는 지속적인 압박과
>> +지속적인 남용이 결합되면서 커널 커뮤니티가 이러한 할당에 대한 통제권을 가져야
>> +한다는 것이 분명해졌습니다.
>> +
>> +Linux 커널 개발자 팀은 잠재적인 Linux 커널 보안 문제에 대해 CVE를 할당할 수
>
> I'd suggest s/개발자 팀/개발팀/
>
>> +있는 권한이 있습니다. 여기서 할당은 :doc:`일반 Linux 커널 보안 버그 보고
>> +절차<../process/security-bugs>`와는 별개입니다.
>
> Would the path to the linked doc need to be updated?
>
>> +
>> +Linux 커널에 할당된 모든 CVE 목록은
>> +https://lore.kernel.org/linux-cve-announce/ 에 있는 Linux-CVE 메일링 리스트의
>> +아카이브에서 확인할 수 있습니다. 할당된 CVE에 대한 알림을 받으려면 다음의
>> +메일링 리스트를 `구독
>> +<https://subspace.kernel.org/subscribing.html>`_ 하세요.
>> +
>> +절차
>> +====
>> +
>> +일반적인 안정 릴리스 절차의 일부로, 잠재적으로 보안 문제가 될 수 있는 커널
>> +변경 사항은 CVE 번호 할당을 담당하는 개발자가 식별하여 CVE 번호를 자동으로
>> +할당합니다. 이러한 할당은 linux-cve-announce 메일링 리스트에 공지사항으로
>> +수시로 게시됩니다.
>> +
>> +리눅스 커널이 시스템에 있는 계층으로 인해 거의 모든 버그가 커널의 보안을
>
> I feel "있는" here a little bit difficult to read. What about "위치하는" or
> rather making the point clear, e.g., "리눅스 커널은 시스템의 하위 계층에 있기
> 때문에 ..."?
>
>> +손상시키는 데 악용될 수 있지만 버그가 수정되면 악용 가능성이 명확하게 드러나지
>> +않는 경우가 많습니다. 이 때문에 CVE 할당 팀은 지나치게 조심스럽게 버그 수정이
>> +확인되는 모든 버그에 CVE 번호를 할당합니다.
>
> I feel "지나치게" might wrongly present the original meaning. What about
> "지나치게 조심스러워 보일 수 있는 방식으로"?
>
>> +이것이 리눅스 커널 팀에서 발행하는 겉으로 보기에 많은 수의 CVE를 설명합니다.
>
> I think "겉으로 보기에" might not what really the author wanted to mean. I
> think we can simply drop "보기에".
>
>> +
>> +사용자가 CVE를 지정해야 한다고 생각하는 특정 수정 사항을 CVE 할당 팀이 놓친
>> +경우에는 <[email protected]>로 이메일을 보내 주시면 커널 CVE 할당 팀에서 함께
>> +작업할 것입니다. 이 별칭은 이미 릴리스된 커널 트리에 있는 수정 사항에 대한
>> +CVE 할당 전용이므로 잠재적인 보안 문제는 이 별칭으로 보내서는 안 됩니다.
>
> s/별칭/주소/?
>
>> +수정되지 않은 보안 문제를 발견했다고 생각되면 :doc:`일반 Linux 커널 보안
>> +버그 보고 절차<../process/security-bugs>`를 따르세요.
>
> Again, can you please confirm if the link can work with the path?
>
>> +
>> +Linux 커널에서 수정되지 않은 보안 이슈에 대해서는 CVE가 자동으로 할당되지
>> +않으며, 수정이 제공되고 안정적인 커널 트리에 적용된 후에만 자동으로 할당되며,
>
> I think translating "stable kernel tree" as "안정적인 커널 트리" makes it
> confusing. I think simply calling it "stable 커널 트리" like below paragraph
> is better. At least it should be consistent in my opinion.
>
>> +기존 수정의 git 커밋 ID로 추적할 수 있습니다. 커밋으로 문제가 해결되기 전에
>> +CVE를 할당받고자 하는 사람은 커널 CVE 할당 팀<[email protected]>에 문의하여
>> +예약된 식별자 항목들에서 식별자를 할당받으시기 바랍니다.
>> +
>> +현재 Stable/LTS 커널 팀에서 적극적으로 지원하지 않는 커널 버전에서 발견된
>> +문제에 대해서는 CVE가 할당되지 않습니다.
>
> I again don't think translating "actively supported" as "적극적으로 지원하지
> 않는" makes readers confused. I think it is better to drop "적극적으로".
>
>> +현재 지원되는 커널 브랜치 목록은 https://kernel.org/releases.html 에서 확인할
>> +수 있습니다.
>> +
>> +할당된 CVE 항목들의 분쟁
>> +=========================
>> +
>> +특정 커널 변경에 대해 할당된 CVE에 대해 이의를 제기하거나 수정할 권한은
>> +전적으로 영향을 받는 관련 하위 시스템의 유지 관리자에게 있습니다.
>> +이 원칙은 취약점 보고에 있어 높은 수준의 정확성과 책임성을 보장합니다.
>> +하위 시스템에 대한 깊은 전문 지식과 친밀한 지식을 갖춘 사람만이 보고된
>> +취약점의 유효성과 범위를 효과적으로 평가하고 적절한 CVE 지정을 결정할 수
>> +있습니다. 이 지정된 기관 외부에서 CVE를 수정하거나 이의를 제기하려는 시도는
>> +혼란, 부정확한 보고, 궁극적으로 시스템 손상으로 이어질 수 있습니다.
>> +
>> +잘못된 CVE 항목들
>> +=================
>> +
>> +특정 배포판에서 변경된 사항 적용한 배포판은 더 이상 kernel.org 지원 릴리스가
>> +아닌 커널 버전을 지원합니다. 때문에 Linux 배포판에서만 지원되는 Linux 커널에서
>> +보안 문제가 발견되는 경우 Linux 커널 CVE 팀에서 CVE를 할당할 수 없습니다.
>> +변경된 사항을 적용한 특정 Linux 배포판 자체에 요청해야 합니다.
>
> I was unable to understand above paragraph at the first glance. I think some
> wordsmithing is needed?
>
>> +
>> +커널 할당 CVE 팀이 아닌 다른 그룹에서 적극적으로 지원되는 커널 버전에 대해
>> +Linux 커널에 대해 할당된 CVE는 유효한 CVE로 취급해서는 안 됩니다.
>
> Again, "적극적으로 지원되는" sounds odd to me. The overall sentence is
> difficult to understand.
>
>> +CNA 수정 절차를 통해 특정 배포판에서 적용한 항목을 무효화할 수 있도록
>> +커널 CVE 할당 팀<[email protected]>으로 알려주시기 바랍니다.
>
> "<[email protected]> 이메일을 통해"?
>
>> +
>> +특정 CVE의 적용 가능성
>> +======================
>> +
>> +Linux 커널은 외부 사용자가 다양한 방법으로 접근하거나 전혀 접근하지 않는
>> +등 다양한 방식으로 사용될 수 있으므로 특정 CVE의 적용 여부는 Linux 사용자가
>> +결정할 사항이며 CVE 할당 팀의 권한이 아닙니다. 특정 CVE의 적용 가능성을
>
> I'd suggest using consistent term for "applicability". I think the second one
> is better.
>
>> +판단하기 위해 우리에게 문의하지 마시기 바랍니다.
>> +
>> +또한 소스 트리가 매우 방대하고 어떤 시스템도 소스 트리의 작은 하위 집합만
>> +사용하므로 Linux 사용자는 할당된 많은 수의 CVE가 자신의 시스템과 관련이 없다는
>> +사실을 알고 인지해야 합니다.
>> +
>> +즉, 우리는 사용자의 사용 사례를 알지 못하며 사용자가 커널의 어떤 부분을
>> +사용하는지 알 수 없으므로 특정 CVE가 사용자의 시스템과 관련이 있는지 판단할 수
>> +있는 방법이 없습니다.
>> +
>> +항상 그렇듯이 커널 변경 사항은 개별적으로 선별된 변경 사항이 아니라 많은
>> +커뮤니티 구성원이 통합된 전체에서 함께 테스트하는 것이므로 릴리스된 모든 커널
>> +변경 사항을 적용하는 것이 가장 좋습니다. 또한 많은 버그의 경우 전체 문제에
>> +대한 해결책은 단일 변경 사항이 아니라 여러 수정 사항을 모아놓고 보아야 찾을 수
>> +있다는 점에 유의하세요. 이상적으로는 모든 문제에 대한 모든 수정 사항에 CVE가
>> +할당되지만, 때로는 수정 사항을 발견하지 못하는 경우가 있으므로 CVE가 할당되지
>> +않은 일부 변경 사항이 관련성이 있을 수 있다고 가정합니다.
>
> The last part is simply wrong in my opinion. It is a suggestion, not an
> explanation.
>
>
> Thanks,
> SJ
>
>> --
>> 2.34.1
>>
>>