Joint Reports - How do we format?

[koronkowy]

This is bound to come up again but there's already some instances of this with the Kudelski Security - X41 reports.

Some suggestions on how to tackle this would be: A defined naming convention for this (which company first? Alphabetical or as it appears on the report?), or possibly a folder that is titled Joint Reports that then has folders inside.

[bleetsheep]

There are a few ways we can keep the "one directory per company" structure, since to me that seems the most organised, easiest to find reports, and not favoring one company by making it alphabetical or something.

Option 1: git does deduplication, so for GitHub's storage and the download size it shouldn't be an issue to have the same report in both companies' directories. Until the repository grows much larger, I also doubt anyone cloning the whole thing will have any issue checking out the files. This does feel a little bit dirty, though, but it just works™.

Option 2: git supports symlinks, so we could simply put the report in one of the directories and symlinking from the other, e.g.:

./ACorp
./ACorp/Example.pdf
./BCorp
./BCorp/Example.pdf -> ../ACorp/Example.pdf

The problem, as always, is Windows support. I'm personally fine to have Windows users that clone the repository have text files with links instead of real symlinks, since I doubt that many pentesters use Windows as their main system and I also don't expect many people clone the whole thing with the goal of browsing it in the first place (the web interface seems more convenient for that, especially if you're a GUI person). If we really do want to work around this, we can either make an index in the README and link to report files from there so we don't have to deal with Windows filesystem limitations, or add some post-checkout script like this.

A related option (2b?) might be to put the PDF in a joint directory where it really belongs, and symlink from both ./ACorp/Example.pdf and ./BCorp/Example.pdf to ../ACorp-and-BCorp/Example.pdf, since that also sort of mitigates the Windows problem (Windows users can use the joint directories), but then we have the name ordering issue again and it's slightly more complicated than only one symlink and clutters the directory listing with joint names.

If we do want to solve the ordering issue and do joint directories, I would generally say we should order it with some simple but verifiable random. My school did a verifiable random seat ordering and I appreciated the nerdiness quite a bit, even considering it was useless for teaching (research at the time said teacher-assigned is the best seating, not random or student-chosen). One example would be: shuf names --random-source <(sha256sum names). If we use the report order, the next report might use a different order due to different work distribution. Alphabetical always favors the same company and does not seem right.

Making a single directory for all joint reports (let's call that option 3) would spread the reports from one company into multiple directories and also doesn't solve name ordering (if we use the reports' original order, report 1 may use ACorp-BCorp and report 2 may use BCorp-ACorp, so they're not grouped when sorted). An advantage is that this option would be very easy to implement (like option 1). Maybe an index in the readme would help for discoverability with spread-out files. Or maybe we can symlink from ACorp's and Bcorp's directories to joint-reports/Example.pdf (where Example.pdf uses the report's original ordering), then there would be no need to open the joint directory for browsing and thus ordering should not matter.

I'm putting way too much thought into this.

Anyway, I think option 2 would be easiest and cleanest, with option 3 as second choice -- either way, I'd symlink from the companies' directory/ies to the report location (be that in a single joint directory without sorted names (3), or in each companies' own directory (2)).