v0.77.13

git-ctx v0.77.13

이번 릴리스는 프로젝트가 실제로 갖는 파이썬 락파일을 인벤토리가 읽지 않던 문제를 고칩니다. 파이썬 해석기는 넷이 보통 쓰이는데 읽히는 락파일은 poetry.lock 하나였기 때문에, uv·PDM·pipenv로 해석하는 저장소는 pyproject.toml의 범위만 인벤토리에 들어갔습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고 대응 중이라면 이 릴리스가 판정할 수 있는 저장소를 늘립니다. uv.lock·pdm.lock·Pipfile.lock으로 버전을 고정한 저장소는 find-dependency-usage가 보기에 >=2.31·~=4.2 같은 범위만 말하는 저장소였고, 범위는 권고의 고정 버전과 비교할 수 없는 쪽입니다. 이번에도 판정이 아니라 저장되는 내용이 바뀌므로, 답이 달라지려면 재색인이 필요합니다.

수정

uv.lock도 pdm.lock도 Pipfile.lock도 인벤토리에 없었습니다

• RecognizeLock은 파이썬 락파일로 poetry.lock만 알았습니다. Poetry는 보통 쓰이는 해석기 넷 중 하나이고, 나머지 셋이 쓰는 파일은 전혀 인식되지 않았습니다.
• 그래서 uv·PDM·pipenv로 해석하는 모든 저장소의 인벤토리에는 pyproject.toml의 범위 — >=2.31, ~=4.2 — 만 남았습니다. 범위는 권고 판정이 결정하지 못하는 바로 그것입니다. 인벤토리는 질문만 들고 있었고 답은 한 번도 들어오지 않았습니다.
• uv와 PDM은 Cargo·Poetry와 같은 [[package]] 블록을 쓰므로 기존 TOML 락 파서로 보냅니다. 이름과 버전은 블록 머리의 0열에 서 있어, uv 블록 아래의 requires-dist 항목이나 [package.metadata] 표가 패키지로 새지 않습니다.
• Pipfile.lock은 JSON이라 전용 판독기를 둡니다. 최상위의 _meta는 패키지 집합이 아니고 값의 모양도 다르므로, 문서 전체를 하나의 맵으로 읽는 대신 default·develop 두 집합을 이름으로 짚습니다 — 통째로 읽었다면 _meta에서 실패해 파일 전체가 빠졌을 것입니다.

pipenv는 ==2.31.0이라고 적습니다

• 다른 모든 락파일은 숫자만 적는데, pipenv는 핀을 설치할 요구사항 그대로 ==2.31.0으로 저장합니다. 적힌 대로 두면 다른 도구가 해석한 같은 릴리스와 다른 묶음으로 갈리고, 권고의 고정 버전과 어떤 비교도 성공하지 못합니다. 연산자를 떼고 숫자만 기록합니다.
• VCS ref에서 가져온 패키지는 커밋으로 고정되고 버전이 없으므로 빼둡니다.

두 섹션에 같이 있는 패키지가 두 번 나왔습니다

• pipenv는 한 패키지가 default와 develop에 모두 필요하면 같은 버전으로 양쪽에 적습니다. parsePipfileLock은 둘 다 덧붙여 같은 패키지가 바이트 단위로 똑같이 두 번 나왔습니다.
• 겉보기 중복이 아닙니다. 색인기는 패키지를 INSERT ... ON CONFLICT (...) DO UPDATE 한 문장으로 묶어 넣는데, PostgreSQL은 같은 행을 두 번 갱신하는 문장을 거부합니다 — ON CONFLICT DO UPDATE command cannot affect row a second time. 배치가 실패하고 저장소는 색인되지 않았습니다.
• 이름과 버전이 같은 항목은 첫 번째만 남깁니다. 같은 이름의 다른 버전은 여전히 두 패키지입니다.

검증

• 새 표 TestThePythonLockFilesAProjectActuallyHas — uv.lock·pdm.lock·Pipfile.lock이 인식되고 각 파일에서 해석된 패키지가 읽히는지, uv 블록의 requires-dist와 [package.metadata], Pipfile.lock의 _meta와 VCS 핀이 패키지로 새지 않는지. 수정 전에는 실패함
• 새 시험 TestPipfileLockStatesTheVersionAlone — == 연산자가 떨어지고 숫자만 남는지. 수정 전에는 실패함
• 새 시험 TestAPackageInBothSectionsIsEmittedOnce·TestTheSameNameAtTwoVersionsStaysTwoPackages — 두 섹션의 같은 항목은 한 번, 다른 버전은 둘로 나오는지. 수정 전에는 실패함
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, manifest는 -race도 통과
• 버전 메타데이터 정합성, Kubernetes Kustomize 렌더링, linux/amd64 Docker 이미지 빌드

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인이 필요합니다. 의존성 인벤토리는 색인할 때 만들어지므로, 이미 색인된 저장소의 저장된 선언은 다시 읽기 전까지 그대로입니다. uv.lock·pdm.lock·Pipfile.lock을 두는 저장소가 있다면 해당 ref를 다시 색인하세요.
• 재색인 뒤에는 해석된 버전이 인벤토리에 들어옵니다. 지금까지 범위만 보이던 저장소가 권고 조회에서 고정 버전으로 판정됩니다.
• docs/configuration.md의 지원 락파일 목록에 세 이름을 더했습니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.13.tar.gz
• git-ctx-v0.77.13.tar.gz.sha256

sha256sum -c git-ctx-v0.77.13.tar.gz.sha256
gzip -dc git-ctx-v0.77.13.tar.gz | docker load
docker image inspect git-ctx:v0.77.13 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.13과 git-ctx:0.77.13 태그가 포함됩니다.

전체 변경 내역: v0.77.12...v0.77.13

v0.77.12

git-ctx v0.77.12

이번 릴리스는 YAML 블록 스칼라로 다음 줄부터 적은 자격증명을 마스킹이 전혀 가리지 못하던 문제를 고칩니다. password: | 아래에 적힌 비밀번호와 짧은 토큰은 어떤 규칙에도 잡히지 않아 통째로 색인되고 스니펫으로 그대로 돌아왔습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

