Fix path-traversal vulnerability in emergency P2P checkpoint service

[YuvalElbar6]

A malicious or compromised peer on the P2P network could supply a manifest whose rel_path contained '..' segments or an absolute path, causing P2PNode.fetch_shard_from_peer() to write attacker-controlled bytes outside the staging directory (e.g. a .pth file in site-packages, yielding persistent RCE on the training host).

• Add _safe_path_join() which joins a peer-supplied relative path onto a base directory only if the resolved result stays inside that base. Resolution goes through os.path.realpath so symlink-escape attempts are caught as well.
• Apply the helper on both sides of the wire:
  • Client: fetch_shard_from_peer() validates every manifest entry against stage_dir and aborts the whole fetch on any unsafe entry.
  • Server: handle_download() replaces the substring '..' check with the same resolve-based containment check against self.directory.
• Log every rejection with peer and request context.
• Add regression tests for the helper and both call sites.

Reported via the Google OSS VRP.

[linxiulei]

Hi, thanks for your contribution!

Since Orbax runs on top of JAX, and JAX's coordination service doesn't enforce strong authentication, the Orbax runtime generally assumes it's operating in a secure network environment. In practice, if there were a "compromised peer," we would already be facing much larger systemic risks.

That said, we always welcome security enhancements. Could you please clean up the empty commits in the PR so we can get it merged?

[YuvalElbar6]

Thanks for the context on the threat model — agreed it's a defense-in-depth hardening rather than a critical fix. I've cleaned up the merge commits; the PR is now a single commit on top of main.
@linxiulei

[YuvalElbar6]

Hi @orbax-dev, @linxiulei this PR is now one commit can we merge it?