The only other thing I'm mulling over outside of the above is the addition of the Indicator and Object vocab. The File Name indicator was something I considered "double-duty" for both file names and full file paths. Chatting with some folks to see if we can come to a consensus about splitting it out like you did.

Makes sense, but like file name it would be nice to get to choose and visually see which one you've selected for your file path and to be able to change it whenever you want instead of it being clumped into the list.

Also, about the File Path indicator type. I've talked to a few people about having three distinct types:

• File Name: just the name of a file
• File Path: full path and file name
• Directory: just the full path to the directory where a file lives

Would this make sense? I've gotten positive feedback so far. It would mean we can take the File Paths for a sample and have a "create indicator" feature which can either create a Directory indicator out of the File Path, or a File Path Indicator by combining a File Path and a File Name. But it also begs the question of renaming "File Path" for Samples into "Directories" to make that a more logical transition?

I've stepped across this
https://www.blackhat.com/docs/us-14/materials/us-14-Castle-GRR-Find-All-The-Badness-Collect-All-The-Things-WP.pdf

Then I started thinking about windows path separators vs the rest of the world.

In order to have something useful there I think that having the full path where the file was found, would be great. Then someone will ask for globbing, and then for regex.

For regular web based interface access patterns passing the absolute paths through os.path.basename(), os.path.dirname(), os.path.splitext() should be fine.

My perception is that the pre-chopped forms might be useful for pivoting and querying, but then we'd end up duplicating some data. Perhaps the lowest overhead solution would be to pre-split, then use os.path.join(). Directory and filename make sense, and the only ambiguity will happen when you'll end up with many directories and many filenames, and you'd want to create some actionable indicators, but let's say the filename is dependent on the directory name, and not having connection between filename and directory could be problematic in a sense that it could increase the number of combinations e.g.:
when lots of filenames are occurring in in directory foo, but only few in bar and baz, the pre-chopped model will generate lots of variants that might not exist.

For now I mostly rely on CRITs to hold the data for the observed artifact feeds (sandboxes, AV), and there's not much variety when it comes to filepaths.

Got some more fixes done, even email attachments should work now. Commit times are from May 2015, as I later noticed that the clock on my test VM was not synced)

Do you want it to look like the edit fields for the email properties?

When submitting a zip file (and I assume a rar file) the filepath in the form isn't properly passed along so it is dropped on the floor.

if you get "2 No such file or directory" then the path for 7z is not right. Brew puts it in /usr/local/bin/7z, whereas your default setting might be /usr/bin/7z.

A head's up about the status of this PR: Still waiting for a response to my above comment about filepaths being dropped on the floor for archive files. Not sure about the best solution:

• filepath for exploded archive file is added for each exploded file?
• filepath plus relative path inside of archive file is used for each file in archive?

I think that I'll just add a runtime switch

I'll need to add the logic for this to work.

This one should be ready for testing, and perhaps some naming changes.
One tiny caveat is that I left the RAR path untouched, as #646 removes that part.
Logic added for "inherit_filepath" and filepath should be passed along just fine now. Also, I've changed the parameter for archive extraction, so now we can get the relative paths. I welcome suggestions for a better caption/name for "inherit filepath", it doesn't feel really intuitive. Perhaps "add paths from archive"