[Bug] Re3gression in setup handling of SHA512 checksum failures

[Ken Brown]

On 3/20/2018 2:23 PM, Achim Gratz wrote:
> 
> I've found out the hard way that a dodgy package file no longer gets
> ignored by setup and is installed without any error unless you care to
> look in setup.log.full.  That was hard to figure out because in my case
> some stupid error on mirroring just made each file miss a few bytes off
> the end, so it was always the last file in the archive that went missing
> on unpacking.  I think that's evil and needs to be fixed promptly, but I
> have no time to do it myself right now.  I honestly don't remember if
> the old setup did the uninstall part before not installing the no-good
> package (it probably ddin't), but I suggest it shouldn't uninstall
> anything that we don't have a good replacement for.  Also, the messages
> that go to the console about SHA512 failures need to be reinstated (a
> good check can keep quiet).
> 
> WIth libsolve it seems that we will have to calculate a new solution
> once we have to drop a package from the solution due to SHA512 mismatch,
> then check any new packages in that revised solution again.  So it seems
> we need to keep state around whether the package archive was already
> checked (lest we check everything again each time).

It looks like there are two things going on here.  First, there must 
have been a glitch when the topic/libsolv branch was merged into master. 
  An inadvertent result of that glitch is that the response to the query 
'yesno (owner, IDS_SKIP_PACKAGE, e->what())' in do_install_thread() now 
gets discarded.  Second, as you said, we do have to avoid processing an 
'erase' transaction that's paired with an 'install' transaction that 
gets dropped.

I'll look into both of these issues, unless Jon beats me to it.

By the way, this only affects local installs.  For network installs, the 
hash gets checked at an earlier stage.

Ken