Allow both repo-level configs and user+repo level configs

[matts1]

Fixes #3684

This adds the following workflow to jj to support repo-level workflows:

1. Repo updates config.toml in the VCS
2. User retrieves changes
3. User runs jj command, gets a warning saying "please run jj config update-repo"
4. jj config update-repo adds a TUI requesting the user to approve the diff
5. The approved changes are copied to a permanent config file.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes

[PhilipMetzger]

Please format the commits to adhere to our commit guidelines here: https://github.com/jj-vcs/jj/blob/main/docs/contributing.md#commit-guidelines and add a motivation to each commit. This is also missing tests and a changelog entry since the second commit even introduces a new command.

[matts1]

I know, that's why it's a draft commit. Just want to make sure the concept is approved before I add finishing touches.

[yuja]

cc @arxanas, @ilyagr

The idea sounds generally good to me. We might also want a similar mechanism for the zip file problem. Since the .jj directory may be untrusted, it might be better to store trusted config contents or hashes in e.g. ~/.local directory.

#1595

I have no idea about TUI. I personally would want to just see the diff and accept/reject.

[matts1]

The idea sounds generally good to me. We might also want a similar mechanism for the zip file problem.

I'm not familiar with "the zip file problem". Could you link to the issue?

Since the .jj directory may be untrusted, it might be better to store trusted config contents or hashes in e.g. ~/.local directory.

I'm not opposed to that. I chose this method because it was the same directory that the repo config was stored. I would request, however, that we submit this first and worry about that later, since this is explicitly not making the security any worse than it already is.

I have no idea about TUI. I personally would want to just see the diff and accept/reject.

I do agree, as a user, that that's what I would want, but that's also relatively easy to achieve with the TUI. I think, however, that from a security perspective, a binary accept / reject choice is not great, because it might feel like you have to make a choice between new features and security. With a binary choice, if there's one particular line that you are concerned about and so you reject it, that means you have to reject every future change to the repo config.

[martinvonz]

I'm not familiar with "the zip file problem". Could you link to the issue?

I don't think we have a link, but it's a familiar problem from other VCSs (familiar to VCS developers). The problem is what to do about repo-level configs in .jj/.git/.hg. For example, an attacker can send you a zip file of a repo where the repo-level config has rm -rf / as diff tool. They might ask you to help them troubleshoot some problem with their repo, for example, and you might not expect that simply running jj/git/hg diff in the repo would be harmful.

[matts1]

Makes sense. So I assume the solution would be to store it out of the repo, and require users to run jj config edit --repo instead of something like what I currently do where I type vim .jj/repo/config.toml?

[martinvonz]

I think Yuya's proposal was to record trusted config contents somewhere in ~/.local. When you unpack a zip file and run a command in that repo, you'd get a warning saying that it has untrusted configs. Then you run some command to say which of the configs you approve.

I'm not sure if it's safe to trust configs at the key-value level or only at coarser granularity. Could there be some case where you say that you trust key1="value1" and key2="value2" but somehow the combination is still harmful? I hope not, and it feels like it should be safe.

[matts1]

I'm not sure if it's safe to trust configs at the key-value level or only at coarser granularity. Could there be some case where you say that you trust key1="value1" and key2="value2" but somehow the combination is still harmful? I hope not, and it feels like it should be safe.

AFAICT, the attack surfaces are, in order of danger:

• Mess with the repo
• Send private code
• Remote code execution

This is my analysis of the danger:

• Revsets: Minor nuisances
  • Can mess with the repo
  • Can send code, but generally only to existing remotes
  • Can't escape the repo
• New remotes:
  • Should be obvious to spot, so easy to mitigate
  • RCE possible via pulling code
  • Possible to send private code by accident
• Arbitrary command execution. Only two sources of this are (to the best of my knowledge):
  • jj fix tools
  • Command aliases to jj util exec

I think that it's possible to make one harmful thing and one alias to it, but I don't think it's possible to make two things that are independently safe but together harmful (it's technically possible with two arbitrary commands that execute files in the repo, but if they're doing that then they can already achieve this).

[PhilipMetzger]

Here's a bunch of actual review comments.

[PhilipMetzger]

In my opinion this shouldn't belong in the VCS.

[matts1]

I quite strongly disagree with this. If you leave it up to the user to review the config and copy it, it's far less secure due to psychology:

• The user can run ln -s to create a symlink instead of copying the config, thus never even reviewing changes
• The user is far more likely to review the diff if you actually force a diff open for them than if you tell them "please review and copy if you trust it" - most users will not be bothered to open a diff

What makes you say this shouldn't be in the VCS?