config: Implement secure-config design doc.

[matts1]

See docs/design/secure-config.md for many more details.

Fixes #3303 Fixes #1595

Checklist

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]

I've added Yuja as a reviewer since he's the one I strictly need approval from, but FYI @martinvonz and @PhilipMetzger in case you'd like to review as well.

[higgsd]

Some thoughts on the design doc:

• Missing noun: The attacker can now see [???] stored in the repository
• Content - explain more explicitly how the victim's signatures are misused (or if that's just A Bad Thing)
• Does anything problematic happen if the user's .config directory is itself a jj repo?
  • Is there a need to prevent a repo from storing its configs inside itself?
• Perhaps give users a preferred way to copy/restore a config, so they don't have to hand-correlate repos with config-ids
  • Maybe provide jj config replace [scope] [PATH | --stdin] to help?
• Perhaps provide a way to list known config-ids and the disposition of their repos/workspaces
  • Its an intermediate step (or alternative) to jj config gc, for review and manual cleanup

[matts1]

• Missing noun: The attacker can now see [???] stored in the repository
• Content - explain more explicitly how the victim's signatures are misused (or if that's just A Bad Thing)

This was a remnant of the old proposal. I've renamed it to "config / config signatures"

• Does anything problematic happen if the user's .config directory is itself a jj repo?

Not really

• Is there a need to prevent a repo from storing its configs inside itself?

Yes, this is explained in the design doc in attack vector 1. Other attack vectors just build on top of this.

• Perhaps give users a preferred way to copy/restore a config, so they don't have to hand-correlate repos with config-ids
  • Maybe provide jj config replace [scope] [PATH | --stdin] to help?

This feature is supposed to be transparent to the user. The user does not have to hand-correlate repos with config IDs. It should happen for them automatically. If you did want to manually do it, it's as simple as writing the config id to .jj/repo-config-id, or just running jj config edit and copying the config from there.

• Perhaps provide a way to list known config-ids and the disposition of their repos/workspaces
  • Its an intermediate step (or alternative) to jj config gc, for review and manual cleanup

If someone wanted to implemented it, I wouldn't stop them, but I already mentioned in the design doc that GC was out of scope of the initial version, but that we might consider later.

[higgsd]

• Does anything problematic happen if the user's .config directory is itself a jj repo?

Not really

• Is there a need to prevent a repo from storing its configs inside itself?

Yes, this is explained in the design doc in attack vector 1. Other attack vectors just build on top of this.

Sorry, I meant those as associated bullets. If the user makes their .config directory a jj repo, all their secure configs will be then stored in that repo.

If a jj repo finds that it contains it's own secure config path, should it complain loudly or behave any differently?

[matts1]

If a jj repo finds that it contains it's own secure config path, should it complain loudly or behave any differently?

There's good reason to do such a thing - uploading your jj config to a private repo would make a lot of sense. I think we answer no for now, and can consider circling back to it later if we really want.