Kubernetes Secret·Helm values·Ansible vars·GitLab CI 변수·compose 파일을 담은 저장소를 색인 중이라면 이 릴리스가 저장되는 내용을 바꿉니다. 블록 스칼라는 매니페스트가 한 줄에 맞지 않거나 따옴표로 감싸고 싶지 않은 값을 적는 표준적인 형태이고, 그 본문은 지금까지 원문 그대로 저장돼 있었습니다. 재색인이 필요합니다 — 마스킹 규칙이 바뀌면 정책 지문도 함께 바뀌므로 대부분의 ref는 다음 색인 실행에서 자동으로 다시 읽힙니다.

수정

password: | 아래의 값은 어떤 규칙도 보지 못했습니다

• 자격증명 대입 규칙은 한 줄을 읽고, 콜론 뒤에 네 글자 이상을 요구합니다. 그런데 블록 스칼라는 키 줄에 | 한 글자만 두고 값을 다음 줄부터 적습니다.

  stringData:
    password: |
      S0me-P@ssword

• 뒤따르는 줄은 자기가 무엇에 속하는지 말하지 않으므로 본문이 색인에 들어가 스니펫으로 그대로 나왔습니다. 이렇게 적은 키나 인증서는 비밀키 규칙이, 길고 무작위한 토큰은 엔트로피 규칙이 잡아 주지만, 평범한 비밀번호와 짧은 토큰은 정확히 그 사이에 남아 있었습니다.

• 이제 본문은 키보다 깊게 들여쓴 줄의 연속으로 봅니다 — YAML 자체가 값의 끝을 정하는 방식입니다. 들여쓰기가 키 이하로 얕아지는 줄에서 블록이 끝나고, 문서의 나머지는 건드리지 않습니다.

• 줄은 각각 따로 [REDACTED]로 바꾸고 들여쓰기를 유지합니다. 청크는 마스킹된 내용에서 잘라내고 잘라낸 줄의 번호를 달아 저장되므로, 블록을 [REDACTED] 하나로 접었다면 그 파일에서 그 뒤의 모든 줄이 밀렸을 것입니다. 블록 안의 빈 줄도 그대로 둡니다. CRLF 파일은 줄 끝을 바꾸지 않습니다.

표시자가 줄을 끝내야 합니다

• 표시자는 | 또는 >, chomping -·+, 들여쓰기 숫자, 그리고 그 뒤에는 주석 말고 아무것도 없어야 합니다.
• 그래서 템플릿 언어의 token: > 5 && retries < 2와, 파이프로 시작하는 Markdown 표의 | password | ... | 셀에는 규칙이 닿지 않습니다. script: |·description: |처럼 키가 자격증명 이름이 아닌 블록도 그대로 둡니다.
• 규칙이 아는 필드 이름은 대입 규칙과 한 목록으로 공유합니다. 한 문법에 더한 이름이 다른 문법에서도 같이 읽힙니다.

검증

• TestCredentialShapesAnInstallationActuallyHolds에 블록 스칼라 2건 추가 — 리터럴(|) 블록과 목록 항목 아래 folded(>-) 블록. 수정 전에는 실패함
• 새 시험 TestABlockScalarStatesItsValueOnTheFollowingLines — 빈 줄을 품은 블록 두 개가 가려지고, 들여쓰기가 얕아진 뒤의 username: app과 notes: | 본문은 남으며, 값 줄마다 [REDACTED] 하나가 원래 들여쓰기로 놓이는지. 수정 전에는 실패함
• TestOrdinaryContentIsLeftAlone에 5건 추가 — script: |·description: |·Markdown 표·token: > 5·본문 없는 password: |가 가려지지 않는지
• TestMaskingNeverChangesTheLineCount에 빈 줄을 품은 블록과 CRLF·들여쓰기 숫자 블록 2건 추가
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, contentsecurity는 -race도 통과
• 버전 메타데이터 정합성, Kubernetes Kustomize 렌더링, linux/amd64 Docker 이미지 빌드

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인이 필요합니다. 마스킹은 색인할 때 적용되므로, 이미 저장된 청크 안의 블록 스칼라 본문은 다시 읽기 전까지 그대로입니다.
• 대부분은 자동입니다. 정책 지문에 마스킹 규칙이 들어 있어서, 이번 릴리스로 올리면 지문이 바뀌고 다음 색인 실행에서 커밋이 그대로인 ref도 다시 읽힙니다.
• 다만 정책 지문이 기록되기 전에 색인된 ref는 저장된 지문이 비어 있어 "현재"로 취급됩니다(업그레이드마다 전체를 다시 읽지 않기 위한 동작입니다). 오래 색인하지 않은 저장소가 있다면 해당 ref를 수동으로 다시 색인하세요.
• 재색인 뒤에는 블록 스칼라로 자격증명을 적은 파일에서 credential_assignment 보안 이벤트가 새로 올라옵니다. 지금까지 보이지 않던 자격증명이 잡히는 것이므로 조치 대상으로 보세요.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.12.tar.gz
• git-ctx-v0.77.12.tar.gz.sha256

sha256sum -c git-ctx-v0.77.12.tar.gz.sha256
gzip -dc git-ctx-v0.77.12.tar.gz | docker load
docker image inspect git-ctx:v0.77.12 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.12과 git-ctx:0.77.12 태그가 포함됩니다.

전체 변경 내역: v0.77.11...v0.77.12

v0.77.11

git-ctx v0.77.11

이번 릴리스는 자격증명 마스킹이 자기 줄을 넘어가면서 줄을 지우고, 그 뒤 모든 줄 번호를 어긋나게 하던 문제를 고칩니다. 같은 작업에서 마스킹이 한 번도 보지 못하던 자격증명 두 가지 — PGP 비밀키 블록과 사용자 이름 없는 Redis·AMQP URL — 도 이제 가려집니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

Kubernetes 매니페스트나 .netrc 형식 파일을 담은 저장소를 색인 중이라면 이 릴리스가 답을 바꿉니다. 마스킹이 줄을 지운 파일에서는 그 아래 모든 청크가 실제 파일의 다른 줄 번호를 달고 저장되어 있었고, find-symbol과 스니펫이 가리키는 위치가 파일 끝까지 밀려 있었습니다. 저장되는 내용이 바뀌므로 재색인이 필요합니다 — 마스킹 규칙이 바뀌면 정책 지문도 함께 바뀌므로 대부분의 ref는 다음 색인 실행에서 자동으로 다시 읽힙니다.

