Do not persist MODULE.bazel.lock

[mmorel-35]

MODULE.bazel.lock is platform dependent so it’s better not to persist it

Signed-off-by: Matthieu MOREL matthieu.morel35@gmail.com

[mmorel-35]

Anything blocking this ?

[mmorel-35]

Another thing, to publish to BCR, there is a bit of configuration, see https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md and also an App, see https://github.com/apps/publish-to-bcr

[ejona86]

@veblush, could you review?

@mmorel-35, we have never done releases of this repo, so there will be things to figure out

[mmorel-35]

It seems like it is better to persist it, see https://bazel.build/external/lockfile#best-practices

[ejona86]

Use bazelisk to run Bazel, and include a .bazelversion file in version control that specifies the Bazel version corresponding to the lockfile.

Yeah, we're not doing that. So I think we need to delete the lock file.

[ejona86]

Since this project needs to run with multiple different Bazel versions, it'd also be important to know whether the lock file detects it was used by a different Bazel version.

I also wonder if the lock file could be used for a supply-chain attack; if Bazel trusts the lock file and ignores the files we review, someone could generate a real lock file but then modify it in subtle ways. The file is too large for such a thing to be noticed on human review. That would definitely have been possible for maven_install; I don't know for bzlmod though.

[ejona86]

That would definitely have been possible for maven_install; I don't know for bzlmod though.

This could be detected by a CI, since it seems the output is expected to be stable (generating it twice generates the same bytes).

[ejona86]

@veblush, can you take a look?

[veblush]

LGTM. I'd like to note that bazel.lock file is contained within this repo and shouldn't affect the downstream.