@richardlarocque, thanks for your PR! By analyzing the history of the files in this pull request, we identified @Cornu and @fpletz to be potential reviewers.

I admit to having done no manual testing and not having much clue why conflict resolution was necessary. (My local branch seems to be up to date...)

This is more of a proof-of-concept for #27130. I have manually verified that

extraConf = "password_file /var/lib/mosquitto/passwd";

fixes the problem reported there. So the change should be good at the Mosquitto level.

I'm less familiar with testing NixOS services, so I'm going to hope the Travis CI bot does a good enough job of that.

Nixos services are not covered by travis ci at all. Please use git-rebase instead of git-merge in future to resolve merge conflicts, as the result is easier to review. Is there a use case, where people want to avoid having the password or password hash stored in nix store? If yes, how can it be achieved with your solution? Now as the password is mandatory and no longer opt-out this would also require a changelog note as it is a breaking change. An alternative would be to only set password_file if a password is configured.

I've clobbered this PR with a new version. The merge commit is gone now.

Your point about backwards compatibility is a good one. I've updated the PR to make this change opt-in. Users must set the checkPasswords flag to get the new behavior.

I believe this change has no direct effect on the use of hashedPassword configs. I believe that the flow recommended in the docs (using mkpasswd to generate the hash) doesn't work. Generating hashes with mosquitto_passwd gives me different hash values, and those values seem to work just fine.

If I'm right, then the effect of this change will be that many users who thought they had hashed their passwords correctly will find out that their hashes and passwords do not match. Previously, it would have appeared to work because the server accepted any password as valid, regardless of what hash was specified.

But all of that only comes into play if they toggle on the flag. It defaults to providing the old behavior, so any hashed password value is acceptable.

By the way, I couldn't figure out which tests were relevant, but I did write and run some tests of my own.

I used a script to rebuild and restart the mosquitto daemon under various configs:

#!/usr/bin/env bash

X=$(nix-build -A  'config.systemd.units."mosquitto.service".unit')/mosquitto.service
sudo cp $X /run/systemd/system/tmp-mosquitto.service
sudo systemctl daemon-reload
sudo systemctl restart tmp-mosquitto.service

And another script to verify its behavior:

#!/usr/bin/env ruby

[
  ["No auth",                        "mosquitto_pub -t 'test' -m 'Foo'"],
  ["Unregisterd user, no password",  "mosquitto_pub -u guest -t 'test' -m 'Foo'"],
  ["Registered user, no password",   "mosquitto_pub -u john -t 'test' -m 'Foo'"],
  ["Registered user, bad password",  "mosquitto_pub -u john -P 'badpass' -t 'test' -m 'Foo'"],
  ["Registered user, good password", "mosquitto_pub -u john -P '12345' -t 'test' -m 'Foo'"]
].each do |name, cmd|
	result = system(cmd + " 2>/dev/null") ? 'PASS' : 'FAIL'
	puts "#{name}: #{result}"
end

I hope this is sufficient. My changes only touch configs, so I can't imagine how I could have broken package-building.

See also the notes on the related issue. #27130

Related issue for the password hashing instructions: #27996.