수정

secret: 다음 줄의 값이 값으로 읽혔습니다

• 자격증명 대입 규칙은 이름과 값 사이를 \s로 이었는데, \s는 줄바꿈을 넘어갑니다.

• YAML이 이것을 상수로 만듭니다. secret:·token:·password:는 흔한 섹션 머리글이고, 다음처럼 쓴 Kubernetes 볼륨이

  secret:
    secretName: db-creds

  secret: [REDACTED] db-creds 로 돌아왔습니다 — 키는 가려지고 값은 남았으며, 자격증명이 하나도 없는 매니페스트에 보안 이벤트가 올라갔고, 청크에서 줄 하나가 사라졌습니다.

• 이제 대입 규칙은 자기 줄 안에서 끝납니다. 값이 없는 머리글은 대입이 아니므로 건드리지 않습니다.

.netrc 세 줄이 한 줄로 합쳐졌습니다

• 진짜 .netrc는 machine·login·password를 각각 자기 줄에 적습니다. 그런데 규칙이 매치 전체를 login [REDACTED] password [REDACTED]로 갈아 끼우면서 줄바꿈을 공백으로 바꿔 버렸습니다.
• 이제 구분자를 잡아서 그대로 되돌려 씁니다. 가려지는 것은 두 값뿐이고 줄 구성은 원본 그대로입니다.

줄 하나가 사라지면 그 아래 전부가 어긋납니다

• 청크는 마스킹된 내용에서 잘라내고, 잘라낸 줄의 번호를 달아 저장됩니다.
• 그래서 위 두 규칙이 줄바꿈을 지울 때마다 그 뒤의 모든 줄 번호가 실제 파일의 다른 줄을 가리켰고, 어긋남은 파일 끝까지 누적됐습니다. 답 자체는 맞는데 따라가 보면 엉뚱한 줄인 상황입니다.
• 새 시험이 마스킹 전후의 줄 수가 같은지를 규칙 단위로 못 박습니다.

PGP 비밀키는 유일하게 통째로 색인되던 키 형식이었습니다

• 비밀키 헤더 규칙은 PRIVATE KEY-----에서 끝난다고 보았는데, PGP만 그 뒤가 더 있습니다 — -----BEGIN PGP PRIVATE KEY BLOCK-----.
• 그래서 저장소에 커밋된 .asc·.gpg 내보내기 파일은 다른 모든 키 형식이 차단되는 동안 키 자체까지 그대로 색인됐습니다.

사용자 이름 없는 URL에서는 비밀번호만 남았습니다

• URL 규칙은 :// 뒤에 한 글자 이상의 사용자 이름을 요구했습니다.
• Redis와 AMQP, 그리고 그 위에 얹힌 클라이언트들은 비밀번호만으로 인증하므로 URL을 redis://:s3cr3t@cache:6379처럼 씁니다. 그 줄에서 유일한 자격증명이 유일하게 매치되지 않는 부분이었습니다.
• 사용자 이름 자리를 비워 둘 수 있게 했습니다.

검증

• 새 시험 TestMaskingNeverChangesTheLineCount — 규칙별 대표 입력 7건에서 마스킹 전후 줄 수가 같은지. 수정 전에는 .netrc와 YAML 입력에서 실패함
• TestOrdinaryContentIsLeftAlone에 YAML 섹션 머리글 3건 추가 — 자격증명이 없는 매니페스트가 가려지지 않는지. 수정 전에는 실패함
• TestCredentialShapesAnInstallationActuallyHolds에 Redis·AMQP URL 2건, TestSanitizeBlocksAllCommonPrivateKeyPEMHeaders에 PGP 헤더 1건 추가. 수정 전에는 실패함
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, contentsecurity·indexer·search는 -race도 통과
• 버전 메타데이터 정합성, Kubernetes Kustomize 렌더링, linux/amd64 Docker 이미지 빌드

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인이 필요합니다. 마스킹은 색인할 때 적용되므로, 이미 저장된 청크의 내용과 줄 번호는 다시 읽기 전까지 그대로입니다.
• 대부분은 자동입니다. 정책 지문에 마스킹 규칙이 들어 있어서, 이번 릴리스로 올리면 지문이 바뀌고 다음 색인 실행에서 커밋이 그대로인 ref도 다시 읽힙니다.
• 다만 정책 지문이 기록되기 전에 색인된 ref는 저장된 지문이 비어 있어 "현재"로 취급됩니다(업그레이드마다 전체를 다시 읽지 않기 위한 동작입니다). 오래 색인하지 않은 저장소가 있다면 해당 ref를 수동으로 다시 색인하세요.
• 재색인 뒤에는 보안 이벤트가 줄어듭니다. 자격증명이 없는 Kubernetes 매니페스트에 올라가던 오탐이 사라지기 때문입니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.11.tar.gz
• git-ctx-v0.77.11.tar.gz.sha256

sha256sum -c git-ctx-v0.77.11.tar.gz.sha256
gzip -dc git-ctx-v0.77.11.tar.gz | docker load
docker image inspect git-ctx:v0.77.11 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.11과 git-ctx:0.77.11 태그가 포함됩니다.

전체 변경 내역: v0.77.10...v0.77.11

v0.77.10

git-ctx v0.77.10

이번 릴리스는 프로젝트가 실제로 쓰는 이름의 pip 요구사항 파일을 인벤토리가 읽지 않던 문제를 고칩니다. 인식 대상이 requirements.txt·requirements-dev.txt 두 이름의 정확 일치였기 때문에, 파이썬 프로젝트가 보통 갖는 형태가 통째로 빠져 있었습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고 대응 중이라면 이 릴리스가 통보 대상 목록을 늘립니다. pip-tools 쌍, 접두사·접미사로 갈라 쓴 이름, requirements/ 디렉터리 레이아웃에 핀을 둔 저장소는 find-dependency-usage가 보기에 그 라이브러리를 쓰지 않는 저장소와 똑같았습니다. 이번에도 판정이 아니라 저장되는 내용이 바뀌므로, 답이 달라지려면 재색인이 필요합니다.

