//tools:par_test red on bazel ci again

[hlopko]

Hello :)

I see the par_test is red again: https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/425#47df845e-6759-4c77-8867-7e81e02ddac0

We had problems with it in #67 and in #80. Can you help me understand why the test is failing with bazel@HEAD? What can we do to prevent it in the future? Should we run the test on our CI with bazel@HEAD?

Thanks!

[meteorcloudy]

This is still red https://buildkite.com/bazel/rules-python-python/builds/134
@brandjon

[brandjon]

To recap my understanding of Douglas's comment: This test is intended to provide a security guarantee that the checked-in pre-built .par files have not been tampered with. The problem is that the check for exact equality is too brittle, and a looser check would compromise confidence in the test.

The pre-built .par files are needed for bootstrapping, since piptool and whltool are themselves defined in terms of pip_import. I would argue that since they're used for bootstrapping, this defeats the point of the test anyway, since a malicious piptool.par would taint its own rebuild.

I agree with Douglas's comment that we should just delete the test. That avoids giving people the false impression that we have an automated way to verify the integrity of the .par files. We definitely should not accept PRs modifying the .par files from untrusted sources.

Long term, to avoid a checked-in binary, we could break the circular dependency of piptool/whltool on themselves by using a non-pip_import way of obtaining the dependencies in rules_python/python/requirements.txt.