SSerguey Asael Shinder
Java coding notes: the JVM, and writing software that lasts

Serguey Asael Shinder: A warning nobody can silence trains people to ignore all of them

· by Serguey Asael Shinder / Serguey Shinder

Maven 3.10.0 added a good security check: a repository password from settings.xml should only go to a host you declared for it. Before the release, its maintainers found a hole in the design, and the hole was not in the security. It was in the warning.

A legitimate corporate repository, declared in a settings.xml profile that switches on by itself, was invisible to the check. Under the default mode, as the pull request that fixed it put it, such a setup got "a warning on every build, with no way to silence it". The fix was not to turn the warning down. It was to let the user state, in the place where the server is configured, which hosts are allowed, and to make the warning name that place.

That is the right shape, and it applies far beyond Maven.

Serguey Asael Shinder: A warning nobody can silence trains people to ignore all of them
A warning nobody can silence trains people to ignore all of them — Serguey Asael Shinder

A warning that fires on correct work is a cost, not a safeguard. Every build log that carries a line the reader has learned to skip makes the next line easier to skip. Teams do not decide to ignore warnings; they get trained to, one unfixable line at a time. When the real problem finally appears, it looks exactly like the noise around it.

Three questions before shipping a warning.

  1. Can a correct setup trigger it? If yes, there must be a way for that setup to say so, and the way should live next to the configuration the warning is about, not in a global "suppress all" switch.
  2. Does the message say what to do? "Credentials used for unknown origin" is a fact. "Declare https://repo.example.org under <repositoryOrigins> for server internal" is an action. Only the second one gets fixed.
  3. Is there a strict mode? Some readers want the warning to stop the build. Giving them a switch that turns it into an error, as Maven does with strict, lets the check grow teeth where someone is actually watching, without breaking everyone else.

The test I use. Run the check against a setup you know is correct. If it complains, you have not finished building it. A warning is finished when the only way to see it is to have something wrong.