Request for comment (please don't merge yet)

[javaarchive]

Details I'd appreciate feedback on

• Are some softwares covered out of scope, for example my firefox tangent. Firefox however is installed by default on Ubuntu 22.04. or maybe the eicar antivirus test file thing which isn't actually that practical imo
• commit message format (yea I tried to undo a commit from web editor but failed quite a bit)
• Should mostly windows targeted tools be removed or moved to their own section (might be out of scope as well).
• For NOTES.md would you appreciate a note directing contributing users to write their notes at the end of the file or at a header so they don't conflict with your existing bullet trees?

Up for discussion

• How to reference content from other sections, for example firefox user.js is the same as prefs.js in file-overwrite and can be included in file-append and file-create. For now I just write "see the section in file-overwrite", maybe obsidian has a fancy link to header thing?
• Possibly out of scope: New area for file read because you can do some cool stuff cat /proc/1/environ to read environment of a process by id.
• How would we link relevant sources for information. For now I'm just putting a line break and then a link that says "Source".
• Should I leave out ideas I haven't tested yet into some place gitignorable instead of just putting them with the "(untested)" in the header.
• Better way to write comments to those contributing that isn't prefixing the sentence with "TODO: "
• Similar to sources question, preferably how would I embed a demonstration of a technique. Would the demonstration be kept in a separate file or would I just write it directly in the section. If I prefer to show by video or asciinema, how would you prefer I format such a link.

Questions

• Why not try discussions instead of issues, since the structure seems more fitting?

I apologize if there's anything confusing in the above, I'm writing this quite a bit late at night :) so bear with me

[LiveOverflow]

• I would not consider any software or OS out of scope. However I do think we should focus and prioritize the most useful impacts. For example in a default installation "delete arbitrary file" (probably) does not lead to any privilege escalation. However if we identify software that would make this exploitable, then it's worth documenting. In contrast, "arbitrary file write as root" has so many ways of exploitation on a default installation, that investigating optional software doesn't really help us. How Firefox fits into this, I'm not sure!

• I have never participated or managed an open source project. So I have no idea what should be enforced. At the moment I think the commit volume will be low and we don't really care about "version and change history" like a software does. So I think we could ignore that for now?

• I think Windows is definitely an important OS to research, just not sure how to best do it. Right now we collect everything in a single README.md but we could probably split them up once more content is added, and the README simply points at the other .md files. So we have OS specific WINDOWS.md, Ubuntu2204.md, ... etc.

• I used the NOTES.md to basically document "TODOs" which anybody else could also work on. I kind of like the prefix "TODO:" because somebody could easily grep for open TODOs to work on. Also I don't think the volume is so large that we would need etiquette how to work on the NOTES.md. Maybe we could create new folder "TODO", and in there we collect NOTES.md files and anybody can just create a new file. For example if sb. focuses on windows stuff they can just make a WINDOWS.md.

• You can just reference other content with markdown links. They should also work in obsidian.

• If the same file applies to multiple abilities, I think a simple link is enough as you said. "see also: "

• Good idea about the "reads". Documenting interesting file locations to read from could be useful! But probably a simple "list" is enough which could be easily thrown into a script to test which files exist on a target?

• Linking to sources etc, I also wouldn't overthink it. As you said, just add a line and the source link.

• I like ideas to be somehow part of the repo, because it can be like TODOs for people who would want to contribute. Also then it's part of the git history and if somebody really needs to look deeper in one case they might be able to find old notes about it. But maybe as mentioned above we put that stuff in a TODO folder or something?

• The goal for me is to have a resource useable by a professional pentester who found a file write or file delete, and wants to know how to escalate it. Listing a simple example file with some comments what it does should be enough (like we did on stream). Asciinema or video is maybe a bit overkill, but sure! if we have it, or even a timestamp to the VOD where we researched it, that can also be useful. But I think a simple link in the comment section should be enough?

• I have no clue about these github features, I enabled discussions now. Maybe we could also use discussions instead of the TODO files? what do you think? Any experience with the feature?

Also feel free to move this over into discussions, if you know how to best organize it :D

[lsalvadore]

@javaarchive: My comment is not related to your commits, but I just wanted to suggest you to use the "Convert to draft" pull request feature that you can find in the reviewers section. This way:

• you don't need to add "(please don't merge yet)" to your pull requests titles;
• it is clearer when your pull request is ready: you just need to mark it as ready.

See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests for further information.

Maybe you already knew about this feature, but since I have discovered it only recently, I thought that others might ignore it as well.