So the reason for this is to look for in the git repo itself:
ValueError: 3a5b54a83e99d688e4498b05d137d378531a3dea: Failed to parse signature - malformed e-mail

That being said, we should also catch it on the app side and not raise a 500

For some reason, reply sent via email (Message-ID: <20170228094235.GF10310@redhat.com>)
haven't yet hit the web frontend (the email was GPG-singed but I seem to
recall that such responses were handled OK), so repasting through web:

So the reason for this is to look for in the git repo itself:
ValueError: 3a5b54a83e99d688e4498b05d137d378531a3dea: Failed to parse signature - malformed e-mail

Hmm, I don't see anything wrong about email addresses associated with
underlying commit 74f18d1a69370b9d17a4bf979bd5ea794557710d.
Also, neither tag nor commit is GPG signed.

Just FYI, the side effect is that upon manual distribution file upload,
user is redirected back to /releases, and if that page fails in
a described fashion, the informative bubbles about file that has just
been uploaded will keep stacking on that failing page if there are more
files to be uploaded (it was actually a pro this time as I had a quick
way to verify which file to continue with in row :-).

So two things on this:

• Basically I have a fix for this which will make the page render correctly but without the problematic tags

• basically, this is likely an issue in libgit2 we're using underneath (via pygit2) the tag object are a little different:

$ git cat-file -p RHEL4-beta
object 74f18d1a69370b9d17a4bf979bd5ea794557710d
type commit
tag RHEL4-beta
tagger Patrick Caulfield
$ git cat-file -p cluster-2.02.00        
object 1f0985dfe6d4d79a539abbe4a681c10296837d91
type commit
tag cluster-2.02.00
tagger David Teigland <teigland@rh.com> 1204837016 -0600
cluster-2.02.00 release

(email manually edited to reduce email scan)

Commit 61664129 fixes this issue