ca67cf6313
Both audits flagged buildPage as a non-blocking but worth-cleaning nit: it re-derived next_cursor from len(events) and the last event's ID rather than using the HasMore + NextCursor flags that event.Repository.ListByToken already computes via the LIMIT+1 peek trick. Both calculations agreed today, but the duplication would mask a divergence if the repo's pagination logic ever evolved (e.g. switched to opaque token cursors). Inline buildPage into gatherManageData and use list.HasMore + list.NextCursor as the authoritative signals. Drops the buildPage helper. Behavior identical; tests still pass. |
||
|---|---|---|
| .. | ||
| base64-tool | ||
| c2-beacon | ||
| caesar-cipher | ||
| canary-token-generator | ||
| dns-lookup | ||
| firewall-rule-engine | ||
| hash-cracker | ||
| keylogger | ||
| linux-cis-hardening-auditor | ||
| linux-ebpf-security-tracer | ||
| metadata-scrubber-tool | ||
| network-traffic-analyzer | ||
| simple-port-scanner | ||
| simple-vulnerability-scanner | ||
| systemd-persistence-scanner | ||