네이티브 리스펙스를 사용하세요. 아래 명령은 Bash용이며 Windows에서는 Git Bash로 실행할 수 있습니다. 새 디렉터리에서 시작하고 실행할 때마다 새 출력 경로를 지정하세요.
파일 네 개 준비하기
입력 [2, false]는 절 제목 아래에 2줄이 남았다는 뜻입니다. 규칙은 house-style.lspx, 입력은 heading.json으로 저장하세요. 같은 디렉터리에 아래 한도 파일 두 개도 만드세요.
(let ((남은-줄 (car input))
(장-제목? (car (cdr input))))
(if (< 남은-줄 2)
"deny"
(if 장-제목? "deny" "allow")))[2, false]prepare-limits.json은 규칙을 준비할 때 사용할 한도를 정합니다.
{
"raw_source_bytes": 4096,
"prepare_work": 1000000,
"logical_allocation": 1000000,
"syntax_depth": 64
}evaluation-limits.json은 입력 하나를 평가하고 결과를 기록할 때 사용할
한도를 정합니다.
{
"canonical_input_bytes": 4096,
"eval_work": 1000000,
"logical_allocation": 1000000,
"semantic_frames": 1000,
"traversal_depth": 256,
"output_bytes": 1000000,
"diagnostic_bytes": 1000000,
"transcript_bytes": 1000000,
"transcript_events": 100,
"result_bytes": 1000000
}lispex rule run --source house-style.lspx --input heading.json \
--prepare-limits prepare-limits.json \
--eval-limits evaluation-limits.json --out decision
lispex rule inspect --dir decision
lispex rule verify --dir decision
lispex rule replay --dir decision네 명령은 모두 종료 코드 0으로 끝나며 JSON을 출력합니다. 아래 표는 실제 출력에서 필요한 필드만 발췌한 것입니다.
| 명령 | 출력 필드 |
|---|---|
rule run | "decision": "allow", "category": "semantic-complete" |
rule inspect | "decision": "allow", "executed": false |
rule verify | "status": "verified", "executed": false |
rule replay | "status": "agreed", "fresh_instance": true |
애플리케이션이 남은 줄 수와 장 제목 여부를 전달합니다. allow는 제목을 그대로 둔다는 뜻이고 deny는 다음 쪽으로 넘긴다는 뜻입니다.
| 입력 | 결정 | 이유 |
|---|---|---|
[2, false] | allow | 절 제목 아래에 2줄이 들어감 |
[1, false] | deny | 제목 아래 공간이 모자람 |
[5, true] | deny | 장 제목은 새 쪽에서 시작함 |
저장한 파일 다섯 개 확인하기
rule run은 완성된 decision 디렉터리를 한 번에 씁니다.
원본 소스는 입력 파일과 함께 따로 보관하세요.
| 파일 | 내용 |
|---|---|
prepared.lpxembed | 정해진 실행 형식으로 준비한 규칙 |
canonical-input.lpxvalue | 하나로 정해진 바이트 표현의 요청 값 |
result.lpxembed | 결과와 해당 요청의 연결 정보 |
receipt-core.lpxreceipt | 규칙과 입력, 한도, 평가기, 상세 실행 기록, 결과를 연결하는 이식 가능한 핵심 기록 |
summary.json | 위 기록에서 읽기 쉽게 정리한 요약 |
rule inspect는 저장된 데이터를 읽습니다. rule verify는 파일 구성과
식별자, 해시, 기록 간 연결을 검사합니다. rule replay는 새 평가기
인스턴스에서 요청을 실행하고 결과와 핵심 기록을 모두 비교합니다.
파일 형식이 잘못됐거나 기록이 변조됐다면 검사를 거부합니다.
결정에 서명하고 발급자 인증하기
이 로컬 실습은 키 쌍을 만들고 방금 검사한 결정으로 수신자 정책을 만듭니다. 개인 키는 결정 디렉터리와 소스 관리 밖에 보관하세요. 발급자와 수신자를 나누어 연습하려면 조판 규칙 작업 공간를 따라 하세요. 그 예제에서는 수신자가 공개키와 허용할 규칙을 독립적으로 검토합니다.
lispex key generate --out-dir issuer-key
lispex rule issue --dir decision \
--private-key issuer-key/private.pkcs8.der \
--issuer-label "Publisher A" \
--out issuer-envelope.json
lispex rule policy create --dir decision \
--public-key issuer-key/public.spki.der \
--consumer-label "Print receiver" \
--out recipient-policy.json
lispex rule authenticate --dir decision \
--envelope issuer-envelope.json \
--policy recipient-policy.json
lispex decision issue --dir decision \
--private-key issuer-key/private.pkcs8.der \
--issuer-label "Publisher A" \
--out heading.lpxdecision
lispex decision inspect --bundle heading.lpxdecision
lispex decision authenticate --bundle heading.lpxdecision \
--policy recipient-policy.json
lispex decision replay --bundle heading.lpxdecision \
--policy recipient-policy.json각 명령은 종료 코드 0으로 끝납니다. 아래 표는 생성 파일과 실제 출력의 주요 필드를 보여 줍니다.
| 명령 | 생성 파일 또는 출력 |
|---|---|
key generate | issuer-key/private.pkcs8.der와 issuer-key/public.spki.der 생성, "status": "generated" |
rule issue | issuer-envelope.json 생성, "status": "issued" |
rule policy create | recipient-policy.json 생성, 표준 출력 없음 |
rule authenticate | package_integrity.status가 verified, signature_valid와 policy_admitted가 true |
decision issue | heading.lpxdecision 생성, "status": "issued" |
decision inspect | "decision": "allow", "executed": false |
decision authenticate | request_binding.status가 exact, signature_valid와 policy_admitted가 true |
decision replay | "decision": "allow", "status": "agreed", "fresh_instance": true |
.lpxdecision 묶음은 정해진 바이트 형식으로 항목 일곱 개를 담습니다.
앞의 파일 다섯 개에 구성 목록과 정보를 담은 매니페스트, 발급자가 서명한
기록 묶음이 더해집니다. 네이티브는 이 묶음을 발급하고 검사하고 인증하고
재실행합니다. npm은 오프라인 검사와 인증을 제공합니다.
할 일에 맞는 기록 사용하기
결정 인증은 묶음의 무결성과 발급자 서명, 수신자 정책의 허용 여부, 요청과의 연결을 확인합니다. 재실행은 새 실행 결과를 더합니다.
리스펙스 바우치는 별도로 서명한 상세 실행 기록과 수신자가 독립적으로 제공한 요청을 사용합니다. 로컬 게이트는 현재 네이티브 실행이 요구한 결정을 내는지 확인합니다. 애플리케이션은 요청의 유효 시점을 확인하고 중복 사용을 막으며, 업무 행동을 허가하고 수행합니다.