jj icon indicating copy to clipboard operation
jj copied to clipboard

configs: Improve security of in-repo configuration.

Open matts1 opened this issue 2 months ago • 1 comments

Fixes #3303 and #1595

This completely changes the workflow for in-repo configuration. Instead of being stored in a file on disk, we store the configuration wrapped with a signature in order to determine who wrote the configuration.

In the event that the config is considered insecure, we warn the user and require them to run jj config edit --repo/workspace to re-enable it (test_config_security.rs simulates these workflows and is relatively well documented).

If applicable:

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

matts1 avatar Oct 18 '25 03:10 matts1

Notes for reviewers to make your life easier. I recommend reviewing in the following order:

  1. Start with test_config_security.rs to see the UX
  2. Then go to user_config.proto then user_config.rs to see the API
  3. Then look at cli/config.rs to view the implementation

Everything else is just mostly boilerplate changes with little substance.

matts1 avatar Oct 18 '25 04:10 matts1

@yuja There's clearly been a lot of contention with the UX issues, so I've been rethinking from the ground up, and realized that if I added a concept of a "repo ID" and "workspace ID", we could store configs out-of-repo and solve almost all the issues we were having, and not require any kind of user intervention, or disabling of configs. I've managed to mitigate most of the concerns I originally had with out-of-repo configs, and there's only some very minor UX wierdness.

I wrote the design doc after writing the initial PR, but this time I've updated the design doc and haven't yet written any code. I think you'll appreciate the new design, I put a lot of effort into explaining the solution in an easy-to-understand manner, and I think you'll find it much easier if we do it in a two step process where we first review the design doc and then the PR, so I'd like to invite you to take a look at the new design and review it, and then after it's approved I'll start work on the PR. If you'd still prefer, I can find a different reviewer, but I think you'll find that the contention has disappeared, as I think this new approach gives you what you want out of this.

matts1 avatar Nov 06 '25 01:11 matts1