We now have a plausible scenario for the cause.  Much thanks to ogra, pmcgowan, mandel, and laney for a fantastic team effort.  One caveat: we won't declare success until we have a fix, but the cause we're working on makes the most sense, and we have a plan for fixing it.

* A recent (as in ~the time of popey's original bug report) change in the ui caused an CheckForUpdate to start when System Settings was opened, even before Update icon is clicked.  Now remember that when auto-download is set (the default), not only do we start the check, but we then start the download if an update is available.

* Now click Update icon, a second update is attempted.  We think we have a race condition here where two updates are started at the same time, either by a flaw in the in-process s-i-dbus flag (I can imagine a small window for racing against this flag), or two s-i-dbus processes being started.

* We've verified that the SignatureError seen in all the logs is because the keyring.tar.xz and keyring.tar.xz.asc files are *empty* after u-d-m reports a successful download.  Imagine two download happening at the same time, either because of the above races, or a dbus-inherent race (i.e. messages getting queued up and delivered at an unfortunate time).  s-i-dbus requests u-d-m to download the files to a specific location on the file system, so if a second request comes in with the same destination, it will overwrite the first requests.  We think this is why we're seeing the zero-sized files.

* When we see what is essentially corrupt blacklist files, we assume that it must be the image-master key that's out of date, so we try to download that.  Same thing happens here (which is suspicious, but let's say it's possible).  We see zero sized image-master tar.xz and .asc files.  Those of course fail signature checks, so s-i then left with assuming that the pre-loaded archive master key is possibly corrupt.  We cannot download that key for security purposes, so we're left at the end of the chain and s-i gives up.  The exception that's reported to the ui is a little misleading, or at worst unhelpful, but it's essentially saying "we tried to download a proper chain of trust, and failed at the end of the chain, so we have to give up".  There's nothing more s-i can do.

We have two action items to prevent this:

1) s-i-dbus will add guards to ensure that only a single s-i-dbus process is ever running, by ensuring that the process owns its D-Bus name.  If it can't own the name, another process is running and we'll exit.  Hopefully this is a race-resilient check.  For even better guarantee, I could use flufl.lock which is a long battle tested library for file system locks, with timeouts against stale locks.  I will also double check the in-process flag guard and add lots of tests!  

2) mandel will fix u-d-m to download files to a .tmp file, then atomically rename into place once the files are successfully downloaded.  That way, even in the face of a race condition, it will be impossible to "see" a partially downloaded file.

For those of you who are experiencing this, the work around is to wait 10m for s-i-dbus to exit and try again.  Note that you can also adb shell in and run system-image-cli.  That more or less explains why cli users aren't seeing the bug - they only exec one instance of the cli tool and never hit this race condition.