TL;DR The 2nd headerReload() appends RPMSIGTAG_PADDING into a contiguous
PROT_READ block.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Several points:
1) Your check for repackaged packages is what is running afoul of (what is
obscurely known as) a "dribble", a tag appended to an immutable region, which
is commonly found in repackaged packages (with a doubly linked upgrade chain
tag appended) and in rpmdb headers (signature
Closed #270.
--
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/issues/270#event-1363134715___
Rpm-maint mailing list
Anyway... the check disabled for the signature header in commit
34c2ba3c6a80a778cdf2e42a9193b3264e08e1b3, thanks for the patience everybody.
There will be an update to 4.14.x sooner than later, this will be included.
--
You are receiving this because you are subscribed to this thread.
Reply to
Oh okay, took a dog-walk for it to register: in rpm5 RPMSIGTAG_PADDING is used
for the actual padding between the signature and main header, which is
different from rpm.org's RPMSIGTAG_RESERVEDSPACE. From the initial description
of #183 I assumed it was essentially the same and, I admit, didn't
Ehm, maybe we have a terminology problem here. When I talk about signature
header immutable region, I mean HEADER_SIGNATURES region. That's not used for
digests or signatures and when adding/removing signatures the signature header
changes more fundamentally than just padding adjustments. So
@pmatlai: you are claiming "might well be a bug" in rpm5 at bz#1514190 without
supplying details.
Either supply sufficient details (or a patch preferred) or stop claiming FUD,
entirely your call.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
The signature padding tag cannot be part of an immutable region because its
size/value can/will change. There is also little reason to include padding
within plaintext used for digests/signatures
As for ordering: you chose a different value for the padding tag than what is
implemented in rpm5.
...to continue on the padding tag placement, this is what I see in the capsule
package signature header:
```
Index entries: 7 (112 bytes)
Data size: 792
Header size: 904
Tag #0
tagno:62 (Headersignatures)
type: 7 (blob)
offset: 152
count:16
[...]
Tag
An update, I've contacted the maintainers of the internal signing service to
obtain information about the rpm version used by their system to sign packages.
I'll post an update as soon as I hear from them.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
FWIW that --delsign corruption is of course a bug in <= 4.13.0 someplace, if it
can't handle it should at least refuse to touch it. That corruption longer
happens in 4.13.90 (once patched to accept the package in the first place) so
it's gotten fixed somewhere along the road, whatever it is.
Oh, sorry for missed that. But now the question is, what rpm version is used to
*sign* that package?
It doesn't seem like any rpm.org upstream version because deleting the
signature (with rpm <= 4.13.0) corrupts the package beyond recognition of those
older versions too:
```
[pmatilai@sopuli
Note that a package produced by rpm 4.13 reproduced the problem.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The check is not changing what immutable region is, it's there because
traditionally headers coming off packages on the disk have not had anything
outside the immutable region (and yes the message doesn't make a very good job
of expressing that, shrug) - with the exception of:
- repackaged
Other nitpicks in the geeky error message: the check has nothing to do with a
"tag number mismatch", and lacks an "il" identifier that might have helped
diagnose the problem slightly more rapidly.
OTOH, I'm not sure anyone can diagnose a problem in the binary header format
without a
btw, this command is sufficient to identify the rpm version that built the
package:
`rpm -qp --qf '%{rpm version}\n' intel-aero-repo-1.4-r0.corei7_64.rpm`
It looks the arguments passed used in the exact_size check are incorrect (the
"ril" and "rdl" values in the error message seem wrong).
@n3npq, thanks for your comments.
It's just to add more info:
A possible conflict between package generated by rpm5 x rpm4 was one of our
first hypothesis, however the same issue happens with signed packages generated
by rpm4 (for the yocto-2.3 based system):
```
bash-4.3# rpm5 -qp --yaml
The often stated public policy here with RPM4 is "Compatibility with RPM5 is a
negative goal."
Don't hold your breath for a patch: I will generate and distribute a patch as
soon as I understand
the full consequences of recent changes to the RPM format.
Yes, Yocto issues are well known. The
Regarding using RPM4 to manager RPM5 packages, the reason is that the previous
version of the distro was using RPM5. However due to incompatibilities with dnf
it was decided by uptream Yocto developers do switch to RPM4. In our
Yocto-based distro there are some leftover rpm files that weren't
@n3npq thanks for looking into this. This rpm may be the only one I'll have to
deal with and I can regenerate it using rpm4 reasonably easy. However I thought
it was important to notify upstream since when other distros update they may
face similar problems since they don't have much control
That is a package produced by RPM5:
```
$ /opt/local/bin/rpm -qp --yaml ./capsule-01.00.12-r0.core2_64.rpm | grep
Rpmversion
Rpmversion: 5.4.16
```
The package uses a non-repudiable signature and verifies fine:
```
$ /opt/local/bin/rpm -qvvp ./capsule-01.00.12-r0.core2_64.rpm
...
D: PUB:
21 matches
Mail list logo
