jp: Improve security of rsync proxy

[anomiex]

Proposed changes

Make it harder for something on the host system to activate the proxy.

• Set umask 0077 when creating the socket.
• Pass a secret value to the container, which must be passed back.

Note this isn't bulletproof security: if an attacker can read the environment from Docker and access files as the host system user, this would be fairly easy to get around. But if they can do all that, they can probably do worse things already.

Other information

• Generate changelog entries for this PR (using AI).

Related product discussion/links

Fixes MONOREP-397

Does this pull request change what data or activity we track or use?

No

Testing instructions

• Try it out, ideally without using a saved destination. A jp rsync should work, and while it's waiting at the "No saved entries for XXX. Create one for easier use later?" prompt you can examine the filesystem to see that the socket file (probably /tmp/jp-rsync-XXX) is mode 0700, and the process list to verify that the secret value isn't included in the command line to docker run.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

[kraftbj]

Review comments from automated analysis — 1 critical, 2 important.

[kraftbj]

Bug: Umask not restored on error path

If proxyServer.listen() fails (triggering the 'error' event), rejectListening(err) is called but the umask is never restored — process.umask(oldUmask) only runs in the success callback. The process would continue with umask 0o077, silently breaking permissions for any subsequent file operations.

Since .listen() creates the socket file synchronously before returning, you can restore the umask immediately after the call rather than in the async callback:

Suggested change

	proxyServer.listen( { path: socketPath }, () => {
	const oldumask = process.umask( 0o077 );
	proxyServer.listen( { path: socketPath }, () => {
	resolveListening();
	} );
	process.umask( oldumask );

This eliminates the restoration problem entirely — no need to handle it in both success and error paths.

[anomiex]

Not sure whether the AI introduced a race condition there, though: will proxySever.listen return before creating the socket?