> 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 and
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 `me
@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 mai
@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___
Rpm
> 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 thes
> * 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 t
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
Pretty much not at all, since RPM shelled out to a program which then returned
a blob of text it stored as dependency information.
--
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/rp
cc: @Vogtinator
--
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-760170675___
Rpm-maint mailing list
Rpm-maint@l
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
Rpm-maint@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
Err, no. There might be an off-by-one in the code, but you don't need all this
and an abort(), to deal with that.
Start with the basics. What is the scenario where 'end' is beyond the
allocation? Do you have a reproducer for this?
--
You are receiving this because you are subscribed to this th
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
Rpm-maint@lists.rpm
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
n
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 helps
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:
https://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 surp
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,
sizeof
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 f
20 matches
Mail list logo