A workaround right now is to use git-based sync over https. You can sync from https://github.com/gentoo-mirror/gentoo which is a copy of the portage tree with pregenerated metadata.
That aside, wouldn't it make sense to have the generated metadata in a separate repository? Sync the latest metadata, then check out the corresponding revision from the actual gentoo git repo.
That's the whole reason the rsync infrastructure exists in the first place.
That is just as insecure as rsync. You need to use https in order to protect data. (Appart from that it seems calculate linux doesn't even have a webpage over https...)
That's where the details are (and probably where this submission should point).
The change is in the master:
This is dangerous as it is insecure default behavior. There may
be an argument (poor) for keeping insecure default
behavior. However, it is also doubly dangerous because it may
imply to the user that the operation has been cryptographically
verified when in fact it has not.
Steps to Reproduce:
2. "Fetching file portage-20161021.tar.xz.gpgsig ..."
User things "cool, it's verified"... but it's not verified, and
no warning is shown to this effect.
All downloads are cryptographically verified or, failing that,
a big (preferably red, flashing) SCARY WARNING is shown.
Probably it should whinge immediately and require the addition
of an --insecure command line flag.
I'm not saying you have to educate from first principles, but sure would be nice to include the use case, expected behavior, estimate on how widespread the effect, steps to reproduce,... This is basically a tweet.