add some docs regarding security

[bbrehm]

This adds some clarifications regarding security goals. Big thanks to https://github.com/xavierpinho ❤️ for mentioning that here https://github.com/joernio/flatgraph/security/advisories/GHSA-jqmx-3x2p-69vh

Any improvement / rewording ideas?

[xavierpinho]

Thanks for the prompt discussion and clarifications!

Just a typo (double negation) I spotted:

nor should (not/it) cause

[mpollmeier]

Suggested change

	The main potentially security issue is the following situation: You get handed an untrusted, potentially malicious, flatgraph file, and want to handle it.
	The main potentially security issue is probably: how can you handle an untrusted - and potentially malicious - flatgraph file?

[mpollmeier]

Suggested change

	Deserializing a `.fg` file should not pop a shell / cause privilege escalation, nor should not cause excessive filesystem activity. However, it may take an
	Deserializing a `.fg` file should not be able to open a shell or cause privilege escalation, nor should it cause excessive filesystem activity. However, it may take an

[mpollmeier]

Suggested change

	unbounded amount of time and memory, potentially leading to an OOM crash of the JVM that might not be recoverable from within the JVM by catching some exceptions.
	unbounded amount of time and memory, potentially leading to an OutOfMemoryError in which is typically not recoverable and will bring down the entire JVM.

[mpollmeier]

Suggested change

	If you need to handle untrusted `.fg` files, then we recommend some form of sandboxing in order to limit the DoS impact.
	If you need to handle untrusted `.fg` files you should really sandbox your process, in order to limit the DoS impact.

[mpollmeier]

Suggested change

	If you do decide against our recommendation to write your own code to "sanity check" potentially malicious `.fg` files before attempting to deserialize them, then we'd be happy for your feedback and PRs. (also beware of potential parser differentials -- e.g. the manifest json can be reached either via the offset from the file header, or via `tail -n 1`, and these may very well be different manifests)
	You should always sanity check potentially malicious `.fg` files before attempting to deserialize them. If there's anything we can add in flatgraph's Deserializer, we'd be happy for your feedback and PRs.
	N.b. also beware of potential parser differentials -- e.g. the manifest json can be reached either via the offset from the file header, or via `tail -n 1`, and these may very well be different manifests.