Rebase to rpm 4.17.1 (http://rpm.org/wiki/Releases/4.17.1)
Note: During the first DNF transaction following the one in which this update is applied, a spurious warning will be shown if you run DNF in --verbose mode: RPMDB altered outside of DNF. You may ignore this warning as it's caused by a change in the algorithm used to generate the RPMDB hash.
Updates may require up to 24 hours to propagate to mirrors. If the following command doesn't work, please retry later:
sudo dnf upgrade --refresh --advisory=FEDORA-2022-763dfc66f1Please login to add feedback.
This update has been submitted for testing by mdomonko.
This update's test gating status has been changed to 'waiting'.
mdomonko edited this update.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'passed'.
This update has been pushed to testing.
Works.
This update can be pushed to stable now if the maintainer wishes
works
works
LGTM.
During the next update after installing this one I noticed in dnf output
RPMDB altered outside of DNF, that's expected and not an indication of some tampering with my system, right?no issues
Trying to reproduce the same problem as in FEDORA-2022-37913de00f:
Turns out, it's config dependent:
This update has been unpushed.
Similarly to FEDORA-2022-37913de00f, a fix is on the way.
mdomonko edited this update.
New build(s):
Removed build(s):
Karma has been reset.
This update has been submitted for testing by mdomonko.
@ozeszty, this is indeed strange, thanks for the report. I suspect the warning has to do with us bumping the RPMDB cookie (a hash) to from SHA1 to SHA256 in this release: https://github.com/rpm-software-management/rpm/commit/1db8004b3bcbf073257b4a059915001d512e0686
That said, I can't reproduce this myself. However, looking at
dnf history info lastafter this update, the "End rpmdb" hash indeed looks strange (note the double ** at the end):I'll need to investigate further, it might be that DNF or RPM is accessing uninitialized memory when reading/writing the cookie before/after the transaction due to the expected length being changed. Until then, I'm revoking this update so that we stay on the safe side.
@mdomonko there are no asterisks after end hash from that update on my computer.
Yeah, the asterisks get removed from that hash after the next transaction, for some reason.
OK, it turns out the ** is an undocumented marker that comes from DNF and indicates that the RPMDB was altered outside of DNF, just like the verbose output says during the subsequent transaction.
The reason DNF considers it "altered" is simply that the hash function used by RPM has changed (not the underlying data). This could easily be "fixed" in DNF by making sure the two hashes being compared are of the same length, but since the message only shows in --verbose mode and the double asterisk marker in the "dnf history info" output is only transient, it's probably not worth obsessing over.
The hash returned from the RPM API is a C string and it's handled like that in both libdnf and DNF (I've checked the code) so no assumptions are made about its length that would have to be adapted in DNF. I'm moving this update back to testing now.
This update has been submitted for testing by mdomonko.
This update has been pushed to testing.
mdomonko edited this update.
mdomonko edited this update.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'passed'.
Working fine.
This update can be pushed to stable now if the maintainer wishes
This update has been submitted for stable by mdomonko.
@mdomonko I hope I haven't wasted your time.
@ozeszty, oh, quite the opposite! Thanks again for noticing this, people might be confused by it so we'd better have a note somewhere. I've added one in the update description (in case somebody actually reads it) and also in the release notes on rpm.org.
This update has been pushed to stable.