> Thing is, since the payload is typically compressed, offsets are useless
> because they'd just point to somewhere in the middle of a compression stream,
> you can't jump to it without reading the whole thing anyhow.
zstd frame headers can carry both compressed and uncompressed sizes, which
@ddiss fsverity would also be suitable. If you go with this approach, I
recommend also including the total length of the payload in the (signed)
header, to avoid vulnerabilities where extra data somehow doesn’t get hashed.
--
Reply to this email directly or view it on GitHub:
@DemiMarie I wonder whether packaging fsverity (Merkle tree) metadata into the
rpm header would be an option for performant block-based hashing. It'd also
bloat the rpm header, but may have the benefit of allowing the metadata to be
reused for post-installation integrity and authenticity
So what does this do when we use it to declare only a subpackage as noarch?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2085451141
You are receiving this because you are subscribed to this thread.
Message ID:
I think as long as the zstd frame boundaries align with individual file data
segments then it should still work fine with `BTRFS_IOC_ENCODED_WRITE` and
reflink, although we'd need to write out individual files immediately rather
than staging the complete cpio archive.
--
Reply to this email
@pmatilai pushed 1 commit.
a5ea8c6db14455399d5447601ab0b5ebe7896878 Automatically reload rpm
configuration on mismatching BuildArch
--
View it on GitHub:
Eh, including the test-spec in the commit improves the chances of success...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3071#issuecomment-2084986916
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 1 commit.
d09c5e9543dedac603f95e7a3252b10fecea5d85 Automatically reload rpm
configuration on mismatching BuildArch
--
View it on GitHub:
The way buildForTarget() now serves two quite different purposes is a bit ugly
of course but keeps the patch small. I'd rather live with this for now and
address the whole thing at a more fundamental level later on.
--
Reply to this email directly or view it on GitHub:
When BuildArch is encountered during spec parse, rpm recurses the parse, but
this doesnt reset/reload the global configuration and macros to match. So
eg a BuildArch: noarch package gets built with a dramatically
different macros depending on whether --target noarch was used or
not, whereas
--target causes the entire rpm configuration to be reloaded from scratch, and
since --undefine operates on the init macro context at program startup, the
rpmPopMacro()'s it does get lost in the reload. Filing this as "documentation"
for the issue: if nothing else, it's inconsistent behavior.
Closed #2313 as resolved.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2313
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Thing is, since the payload is typically compressed, offsets are useless
because they'd just point to somewhere in the middle of a compression stream.
If the files in the payload were individually compressed, it'd seem quite
reasonable to have offsets stored. Of course that would likely loose
There are no offsets stored, so I don't think there is.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-9271000
You are receiving this because you are subscribed to this thread.
Message ID:
Is there any way to pad (for alignment) between file data segments in the v6
payload? IIUC, the rpm header carries file data payload offset and length
information, so perhaps sparse / zero ranges in between might be possible?
--
Reply to this email directly or view it on GitHub:
Merged #3069 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3069#event-12652696073
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3067 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3067#event-12652692342
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3066 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3066#event-12652691270
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Merged #3062 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3062#event-12652690152
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
> The rpm payload format isn't modified, although there's a slight "bending" of
> the cpio/newc spec to use the filename field for padding. zstandard frames
> making up the compressed rpm payload explicitly carry both compressed and
> uncompressed lengths, to allow detection of
20 matches
Mail list logo
