disclude.ioghapi 2.1.4
- Source
- https://github.com/fastai/ghapi
- Tag scanned
2.1.4- Compared with
2.1.3(35 signals introduced since)- Files
- 23 scanned, 68 skipped (binary, oversized, or unrecognised)
- Signals
- 0 critical · 0 warn · 52 info
- Scan time
- 30.0 s
- LLM review
- Reviewed by claude-haiku-5-5 (Anthropic): 38 of 38 warn and critical signals; 38 demoted to info.
- Disclude version
- 4.0.0
- Scanned (UTC)
- 2026-10-14 18:52
Signals
Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.
-
:likely benign Base64 value (log key identifier) inside an embedded GitHub attestation verification structure.Reasoning
The blob sits inside a large embedded API specification dictionary. It is a 44-byte base64 value in a Sigstore transparency-log verification structure, which is a legitimate data field. Raw-pass base64 hits in data files have a high false-positive rate.
-
: ,likely benign Base64 signed entry timestamp in an embedded Sigstore attestation example.Reasoning
The 96-byte base64 string is a signedEntryTimestamp, an ECDSA signature field in a Sigstore inclusion promise. It is expected data in an API spec and is not encoded code.
-
: ,likely benign Base64 SHA-256 rootHash value in an embedded attestation structure.Reasoning
This is a base64 SHA-256 digest (44 characters with a trailing '=') in a rootHash field of a Merkle-tree attestation structure. Hashes like this are expected in the spec.
-
:likely benign Base64 SHA-256 hash entry in an embedded attestation hashes list.Reasoning
This is a base64 SHA-256 digest in a hashes list, the same kind of Merkle-tree attestation data. It is a legitimate data constant.
-
,likely benign Base64 SHA-256 hash value in an embedded attestation structure.Reasoning
This is a base64 SHA-256 digest in the same attestation data block. It has the normal shape of a hash value and no decoding or execution is involved.
-
,likely benign Base64 SHA-256 hash value in an embedded attestation structure.Reasoning
This is a base64 SHA-256 digest in the same attestation data block. It is a static data constant in a spec file.
-
,likely benign Base64 SHA-256 hash value in an embedded attestation structure.Reasoning
This is a base64 SHA-256 digest in the same attestation data block. It is a static data constant with no execution path.
-
,likely benign Base64 SHA-256 hash value in an embedded attestation structure.Reasoning
This is a base64 SHA-256 digest in the same attestation data block. It is a static data constant with no execution path.
-
,likely benign Base64 SHA-256 hash value in an embedded attestation structure.Reasoning
This is a base64 SHA-256 digest in the same attestation data block. It is a static data constant with no execution path.
-
,likely benign Base64-encoded 32-byte value in an embedded GitHub API spec for attestations.Reasoning
The snippet is a 44-byte base64 string ending in '=' inside a large embedded GitHub API spec dict, alongside attestation-related fields. Such values are typically sample hashes or keys in API documentation, not a payload.
-
,likely benign Base64-encoded 32-byte example value within the GitHub API spec data.Reasoning
The same pattern as the neighbouring entries: a 32-byte base64 value with padding, in a list of example values inside a generated API spec file. It is data, not executed code.
-
,likely benign Base64 sample value in a list inside the GitHub API spec.Reasoning
A sequence of consecutive 44-character base64 strings with a common layout, consistent with documented sample hashes or public keys in a generated spec file. Nothing in the snippet decodes or executes them.
-
,likely benign Base64-encoded digest-like string in the GitHub API spec data.Reasoning
A standard 32-byte base64 digest-like string in a literal list in an API spec module. The context is documentation data for attestation examples, and the snippet shows no decoding or execution.
-
,likely benign Base64-encoded example hash in the GitHub API spec.Reasoning
Another 44-character padded base64 value in a list of example attestation data. High entropy is expected for hashes and keys, and the file is a generated API spec.
-
,likely benign Base64-encoded example value in the GitHub API spec.Reasoning
A padded 32-byte base64 string in the same literal list of spec examples. It is static data with no decode or execution path visible.
-
],likely benign Final base64 example value closing a list in the GitHub API spec.Reasoning
The last entry of the same list of base64 example values in the generated spec. The closing bracket shows it is a plain data literal.
-
:likely benign Sigstore Rekor checkpoint envelope with a base64 signature in the API spec example.Reasoning
The snippet has a Sigstore/Rekor transparency-log checkpoint envelope with a base64 signature line and a log origin string. This is the documented format for a checkpoint in an attestation example, not obfuscation.
-
}},likely benign Base64 ECDSA signature in an attestation bundle example.Reasoning
The base64 value begins with the DER prefix MEUCI/MEQCI/MFkw-style ECDSA signature structure and is followed by a newline escape and a dict close, consistent with an example Sigstore signature in an attestation bundle.
-
: }}}}}, : },likely benign Base64 ECDSA signature in an attestation example with a documentation link.Reasoning
A base64 DER-encoded ECDSA signature ('MEQCI...') inside a nested signatures structure with a docs_url pointing to GitHub's attestation documentation. This is documentation example data.
-
:likely benign Gzip-compressed base64 example SARIF document in the GitHub API spec.Reasoning
The value is a gzip-compressed base64 blob ('H4sI' is the gzip header) holding an example SARIF file, stored as an example response in the API spec. Compression is a common way to embed sample payloads, and nothing here decodes or runs it automatically.
-
likely benign A base64-encoded line, probably embedded PGP/key material, in the ghapi spec module.
Reasoning
Raw-pass base64 match on a 64-character line inside a generated API spec module. The 'iQIzBAABAQAdFiEE' and 'CACgkQ' fragments look like the start of a PGP key or signature packet, which is embedded binary data, not an obfuscated payload. No decode or execution call appears in the snippet, and raw findings carry a high false-positive rate.
-
likely benign Another base64 line from the same embedded key-like block.
Reasoning
Consecutive base64 line in the same embedded block as 11487. It is a plain string literal with no decode or execution, and the block is consistent with an armored key.
-
likely benign Base64 continuation line within the embedded key-like data.
Reasoning
Same embedded base64 block continuing across lines with no code consuming it. The raw pass flags high-entropy text, which armored key data reliably produces.
-
likely benign Base64 line of embedded key-like data.
Reasoning
Same embedded block, with no decode call or execution visible. Consistent with armored cryptographic material in a library data file.
-
likely benign Base64 line from the static embedded data block.
Reasoning
Continuation of the same base64 literal block. Nothing in the snippet decodes or runs it, and the structure is a static data string.
-
likely benign Base64 data line in the embedded block.
Reasoning
Same static base64 block with no decode or execution path visible. The flag is a raw entropy match on binary-looking data typical of embedded keys.
-
likely benign Base64 line in the static data block.
Reasoning
Part of the same consecutive base64 literal. Static data with no consumer in the snippet; the raw-pass signal is weak here.
-
likely benign Base64 data line within the embedded block.
Reasoning
Continuation of the same static base64 literal. No dropper or dynamic execution indicated, and the pattern matches embedded key material.
-
likely benign Base64 line of static embedded data.
Reasoning
Same embedded block, with no decode call or execution visible. Consistent with armored key data in a library file.
-
likely benign Base64 data line closing the embedded block.
Reasoning
Final visible line of the same static base64 block. No runtime use is shown, and the raw-pass match on random-looking text is expected for armored key material.
-
likely benign A base64-encoded PGP signature embedded as a string literal in the GitHub API spec module.
Reasoning
Raw-pass base64 match on a multi-line string that is part of a PGP signature block (the next line shows '-----END PGP SIGNATURE-----'). This is a literal signature in an API spec fixture, not an encoded payload. Raw findings have a high false-positive rate, and this one is a standard data blob.
-
}}},likely benign Tail of a PGP signature armor block stored as string data in the GitHub API spec file.Reasoning
The same PGP signature block, continuing with the armor checksum line '=5Io4' and the END marker. It is a documentation or example signature in a generated API spec, with no execution or decoding logic nearby in the snippet.
-
:likely benign An example OIDC JSON Web Token string literal inside the GitHub API spec.Reasoning
The value is a JWT (header starts 'eyJ0eXAiOiJKV1Qi'), used as an 'oidc_token' example in an API spec. JWTs in example payloads are common, and the string is just data with no decoding or execution in the snippet.
-
-likely benign Remaining JWT segment (payload and signature) of the example OIDC token in the spec data.Reasoning
A continuation of the same JWT example string, with the payload and signature segments in base64url form. This is a sample credential-shaped value in a spec file, not an obfuscated dropper.
-
likely benign Final portion of the example JWT signature string embedded in the GitHub API spec dictionary.
Reasoning
Another fragment of the same long base64url JWT signature string inside a literal, with a closing quote and brace structure consistent with a dict of example data. No decoding or execution appears in the snippet.
-
-
likely benign README instruction to eval the output of completion-ghapi --install to enable shell completion.
Reasoning
The eval wraps output of the package's own completion-install subcommand. This is the common shell-completion setup idiom in CLI tools, and the expression is not an obfuscated payload or a download-and-run chain. It is still dynamic execution, so the confidence is not higher.
-
# %% ../nbs/04_event.ipynb #8232d504likely benign Dynamically creates GhEvent subclasses by exec-ing a generated class statement for each event name.Reasoning
exec builds event subclasses from a known list of event names via snake2camel. The gzip import is in the same file but the snippet shows no decoding feeding into exec, so the multi-stage payload shape is not present. This is ordinary metaprogramming for generating classes.
-
# %% ../nbs/04_event.ipynb #4de78d50 return # %% ../nbs/04_event.ipynb #e3e61809likely benign Looks up an event class by name from globals() to cast an event object.Reasoning
globals() lookup maps an event type string to a class defined in the same module, which is a standard dispatch pattern. The lookup key comes from the API's own event type field and the target is a module-local class, so there is no sign of an attacker-controlled name reaching a sensitive sink.
-
: , -
: , : , -
: , -
: , -
: , -
: , : }, -
: , : }, -
: , -
: , -
: }, : }, -
: , -
or `` is ``. }, : -
-, in None], :
Reproduce This Scan
Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.
&&