Be much more careful about copying data from the signature header

[pmatilai]

Only look for known tags, and ensure correct type and size where known
before copying over. Bump the old arbitrary 16k count limit to 16M limit
though, it's not inconceivable that a package could have that many files.
While at it, ensure none of these tags exist in the main header,
which would confuse us greatly.

This is optimized for backporting ease, upstream can remove redundancies
and further improve checking later.

Fixes: RhBug:1935049, RhBug:1933867, RhBug:1935035, RhBug:1934125, ...

Fixes: CVE-2021-3421, CVE-2021-20271

[pmatilai]

(reporter credits added to commit message)

[DemiMarie]

Thank you! I included a couple of minor performance suggestions, but those should not delay merging.

[pmatilai]

I included a couple of minor performance suggestions, but those should not delay merging.

But that's exactly what such things tend to do, as I'm now wondering could there be some quirks code, especially very old versions, that cause it to actually rely on the put-sort cycle. It's extremely unlikely, but there have been stranger things (see commit da3a3a1)

[pmatilai]

Split the optimization part to a separate commit so the first one can be safely picked for old versions.
I merged the MINMEM part to the first commit though - I had some kind of reason to not put it there in the first place (probably just that MINMEM is a bit iffy in the first place), but thinking it again, MINMEM is what the header iteration does so in a way this is closer to the original behavior.

[pmatilai]

Mind you, the suggested optimization to avoid multiple sorts totally makes sense and never occurred to me at all (too much staring at how it always did it), so thanks for that! Just that with critical fixes needing backports and all, other enhancements such as performance are best kept apart - I planned to do a PR for that separately sooner or later.