수정

requirements.in도 requirements/base.txt도 인벤토리에 없었습니다

• Recognize는 requirements.txt와 requirements-dev.txt를 정확히 그 이름일 때만 pip 요구사항 파일로 봤습니다.
• 그래서 파이썬 프로젝트가 보통 갖는 다음 형태가 전부 읽히지 않았습니다 — pip-tools 쌍(requirements.in을 컴파일해 requirements.txt를 만드는 형태), 한 벌을 갈라 쓴 이름(requirements_test.txt, dev-requirements.txt), 그리고 대다수 Django 프로젝트가 출발점으로 삼는 환경별 한 파일 레이아웃(requirements/base.txt, requirements/prod.in).
• 핀이 한 번도 읽히지 않은 저장소는 그 라이브러리를 쓰지 않는 저장소와 구별되지 않습니다. 그런 저장소를 포함한 권고 조회는 무사 통보처럼 읽혔습니다.
• 이제 이름 규칙으로 인식합니다 — requirements 접두사·접미사(-·_·. 구분), 확장자 .txt·.in, 그리고 requirements/ 디렉터리 아래의 .txt·.in 파일.

파일 이름이 말하는 scope를 버리고 전부 direct로 적었습니다

• 요구사항 파일에는 // indirect 같은 표시가 없어서, 한 벌이 무엇에 쓰이는지 말하는 것은 파일 이름뿐입니다.
• 그런데 모든 선언이 direct로 들어갔고, 저장소가 시험에만 쓰는 도구와 서비스가 실제로 싣는 의존성이 같은 자리에 섞였습니다.
• 이제 이름이 dev·develop·development·local을 말하면 dev, test·tests·testing을 말하면 test로 기록합니다. 그 밖은 그대로 direct입니다.

This directory contains가 패키지 "This" 버전 "directory"였습니다

• 요구사항이 사는 자리의 .txt를 읽게 되면 README 같은 산문도 파서에 닿습니다.
• 요구사항 패턴은 연산자를 선택으로 두고 버전 그룹은 따로 받았기 때문에, 이름 뒤에 맨 단어가 오면 그것을 버전으로 읽었습니다 — 수정 전 실제 출력에서 This directory contains는 패키지 This의 버전 directory가 되었습니다.
• 어떤 요구사항도 연산자 없이 버전을 적지 않습니다. 그런 줄은 이제 건너뜁니다.

검증

• 새 표 TestRequirementsFilesTheWayProjectsNameThem — 인식해야 하는 이름 10건과 인식하면 안 되는 이름 4건. 수정 전에는 실패함
• 새 표 TestRequirementsScopeComesFromTheFileName — 이름에서 읽어야 하는 scope 7건. 수정 전에는 실패함
• 새 시험 TestProseIsNotARequirement — 산문 한 줄이 선언으로 새지 않는지 확인. 수정 전에는 실패함
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, manifest·indexer·search는 -race도 통과
• 버전 메타데이터 정합성, Kubernetes Kustomize 렌더링, linux/amd64 Docker 이미지 빌드

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인이 필요합니다. 의존성 인벤토리는 색인할 때 만들어지므로, 이미 색인된 저장소의 저장된 선언은 다시 읽기 전까지 그대로입니다. 요구사항 파일을 requirements.txt 이외의 이름으로 두는 저장소가 있다면 해당 ref를 다시 색인하세요.
• 재색인 뒤에는 선언 수가 늘고, dev·test scope로 갈리는 선언이 생깁니다. 그만큼 권고 조회에 걸리는 저장소도 늘어납니다.
• docs/configuration.md의 지원 매니페스트 설명에도 읽는 이름 규칙을 적었습니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.10.tar.gz
• git-ctx-v0.77.10.tar.gz.sha256

sha256sum -c git-ctx-v0.77.10.tar.gz.sha256
gzip -dc git-ctx-v0.77.10.tar.gz | docker load
docker image inspect git-ctx:v0.77.10 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.10과 git-ctx:0.77.10 태그가 포함됩니다.

전체 변경 내역: v0.77.9...v0.77.10

v0.77.9

git-ctx v0.77.9

이번 릴리스는 pyproject가 선언한 의존성 배열을 인벤토리가 한 줄에서 끊거나 아예 읽지 않던 문제를 고칩니다. extra를 쓰는 요구사항 하나가 PEP 621 배열을 문자열 한가운데서 잘랐고, 개발·시험 도구를 두는 표준 자리인 나머지 배열은 읽히지 않았습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고 대응 중이라면 이 릴리스가 통보 대상 목록을 늘립니다. black[jupyter]>=23.0 뒤에 적힌 의존성과 [project.optional-dependencies]·[dependency-groups]·[tool.pdm.dev-dependencies]에 핀된 라이브러리는 find-dependency-usage가 보기에 그 라이브러리를 쓰지 않는 저장소와 똑같았습니다. 이번에도 판정이 아니라 저장되는 내용이 바뀌므로, 답이 달라지려면 재색인이 필요합니다.

수정

black[jupyter]>=23.0 뒤의 의존성이 전부 사라졌습니다

• PEP 621 배열은 dependencies\s*=\s*\[(.*?)\]로 잘라 읽었습니다. 첫 ]에서 끝나는 패턴인데, 요구사항은 extra를 적을 때 대괄호를 스스로 가지고 있습니다.
• 그래서 dependencies = ["black[jupyter]>=23.0", "requests==2.31.0", "urllib3>=2"]는 "black[jupyter까지만 배열로 읽혔고, 그 뒤의 requests·urllib3는 통째로 없는 것이 되었습니다.
• 이제 배열은 인용·중첩·주석을 추적하는 스캐너로 읽습니다. 요구사항 안의 대괄호는 요구사항의 일부로 남고, 배열은 자기 짝이 맞는 ]에서 끝납니다.

읽히지 않던 배열이 세 종류 있었습니다

