1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
//! Git-LFS pointer recognition.
//!
//! A file tracked by [Git LFS](https://git-lfs.github.com) is committed not as
//! its real bytes but as a tiny text *pointer*, the actual blob lives in LFS
//! storage and is only materialised on `git lfs pull`. A canonical pointer is:
//!
//! ```text
//! version https://git-lfs.github.com/spec/v1
//! oid sha256:<64 lowercase hex>
//! size <decimal bytes>
//! ```
//!
//! The spec fixes the `version` line first and then lists the remaining keys in
//! alphabetical order, so `oid` always precedes `size`; optional `ext-*` lines
//! may appear between `version` and `oid`.
//!
//! Two consumers share this recognition, which is why it lives in `core`:
//! * the scanner suppresses the pointer's 64-hex `oid` (it is a content hash,
//! not a leaked secret, yet matches a generic high-entropy hex shape), and
//! * a source records a coverage gap, the pointer's real blob (`size` bytes)
//! was NOT scanned, so a repo of unmaterialised LFS pointers is not
//! reported as a false-clean.
//!
//! Recognition is deliberately strict (all three well-formed lines, in order):
//! a false positive would suppress a real credential, and a whole-file pointer
//! is unambiguous, so strictness costs no recall.
/// The exact first line of every Git-LFS pointer. Compared case-insensitively
/// because the recognition is content-classification, not byte-exact parsing.
pub const GIT_LFS_VERSION_LINE: &str = "version https://git-lfs.github.com/spec/v1";
/// The number of hex characters in a `sha256` object id.
///
/// Canonical owner for the whole `keyhog-core` crate: a `sha256` digest is 32
/// bytes, i.e. 64 lowercase hex characters, whether it names a Git-LFS blob
/// (here) or a compiled-pattern cache file (`hardening.rs`).
pub const SHA256_HEX_LEN: usize = 64;
/// True if `line` (ignoring surrounding ASCII whitespace) is the Git-LFS
/// `version` line.
/// True if `line` is a Git-LFS `oid sha256:<64 hex>` line. The 64-hex body is
/// what the scanner must NOT flag as a secret.
/// True if `line` is a Git-LFS `size <decimal>` line.
/// True if `content` is a whole Git-LFS pointer file: a `version` line, then an
/// `oid` line, then a `size` line, in that spec-mandated order. Lines that are
/// none of the three (e.g. optional `ext-*` lines, or blank lines) are tolerated
/// between the anchors, matching real pointers.
///
/// Cheap: an O(n) single pass over the (tiny, <200 byte) pointer, and callers
/// that scan large files should gate on the size/prefix first, a real pointer
/// begins with [`GIT_LFS_VERSION_LINE`].
// Tests live in `tests/unit/git_lfs_sha256_hex_len_owner.rs` (KH-GAP-004: no
// inline test modules in `src/`).