secure repo password change

[out-of-heap-space]

The repo password is currently changeable without having to confirm the action with the existing password. The new password also does not have to be repeated. Kopia is still a great backup software, but unfortunately this fact breaks the ObjectLock feature.
After this fix: The password should neither be readable from memory nor compromised by an older Kopia version. I would be very happy about this big piece of more security. I would like to take this opportunity to praise the project and thank the community.

[Tedpac]

When a repository is opened, the repository password is stored locally so that there is no need to ask for it every time Kopia has to perform a task, therefore, anyone who has access to the computer will be able to see it. That said, what is the need to ask for a password that is already available locally?

It seems to me that a validation that the password is not repeated would only be beneficial to prevent Kopia from making unnecessary changes to the repository (since the password is the same). I don't know if this is already implemented. From a security point of view I don't see any benefit in this validation.

[out-of-heap-space]

I understand your objection.
What you say basically means that everything depends on the hardening of the operating system.
My argument comes from the ObjectLock feature. Kopia supports this. What's the point of this feature if the attacker has made it into the OS. He simply bypasses the last line ObjectLock by changing the Kopia password.
In my case, I run backups via the Task Scheduler with a technical user. That seemed easier to me than making Kopia a service on Windows.
In my case, I don't disconnect after every backup, but leave it open. In my opinion, a separation would not bring any more security. On the one hand, because the connection can be established manually via the task scheduler and on the other hand, because the S3 connection data is also stored in plain text. So full access for the attacker, up to the ObjectLock/Retention limit.
To return to the attack scenario. The attacker changes the password and simply waits for the retention and then strikes.
The only way to handle this scenario at the moment would be to regularly re-establish the connection, but this would have to be done manually.
Hence my argument. The ObjectLock protection doesn't help if I can no longer access my (good and encrypted) backups because of the unknown password.

Or (and now it goes into the Kopia architecture, which I may not know very well) I can do an initial or regular offsite backup of these two files kopia.blogcfg and kopia.repository
protect my backups? So reset the old repo password and access the latest (encrypted) backups?

We can of course discuss the probability of the scenario occurring. But maybe I'm missing something; therefore the discussion also increases understanding.

[brodieG]

I had this concern too, but if you use the --point-in-time feature to access a repo snapshot as of a previous time when your old password was still in effect, the old password is the one that will give access (I just tried it). So it's not possible to lock someone out of past versions of a repository by changing passwords provided that the repository is keeping previous file versions because it seems to also keep the old version of the master encryption key encrypted with the old password.