• [project]의 PEP 621 배열 하나만 읽었습니다. 나머지는 setuptools·hatch·PDM 프로젝트가 개발·시험 도구를 두는 표준 자리입니다 — [project.optional-dependencies], PEP 735의 [dependency-groups], [tool.pdm.dev-dependencies].
• 거기에 라이브러리를 핀한 저장소는 그 라이브러리를 안 쓰는 저장소와 구별되지 않았습니다. 실제로 존재하는 유일한 핀이 아무도 읽지 않는 배열에 있었습니다.
• 이제 섹션 이름이 말하는 대로 scope를 매깁니다 — extra는 optional, test라는 이름의 그룹은 test, 나머지 그룹은 dev. [project]에서는 dependencies 배열만 direct이고, classifiers나 [build-system]의 requires 같은 이웃 배열은 의존성이 아니므로 읽지 않습니다.
• 섹션 순회는 tomlSections로 뽑아 parseTOMLDependencies와 공유합니다.

urllib3!=1.25.0의 버전이 "!"였습니다

• 요구사항 패턴의 연산자 목록에 !=와 ===가 빠져 있었고, 둘 다 조용히 틀렸습니다.
• urllib3!=1.25.0은 버전 "!"로 기록됐습니다 — 무엇과도 비교할 수 없는 가짜 버전 그룹입니다. 제외는 프로젝트가 받지 않을 릴리스를 말할 뿐 실행 중인 릴리스를 말하지 않으므로, 핀이 없는 요구사항과 같이 버전을 lock 파일에 맡깁니다.
• pip===23.3.1은 버전 없음으로 읽혔습니다. 임의 동등(arbitrary equality)은 정확히 한 릴리스를 고정하므로, 핀 그대로 기록해 권고를 바로 판정할 수 있게 합니다.

검증

• 새 표 TestPyProjectReadsEveryDependencyArray — 배열 4종 9개 선언의 이름·버전·scope와, [build-system] requires·classifiers가 인벤토리로 새지 않는지 확인. 수정 전에는 실패함
• 새 표 TestRequirementOperatorsThatWereMissing — !=·===를 포함한 4개 형태와 === 핀의 Comparable. 수정 전에는 실패함
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, manifest·search·indexer는 -race도 통과
• 버전 메타데이터 정합성, Kubernetes Kustomize 렌더링, linux/amd64 Docker 이미지 빌드

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인이 필요합니다. 의존성 인벤토리는 색인할 때 만들어지므로, 이미 색인된 저장소의 저장된 선언은 다시 읽기 전까지 그대로입니다. pyproject.toml을 쓰는 저장소가 있다면 해당 ref를 다시 색인하세요.
• 재색인 뒤에는 선언 수가 늘고, 버전 !인 가짜 항목이 사라집니다. 그만큼 권고 조회에 걸리는 저장소도 늘어납니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.9.tar.gz
• git-ctx-v0.77.9.tar.gz.sha256

sha256sum -c git-ctx-v0.77.9.tar.gz.sha256
gzip -dc git-ctx-v0.77.9.tar.gz | docker load
docker image inspect git-ctx:v0.77.9 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.9과 git-ctx:0.77.9 태그가 포함됩니다.

전체 변경 내역: v0.77.8...v0.77.9

v0.77.8

git-ctx v0.77.8

이번 릴리스는 경로 아래에 선언된 TOML 의존성을 인벤토리가 통째로 놓치던 문제를 고칩니다. Cargo와 Poetry는 의존성을 더 긴 경로의 테이블에 적는 형태가 흔한데, 매니페스트 파서가 섹션 이름을 정확 일치로만 봐서 그런 선언이 전부 버려졌습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고 대응 중이라면 이 릴리스가 통보 대상 목록을 늘립니다. Cargo 워크스페이스의 멤버 크레이트와 Poetry 1.2 이후의 개발·시험 그룹은 find-dependency-usage가 보기에 그 라이브러리를 쓰지 않는 저장소와 똑같았습니다. 이번에는 판정이 아니라 저장되는 내용이 바뀌므로, 답이 달라지려면 재색인이 필요합니다.

수정

[dependencies.serde]는 인벤토리에 없었습니다

• parseTOMLDependencies는 섹션 이름이 dependencies·dev-dependencies·tool.poetry.dependencies와 정확히 같을 때만 그 안을 읽었습니다.
• 그래서 다음 네 가지가 전부 빠졌습니다 — 필드가 여럿인 선언이 흔히 쓰는 [dependencies.serde], 모노레포가 버전을 한 곳에 모으는 [workspace.dependencies], 플랫폼별 빌드의 [target.'cfg(unix)'.dependencies], Poetry 1.2가 dev-dependencies를 대체한 [tool.poetry.group.dev.dependencies].
• 의존성 테이블보다 경로가 한 칸 긴 섹션은 그 한 패키지로 읽습니다. 섹션 이름의 마지막 조각이 패키지 이름이고, 본문의 version = "1.0"이 버전입니다.

serde.workspace = true가 serde.workspace라는 패키지였습니다

• 버전을 워크스페이스 루트에 모은 모노레포에서, 멤버 크레이트는 전부 serde.workspace = true로 선언합니다. 파서는 이 키를 통째로 이름으로 읽어 이름 serde.workspace·버전 없음인 가짜 패키지를 인벤토리에 넣었습니다.
• 그 저장소는 serde 권고 조회에 걸리지 않습니다. 실제로 존재하는 유일한 핀은 아무도 읽지 않는 루트 파일에 있었고, 저장소는 serde를 쓰지 않는 것처럼 보였습니다.
• 점이 든 키는 그 키가 가리키는 패키지의 필드로 읽습니다. serde.workspace·serde.features는 이름 serde의 선언이 되고, 버전을 정하는 것은 serde.version뿐입니다. 같은 패키지가 여러 줄에 나뉘어도 하나로 합칩니다.

생태계별 섹션 판정을 분리했습니다

• Cargo는 섹션의 마지막 조각으로 판정합니다 — dependencies는 direct, dev-dependencies·build-dependencies는 dev. [workspace.dependencies]도 [target.'cfg(unix)'.dependencies]도 저장소의 실제 의존성입니다.
• Poetry는 [tool.poetry.group.<이름>.dependencies]를 그룹 이름으로 판정합니다 — test 그룹은 test, 나머지 그룹은 dev. PEP 621 배열과 기존 표기는 그대로입니다.

