Repository navigation
Conversation
|
This is a great idea! A couple of questions for you: Has this skill been used on any audits yet? If not, do you think it would be better to keep the skill local until it has been through one or two (or more) trial audits? Maybe we could try checking out an older commit where we already know the fix, and run the skill to see how it performs (with that fix taken out of the skill's notes, so it can't just look it up)? |
jinhgkim
left a comment
jinhgkim
left a comment
There was a problem hiding this comment.
Just a couple of things that stood out while skimming
| ## Build and verify | ||
|
|
||
| - Reconfigure from inside `build/` (`cd repo && cmake .` triggers an | ||
| in-source build error). After a main checkout on dev-3.1, reconfigure with |
There was a problem hiding this comment.
Isn't dev-3.1 already stale? Maybe we could say "release branch" or "main branch"?
There was a problem hiding this comment.
Yeah, good point. All of the auditing and the PRs it led to was before the 3.2 release. But I don't think this is specific to even the release branch. I think I just want this sentence to read something like "when switching branches, do..."
| Actions (`.github/workflows/fuzz.yml`, nightly or on demand). Locally: | ||
| testsuite green plus valid-file byte-identity. Do not stand up a local | ||
| libFuzzer build on macOS unless upstream LLVM is installed. | ||
| - Never bench or exercise C++20 atomic wait/notify on this Mac (kernel panic). |
There was a problem hiding this comment.
on this Mac? Ah, I think the "Build and verify" section is tailored to your machine. Can we make it generic? (unless that was intentional)
There was a problem hiding this comment.
The atomic wait/notify clause can go... that was specific to a particular task I was doing recently and seems to have bled into this skill. It's actually not relevant to the reader auditing.
I'll look over the rest and see what else seems specific to my setup.
For sure, I intend to test this for a while. I wanted to throw it up so people could see what I'm doing. And in any case, it's not designed to be static, it'll hopefully keep getting revised as we find new bug classes that get reported and fixed. |
Over the summer, I did an extensive security audit across the file readers, guided by spec-kit, and the results were turned into a few dozen PRs that landed over the course of the summer. Using Claude, I have distilled the original spec documents and other working files, and what we found in the PRs, into an agent skill "oiio-input-security-audit" that captures the procedure, checklist, bug-class catalog, and per-format notes from the format-by-format reader security audit, so similar audits can be performed in the future (for formats inividually, or all). The skill has instructions to append to its own files as new classes of input security issues are found and fixed. I also kept the original audit spec.md as the requirements record, and the deferral log of hardening findings spotted but not fixed. This has all been greatly reduced from the in-progress versions and auxiliary files spec-kit produces, but I thougth that this remaining part is good to keep in docs/dev/specs as a historical record of the approach. Assisted-by: Claude Code / Claude Sonnet 5.5 Signed-off-by: Larry Gritz <lg@larrygritz.com>
11bce80 to
8364596
Compare
2 participants
Over the summer, I did an extensive security audit across the file readers, guided by spec-kit, and the results were turned into a few dozen PRs that landed over the course of the summer.
Using Claude, I have distilled the original spec documents and other working files, and what we found in the PRs, into an agent skill "oiio-input-security-audit" that captures the procedure, checklist, bug-class catalog, and per-format notes from the format-by-format reader security audit, so similar audits can be performed in the future (for formats individually, or all). The skill has instructions to append to its own files as new classes of input security issues are found and fixed.
I also kept the original audit spec.md as the requirements record, and the deferral log of hardening findings spotted but not fixed. This has all been greatly reduced from the in-progress versions and auxiliary files spec-kit produces, but I thougt that this remaining part is good to keep in docs/dev/specs as a historical record of the approach.
Assisted-by: Claude Code / Claude Sonnet 5.5