> But that's getting off track. The thing is, there can never be "only one" set
> of algorithms in rpm. The initial design did just that, and that's why we're
> still forced to deal with MD5 as a required field in packages produced a
> decade after MD5 was declared obsolete. The rpm lifespan
The only case where `end` can be beyond the allocation is for the last entry in
the header. This can happen for v3 headers, or v4 headers that aren’t
contiguous. I know that compilers are allowed to assume that the arguments to
`memcpy` can be dereferenced, and the same may also be true of
@pmatilai Please? :crying_cat_face:
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1317#issuecomment-760231299___
Rpm-maint
@mlschroe approved this pull request.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1465#pullrequestreview-568249257___
> Do I understand it correctly that you'd essentially do a `my_spec_generator >
> %_builddir/__rpm/subpac.spec` which would e.g. contain a new subpackage
> definition?
Basically yes. As this is run in the %build or %install section you would need
to modify your spec generator to not output
> * The generated spec fragments need to have some other suffix than *.spec to
> avoid confusion. Call it .specpart or whatever, but they are not spec files
> so they must not be mistaken as such, either by humans or the computer (eg
> multiple .spec files in a tarball will confuse rpm)
> * If
This looks intriguing!
Do I understand it correctly that you'd essentially do a `my_spec_generator >
%_builddir/__rpm/subpac.spec` which would e.g. contain a new subpackage
definition?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
cc: @dcermak
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1485#issuecomment-760169523___
Rpm-maint mailing list
There is a middle way how to deal with signatures: Append at the end of the
package. RPM should probably dictate a way how they should be separated. Then
one could just read the last few kB of the package and check for signatures
there without understanding the rpm format at all. You could also
Closed #1493.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1493#event-4205564323___
Rpm-maint mailing list
NAK.
This is actually an entirely useless check (the existing one in regionSwab()
equally so) as it misses the real limit by such a *huge* margin, yet gives you
a false sense of security from doing yet another check.
The one count-related thing we can check straight away is that it has to be
The added check may well be right, but it hardly prevents "any possible
overflow" there could ever be.
If you look at past commits, we go to great lengths to explain in which
situation some problem can happen and how the existing checks are not suffient,
please help keep the tradition. It
It's entirely legitimate for a *header* to be empty, region or no.
A *package* cannot have an empty header (or region), but that'd be a different
kind of check.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The check is probably fine, but the "checked for other headers" commit message
does not make sense.
I presume you mean "other header entries" instead? A header is the container,
containing zero or more entries.
--
You are receiving this because you are subscribed to this thread.
Reply to this
This is no "header with count zero", it'd be a header tag data with count zero.
Which is something that cannot legitimately exist.
Now, one would *think* we already catch that *someplace*, but after meeting
several such canyon-wide cracks in the checks in the last hardening round,
nothing
This is because the void pointer is then cast to an int32_t pointer, right?
Please put that align check into a macro and refer to the actual thing it
depends on, that'll make it much more self-explanatory than this
random/magic-looking `& 7`. Ie something to the tune of `if (chkAlign(uh,
More random thoughts as they trickle through this old-but-not-obsolete (yet)
processor of mine... :brain:
- This is too implicit as it is. Existing carefully hand-crafted packages can't
start behaving differently because somebody else somewhere did something
(unless that something creates new
17 matches
Mail list logo