검증

• 새 표 TestTOMLDependenciesStatedUnderAPath — Cargo 6건(워크스페이스 dotted key, 서브테이블, target 아래 테이블, dev 서브테이블)과 필드가 패키지로 새지 않는지 확인하는 6건, Poetry 4건(서브테이블, dev 그룹, test 그룹). 수정 전에는 실패함
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, manifest·search·indexer는 -race도 통과
• 버전 메타데이터 정합성, Kubernetes Kustomize 렌더링, linux/amd64 Docker 이미지 빌드

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인이 필요합니다. 의존성 인벤토리는 색인할 때 만들어지므로, 이미 색인된 저장소의 저장된 선언은 다시 읽기 전까지 그대로입니다. Cargo 워크스페이스나 Poetry 그룹을 쓰는 저장소가 있다면 해당 ref를 다시 색인하세요.
• 재색인 뒤에는 선언 수가 늘고, 이름 *.workspace 같은 가짜 항목이 사라집니다. 그만큼 권고 조회에 걸리는 저장소도 늘어납니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.8.tar.gz
• git-ctx-v0.77.8.tar.gz.sha256

sha256sum -c git-ctx-v0.77.8.tar.gz.sha256
gzip -dc git-ctx-v0.77.8.tar.gz | docker load
docker image inspect git-ctx:v0.77.8 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.8과 git-ctx:0.77.8 태그가 포함됩니다.

전체 변경 내역: v0.77.7...v0.77.8

v0.77.7

git-ctx v0.77.7

이번 릴리스는 권고 판정이 표시 개수에 잘려 일부 저장소를 아무 데도 세지 않던 문제를 고칩니다. 조회는 표시 limit의 네 배에서 멈추는데 절단 통지는 다섯 배 큰 상수와 비교하고 있어서, 기본 설정에서는 조회가 끊겼다는 말이 한 번도 나오지 않았습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고 대응 중이라면 이 릴리스가 통보 대상 목록을 늘립니다. 널리 쓰이는 패키지의 권고에서 앞쪽 400개 선언 밖에 있던 저장소는 영향으로도 안전으로도 세지 않았고, 결과는 그 저장소들에 대해 무사 통보처럼 읽혔습니다. 저장된 내용이 아니라 조회 범위가 바뀐 것이라 재색인 없이 답이 달라집니다.

수정

영향 3개 · 안전 9개가 앞쪽 400건만 보고 나온 수치였습니다

• 인벤토리 질의는 LIMIT min(limit*4, 2000)으로 선언을 읽습니다. 기본 limit이 100이므로 실제 한계는 400건입니다.
• 그런데 절단 통지는 상수 2000과 비교했습니다. limit이 500 이상일 때가 아니면 통지는 절대 뜨지 않습니다.
• 그래서 널리 선언된 패키지의 권고는 앞쪽 400개 선언만 읽고 "영향 N개 · 안전 M개"를 냈습니다. 정렬이 이름 → library_id 순이라 뒤쪽 저장소가 통째로 빠졌고, 빠진 저장소는 영향에도 안전에도 판정 불가에도 없었습니다. 세지 않은 것과 안전한 것을 답만 보고는 구분할 수 없습니다.

판정은 조회 한계까지 봅니다

• 수정 버전(fixedIn)이 있는 질의 — 즉 권고 판정 — 은 표시 limit과 무관하게 dependencyScanLimit(2000)까지 조회합니다. 판정이 매치 전체를 대변한다는 것은 원래부터의 약속이었고, 이제 조회가 그 약속에 맞습니다.
• 표시 limit은 목록만 제한합니다. 반환되는 선언 목록의 길이는 종전 그대로입니다.

조회가 끊기면 그 사실을 말합니다

• 절단 통지는 실제로 적용된 한계와 비교합니다. 권고 없는 질의에서 400건에 닿으면 이제 "상위 400건만 확인했습니다"라고 정확히 말합니다.
• 권고 중 절단이 실제로 일어나면 문구가 달라집니다 — "선언 N건에서 조회를 끊었습니다. 그 뒤의 저장소는 영향·안전·판정 불가 어디에도 세지 않았으므로 아래 집계는 불완전합니다." 그 상황에서 절단은 표시상의 사정이 아니라 수치의 신뢰도 문제이기 때문입니다.

검증

• 새 표 TestAdvisoryJudgesEveryMatchNotOnlyTheListedOnes — 저장소 12개·limit 1에서 전부 판정되는지, 목록은 1건인지, 권고 없는 질의는 "상위 4건만 확인했습니다"를 내는지. 수정 전에는 affected가 2개만 나와 실패함
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, search·mcp는 -race도 통과
• FTS5 빌드·태그 없는 빌드·PostgreSQL 3가지 조합 전체 단위·통합·race 테스트, 빌드 모드 교차 시험, 릴리스 데이터베이스 업그레이드 시험, 콘솔 시험

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인은 필요하지 않습니다. 저장된 선언은 그대로이고, 판정이 읽는 범위만 넓어집니다.
• 널리 쓰이는 패키지의 권고에서 영향 저장소가 더 나올 수 있습니다. 그것이 이번 수정의 목적입니다. 이전 답으로 통보를 끝냈다면 다시 질의해 보세요.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.7.tar.gz
• git-ctx-v0.77.7.tar.gz.sha256

sha256sum -c git-ctx-v0.77.7.tar.gz.sha256
gzip -dc git-ctx-v0.77.7.tar.gz | docker load
docker image inspect git-ctx:v0.77.7 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.7과 git-ctx:0.77.7 태그가 포함됩니다.

전체 변경 내역: v0.77.6...v0.77.7

v0.77.6

git-ctx v0.77.6

이번 릴리스는 이름이 부분만 겹치는 이웃 패키지 때문에 저장소가 "영향"으로 보고되던 문제를 고칩니다. 인벤토리 질의는 이름을 일부러 부분 일치로 찾는데, 권고 판정이 그렇게 걸려 온 선언까지 질의한 패키지의 버전인 양 읽고 있었습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고 대응 중이라면 이 릴리스가 통보 대상 목록을 바꿉니다. "영향"으로 지목돼 CODEOWNERS 소유자까지 조회됐던 저장소 일부는 그 라이브러리를 쓰지 않습니다. 저장된 내용이 아니라 판정 방식이 바뀐 것이라 재색인 없이 답이 달라집니다.

