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.
@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 last after this update, the "End rpmdb" hash indeed looks strange (note the double ** at the end):
# dnf history info last Transaction ID : 13 Begin time : Mon 11 Jul 2022 11:44:45 AM EDT Begin rpmdb : d45b12fd3dedbf082548dcdccba6f0d3344ab5df End time : Mon 11 Jul 2022 11:44:47 AM EDT (2 seconds) End rpmdb : fa29c830d06b5fe14cbb5ddd2e064f9772713122 ** [...]
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.