Enforcement of locks

[errge]

When intentionally changing the lock file by hand for enforcement of locks, I noticed this:

Cloning with-editor...

Warning (straight): Could not reset to commit "ca902ae02972bdd6919a902be2593d8cb6bd991c" in repository "with-editor"
Cloning with-editor...done

(Correct git hash would be with 991b at the end instead of c.)

I understand that in the name of user-friendliness if the lock file is screwed up, straight.el prefers to go ahead and just continue, but for me this is kind of an issue, as I consider this even security related (e.g. a package author can push malware at unchecked new master commits and make the locked commit go away with a rebase or something, so the next time I pull, I get the incorrect malwarish commit automatically). I know this is a convoluted attack, and I shouldn't be paranoid, but it still seems to me that this user friendliness is against the spirit of lock files.

Do I misunderstand something? If not, would it be possible to provide a flag, that I could just flip, e.g. something like straight-enforce-lock-files, I'm OK if it defaults to nil to be backward compatible.

[errge]

Additional important idea: as an additional, even stricter option, straight.el should provide a way to signal error if the lock file doesn't contain something that is being installed right now.

The use-case is to protect against my .emacs framework getting out-of-sync with the lockfile, because I simply forgot to freeze the last time I added a new package.

[raxod502]

Yes, your understanding of the current state is correct. There is no current option for making lockfiles behave in the way that you would expect, but I agree that such an option should be provided and, arguably, it should be the default at least to notify the user interactively and allow them to choose how to proceed.