수정

requests 권고가 requests-toolbelt을 쓰는 저장소를 지목했습니다

• 인벤토리 질의는 이름을 부분 일치로 찾습니다. 운영자가 손에 든 것은 권고가 부르는 라이브러리 통칭이지 매니페스트가 적는 좌표가 아니라서, log4j가 org.apache.logging.log4j:log4j-core를 찾아 주어야 하기 때문입니다.
• 그런데 같은 규칙이 requests에 requests-toolbelt을 물어 왔고, 수정 버전 판정은 걸려 온 모든 선언의 버전을 질의한 패키지의 버전으로 읽었습니다.
• 그래서 requests 2.31.0 권고에 requests-toolbelt 0.10.1을 쓰는 저장소가 "영향"으로 보고되고, 그 저장소의 소유자가 CODEOWNERS에서 조회되어 통보 대상에 올랐습니다. 쓰지도 않는 라이브러리의 취약점 때문입니다.

판정은 질의한 패키지의 선언만 봅니다

• 이름 전체가 같거나, 이름의 온전한 한 조각일 때만 같은 패키지로 봅니다 — maven group·artifact, 모듈 경로나 scoped 패키지의 경로 요소, group의 마지막 점 구분 조각.
• 좌표는 그대로 걸립니다 — log4j → org.apache.logging.log4j:log4j-core, gin-gonic/gin → github.com/gin-gonic/gin.
• 접두사나 하이픈 한 단어만 겹치는 이름은 판정에서 빠집니다 — requests 대 requests-toolbelt.
• 제외한 선언은 응답에서 사라지지 않습니다. Declarations에는 그대로 남고, 어떤 패키지를 왜 뺐는지 notes에 이름과 함께 적습니다(이름이 많으면 5개까지, 나머지는 개수로).
• 권고 없는 질의는 종전 그대로 부분 일치 전체를 묶어 보여 줍니다. 거기서 넓은 매칭은 주장이 아니라 탐색을 돕는 장치이기 때문입니다.

limit을 넘는 저장소가 판정에서 말없이 빠졌습니다

• 판정용 버전 그룹을 limit으로 잘린 목록이 아니라 조회한 선언 전체에서 만듭니다.
• 락파일 우선 재그룹이 잘린 목록을 읽고 있어서, 상위 N건 밖의 저장소는 아무 말 없이 판정 대상에서 빠질 수 있었습니다.

검증

• 새 표 TestAdvisoryJudgesOnlyTheQueriedPackage — 이웃 패키지가 "영향"을 만들지 않고, Declarations에는 남으며, notes가 제외한 이름을 말하는지
• 새 표 TestAdvisoryStillReachesTheCoordinate — log4j·gin-gonic/gin 같은 통칭이 여전히 좌표에 닿는지
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, search·mcp는 -race도 통과
• FTS5 빌드·태그 없는 빌드·PostgreSQL 3가지 조합 전체 단위·통합·race 테스트, 빌드 모드 교차 시험, 릴리스 데이터베이스 업그레이드 시험, 콘솔 시험

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인은 필요하지 않습니다. 인벤토리에 저장된 선언은 그대로이고, 그 선언을 판정에 쓰는 범위만 달라집니다.
• 이전에 "영향"으로 돌아오던 저장소 일부가 이제 목록에서 빠집니다. 그것이 이번 수정의 목적입니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.6.tar.gz
• git-ctx-v0.77.6.tar.gz.sha256

sha256sum -c git-ctx-v0.77.6.tar.gz.sha256
gzip -dc git-ctx-v0.77.6.tar.gz | docker load
docker image inspect git-ctx:v0.77.6 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.6과 git-ctx:0.77.6 태그가 포함됩니다.

전체 변경 내역: v0.77.5...v0.77.6

v0.77.5

git-ctx v0.77.5

이번 릴리스는 캐럿(^)·틸드(~) 범위가 이미 답을 정해 놓은 권고를 "판정 불가"로 돌려주던 문제를 고칩니다. 범위가 하한만 있는 것처럼 읽혔기 때문에, npm·Cargo·PEP 440 매니페스트가 실제로 가장 많이 쓰는 두 표기가 통째로 결정에서 빠져 있었습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

권고가 올 때마다 운영자가 저장소를 하나씩 손으로 확인하고 있었다면, 이 릴리스가 그 목록을 줄입니다. 저장된 내용이 아니라 판정 방식이 바뀐 것이라 재색인 없이 답이 달라집니다.

수정

~2.14.0은 2.17.1에 닿을 수 없는데도 "판정 불가"였습니다

• 캐럿과 틸드는 하한과 상한을 함께 말합니다. 그런데 판정은 하한만 읽고 둘 다 열린 범위로 취급했습니다.
• 그래서 ~2.14.0(2.15.0 미만)을 선언한 저장소는 수정 버전이 2.17.1인 권고에 대해, ^1.2.3(2.0.0 미만)을 선언한 저장소는 수정 버전이 2.0.0인 권고에 대해 **"매니페스트만으로는 결정할 수 없다"**고 답했습니다. 어느 범위도 수정본을 담은 릴리스에 도달할 수 없는데도 그랬습니다.
• 이제 선언은 도달할 수 없는 첫 릴리스를 함께 돌려줍니다. 하한이 수정 버전 아래이고 그 상한이 수정 버전 이하이면 영향입니다.

상한을 읽는 규칙

• 캐럿은 맨 왼쪽 0이 아닌 자리를 올립니다 — ^1.2.3→2.0.0, ^0.2.3→0.3.0, ^0.0.3→0.0.4.
• 틸드는 major·minor를 유지합니다 — ~1.2.3·~=1.2.3→1.3.0.
• 자릿수가 모자라 생태계마다 해석이 갈리는 ~1.2·^0.2는 넓은 쪽을 택합니다(npm은 ~1.2를 1.3.0에서, PEP 440은 ~=1.2를 2.0.0에서 멈춥니다). 상한은 "영향" 판정만 만들 수 있기 때문에, 너무 좁게 잡으면 없는 영향을 지어냅니다.

