So, the trivial fix is to simply append 203e9b92fe3623aeba277ee44297f7dd to openssh-server.ucf-md5sum, as Marc had suggested above.
I can proceed with that as the fix. --- But this suggests a few direct questions/thoughts: 0. Does the installer use the openssh-server.ucf-md5sum from the new package, or the previously installed one? If the latter, then the md5sum will need added via SRU. 1. Where in the process did the md5sum get out of sync? I'm not spotting conf changes from the CVE patches by our security team, so looks like this got to us via debian? 2. Our merge review processes need to account for conf file changes with ucf packages. Although, in this case openssh presumably got sync'd so Ubuntu-side process changes would not have caught it. 3. There have been other reports of similar misbehavior with wrongly detected conf file changes (Robie's LP #1747464 mentioned above may be one, there's likely others). Is ucf also being used in these cases, and are those problems likewise caused by missing md5sums in their packages? 4. Is this failure mode something that can be caught in autopkgtests? If so, then per-package checks seem warranted to prevent this in the future. 5. Even better than #3 would be a distro-wide CI check for all packages using ucf, to ensure all distro-default installed conf files (from all pockets) have their conf file md5sums registered. In addition, some broader scoped / philosophical / "dumb" questions: 1. Are md5sums the best way to identify config file changes? E.g. if the change is just a timestamp and commented out line (such as in this case) that shouldn't count as a "change". What about like filtering out commented lines, and checksumming that? 2. Why are commented out lines included in distro-provided conf files? Is it just for documentation, in which case those would be better kept elsewhere and just referenced? (Yes, this is more a debian/upstream policy question which we probably don't have say on...) 3. Is upgrade the right time to be prompting users about config file changes, even if they have legitimate local config changes? With cloud instances, unattended-upgrades, etc. it's not so safe to assume a human is babysitting the dist-upgrade, and breakages during dist-upgrades can be pretty catastrophic for users. It's also a frequently seen pattern in our own bug triaging workloads. Are there any other ways to solve this need? (Yes, much of the above is better fodder for blogs, and no need to discuss it in depth here...) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1861472 Title: upgrade from fresh bionic to focal needlessly prompts user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
