Fix a regression from commit 22106f5d33628515d22c09c1c15dfd2217535116

[DemiMarie]

Commit 22106f5 assumed that
dataLength() would always return a nonzero number. Unfortunately, that
isn’t the case: dataLength() returns zero for RPM_NULL_TYPE. This meant
that hdrblobVerifyInfo() failed to reject such entries, which are
invalid.

This fixes the problem in three different ways:

1. It checks that tag data entries have length greater than zero.
2. It modifies hdrchkType() to reject RPM_NULL_TYPE.
3. It modifies dataLength() to consider zero length as an error.

[pmatilai]

Sigh. I'm kinda tempted to just revert the previous commit instead because when you actually look at it:

len comes from dataLenght(), to which we pass the upper limit so it cannot be larger than the header. So it is in range.

I'm really, really fed up with these kind of patches now.

[pmatilai]

Replaced by #1597. I will not consider any patches in this direction unless there's a concrete reproducable bug involved, far too many regressions by these theoretical hardening patches.

Thanks for pointing out the regression of course.

[DemiMarie]

Replaced by #1597. I will not consider any patches in this direction unless there's a concrete reproducable bug involved, far too many regressions by these theoretical hardening patches.

For clarification: does “undefined behavior detected by sanitizers” qualify?

[pmatilai]

As a rule of thumb: if it shows up in valgrind (or address sanitizer), it's a bug that needs to be addressed.
Obviously there are bugs that will not show up in valgrind that still need fixing - that's just a ballpark rule. As for ubsan, take it with a grain of salt: I'm far from convinced it actually honors the used compiler standard, and so will cause all manner of false alarms to be tripped.