열린 하한은 종전 그대로입니다

• >=2.14.1처럼 상한이 없는 선언은 수정 버전 아래에서 여전히 아무것도 결정하지 않습니다. 그런 범위는 수정본을 담은 릴리스에 도달할 수 있고, 매니페스트는 어느 쪽인지 말하지 않습니다.

검증

• 새 표 TestBoundedRangeBelowTheFixIsAffected — 상한이 결정하는 영향 10건, 상한이 수정 버전을 넘어 여전히 판정 불가 6건, 열린 하한이 안전으로 남는 4건
• 기존 TestRangeBelowTheFixIsUndecided의 틸드 사례는 이제 실제로 결정 가능하므로, 수정 버전이 범위 안에 드는 사례(~2.14.0 대 2.14.5)로 교체
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, manifest·search는 -race도 통과
• FTS5 빌드·태그 없는 빌드·PostgreSQL 3가지 조합 전체 단위·통합·race 테스트, 빌드 모드 교차 시험, 릴리스 데이터베이스 업그레이드 시험, 콘솔 시험

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인은 필요하지 않습니다. 인벤토리에 저장된 선언은 그대로이고, 그 선언을 읽는 방식만 달라집니다.
• 이전에 "판정 불가"로 돌아오던 저장소 일부가 이제 **"영향"**으로 돌아옵니다. 그것이 이번 수정의 목적입니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.5.tar.gz
• git-ctx-v0.77.5.tar.gz.sha256

sha256sum -c git-ctx-v0.77.5.tar.gz.sha256
gzip -dc git-ctx-v0.77.5.tar.gz | docker load
docker image inspect git-ctx:v0.77.5 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.5과 git-ctx:0.77.5 태그가 포함됩니다.

전체 변경 내역: v0.77.4...v0.77.5

v0.77.4

git-ctx v0.77.4

이번 릴리스는 따옴표로 감싼 이름과 네임스페이스가 붙은 이름의 크리덴셜이 마스킹되지 않던 문제를 고칩니다. 규칙이 맨 이름만 읽었기 때문에, 설정 파일이 흔히 쓰는 표기법 두 가지가 통째로 규칙 밖에 있었습니다. 기본 서비스 포트는 계속 4747이며 기존 API·MCP 호환성을 유지합니다.

{"password": "hunter22"}는 마스킹 없이 색인되고 스니펫으로 그대로 반환됐습니다. JSON·Terraform 설정을 색인한 저장소가 있다면 이 릴리스가 그 답을 바꿉니다.

수정

따옴표 친 이름의 크리덴셜이 한 번도 마스킹되지 않았습니다

• 대입 규칙이 맨 이름만 읽었습니다. JSON과 Terraform은 키를 따옴표로 적기 때문에, 이름과 콜론 사이에 닫는 따옴표가 끼면서 규칙이 아예 매치되지 않았습니다.
• 그래서 {"password": "hunter22"}, "api_key" = "abcd..."는 마스킹 없이 색인됐고, 검색 결과 스니펫에도 원문 그대로 실려 나갔습니다. appsettings.json, Postman 컬렉션, Terraform 변수 파일처럼 크리덴셜이 가장 자주 적히는 형식이 전부 여기에 해당합니다.
• 이제 여는·닫는 따옴표를 선택적으로 읽습니다. 따옴표 없는 맨 이름은 종전과 똑같이 매치됩니다.

<con:password>가 놓쳤습니다

• XML 요소 규칙은 이름이 < 바로 뒤에 오기를 요구했습니다.
• 그런데 이 플랫폼이 색인하는 soapUI 프로젝트, WSDL 바인딩, WebSphere·Spring 서술자는 요소에 네임스페이스 접두사를 붙여 <con:password>로 적습니다. 그 형식은 하나도 마스킹되지 않았습니다.
• 이제 접두사를 이름과 함께 캡처하므로, 값을 치환한 뒤에도 여는 태그와 닫는 태그가 짝을 유지합니다.

대입이 아닌 인용 이름은 그대로 둡니다

• fields["password"] = lookup(name)처럼 이름만 인용됐을 뿐 크리덴셜이 대입되지 않은 코드는 건드리지 않습니다. 따옴표를 허용하면서 과마스킹으로 넘어가지 않는지 별도 표에서 확인합니다.

검증

• 크리덴셜 shape 표에 4건 추가 — JSON 객체, 공백이 들어간 인용 키, Terraform 대입, 네임스페이스가 붙은 XML 요소
• 과마스킹 방지 표에 3건 추가 — 대입 없는 인용 이름이 그대로 남는지 확인
• gofmt -l, go vet ./..., FTS5 빌드·전체 테스트 통과, contentsecurity·indexer·search는 -race도 통과
• FTS5 빌드·태그 없는 빌드·PostgreSQL 3가지 조합 전체 단위·통합·race 테스트, 빌드 모드 교차 시험, 릴리스 데이터베이스 업그레이드 시험, 콘솔 시험

업그레이드 참고

• 마이그레이션은 필요하지 않습니다.
• 재색인은 저절로 일어납니다. 마스킹 리비전이 패턴에서 유도되므로, 구 규칙으로 색인된 ref는 다음 색인에서 스스로 다시 읽힙니다.
• 이전에 크리덴셜이 그대로 실려 나가던 스니펫이 이제 마스킹되어 돌아옵니다. 그것이 이번 수정의 목적입니다.

오프라인 Docker 이미지

릴리스 자산은 아키텍처 접미사가 없는 다음 두 파일입니다.

• git-ctx-v0.77.4.tar.gz
• git-ctx-v0.77.4.tar.gz.sha256

sha256sum -c git-ctx-v0.77.4.tar.gz.sha256
gzip -dc git-ctx-v0.77.4.tar.gz | docker load
docker image inspect git-ctx:v0.77.4 --format '{{.Os}}/{{.Architecture}} {{.Config.User}}'

기대 결과는 linux/amd64 10001입니다. 아카이브에는 git-ctx:v0.77.4과 git-ctx:0.77.4 태그가 포함됩니다.

전체 변경 내역: v0.77.3...v0.77.4