Re: [Rpm-maint] [rpm-software-management/rpm] Move the DSI struct to a header for c++ to see (09d90d4)
I imagine this would be more ideal as a boolean value. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/commit/09d90d4012f97d287b1c77490f666ce115191f89#r143612130 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Replace digest bundle static sized array with STL map (PR #3163)
>Technically it's more efficient because we don't need to brute-force search Well, for small numbers of items (<100) brute force is generally faster than a map. Not that it matters - like you say, the real-world difference is negligible. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3163#issuecomment-2167997537 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Convert major librpmbuild structs to native C++ allocation / initialization (PR #3099)
@dralley commented on this pull request.
> }
StringBuf freeStringBuf(StringBuf sb)
{
-if (sb) {
- sb->buf = _free(sb->buf);
- sb = _free(sb);
-}
-return sb;
+delete sb;
I assume / hope there's an intention to move away from `new` / `delete` at a
later stage of refactoring?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3099#pullrequestreview-2058598175
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Examine Compressed Headers (Issue #2220)
Doesn't seem worth it to me -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2220#issuecomment-2094014697 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Return to Tralla La or: RPM in C++ (Discussion #2983)
I mean, it's not a full implementation because it only handles building, signing and parsing packages (not rpmdb management or specfile parsing or anything else), but, it kind of already exists https://github.com/rpm-rs/rpm -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2983#discussioncomment-9311318 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add option to use an external decompressor to rpm2cpio and rpm2archive (Issue #1939)
I read this issue as being "we should fail, but currently we ignore by default. Let's fail by default and provide an option to ignore" Which would be a change to how it currently behaves in addition to adding a new option (to restore present behavior) But I might have read that incorrectly -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1939#issuecomment-2039764446 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: add option to use an external decompressor to rpm2cpio and rpm2archive (Issue #1939)
@pmatilai As a behavioral change, perhaps this is suitable for RPM v6? (as in v6 of the tool, not v6 of the format) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1939#issuecomment-2038570348 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
How about defaulting to Zstd compression as opposed to Gzip? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-9014566 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Rethinking RPM architecture support (Discussion #2060)
Crazy idea: perhaps RPM should take into consideration GPU architecture? Currently the CUDA and ROCm packages tend to be **massive**, and that's partly because they contain optimized code for nearly a dozen different generations of GPUs. ``` $ dnf info rocblas rocsparse rocsolver Last metadata expiration check: 0:08:54 ago on Wed 06 Mar 2024 06:09:47 PM EST. Installed Packages Name : rocblas Version : 6.0.0 Release : 3.fc40 Architecture : x86_64 Size : 6.7 G Source : rocblas-6.0.0-3.fc40.src.rpm Repository : @System >From repo: fedora Summary : BLAS implementation for ROCm URL : https://github.com/ROCmSoftwarePlatform/rocBLAS License : MIT AND BSD-3-Clause Description : rocBLAS is the AMD library for Basic Linear Algebra Subprograms : (BLAS) on the ROCm platform. It is implemented in the HIP : programming language and optimized for AMD GPUs. Name : rocsolver Version : 6.0.0 Release : 4.fc40 Architecture : x86_64 Size : 2.2 G Source : rocsolver-6.0.0-4.fc40.src.rpm Repository : @System >From repo: fedora Summary : Next generation LAPACK implementation for ROCm platform URL : https://github.com/ROCmSoftwarePlatform/rocSOLVER License : BSD-3-Clause AND BSD-2-Clause Description : rocSOLVER is a work-in-progress implementation of a subset : of LAPACK functionality on the ROCm platform. Name : rocsparse Version : 6.0.0 Release : 3.fc40 Architecture : x86_64 Size : 4.8 G Source : rocsparse-6.0.0-3.fc40.src.rpm Repository : @System >From repo: fedora Summary : SPARSE implementation for ROCm URL : https://github.com/ROCmSoftwarePlatform/rocSPARSE License : MIT Description : rocSPARSE exposes a common interface that provides Basic : Linear Algebra Subroutines for sparse computation : implemented on top of AMD's Radeon Open eCosystem Platform : ROCm runtime and toolchains. rocSPARSE is created using : the HIP programming language and optimized for AMD's : latest discrete GPUs. ``` It would be nice if installing only the appropriate implementation for the system's current GPU could be streamlined. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2060#discussioncomment-8739520 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
Ah, you're right that if the builder and rebuilder aren't the same person (which, really, is the primary use case of reproducible builds) then you won't be able to reproduce the package. @DemiMarie suggested a while back that if the non-signature aspects of the package are reproducible, then you can combine the signature of the original package with the signature of the rebuilt package, and *that* should be able to verify correctly as if it was completely reproduced. https://github.com/rpm-rs/rpm/issues/156#issuecomment-1575994196 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1973291699 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set git commit dates based on $SOURCE_DATE_EPOCH (PR #2930)
>A signed rpm build can never be "reproducible" according to their current >definition. Theoretically you could just ensure that the RPM signature uses the same `SOURCE_DATE_EPOCH` timestamp rather than the current time - it's a bit icky, but it works. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2930#issuecomment-1972502494 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
>rpmlib() dependencies on v3 compatibility are dropped: Are these being specifically singled out for deletion, or can we blanket-delete feature dependencies introduced before 4.6? Because that's a much longer, e.g. * ExplicitPackageProvides * FileCaps * FileDigests ... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8561838 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format draft, major update (Discussion #2919)
>this cannot be reflected in PAYLOADFORMAT as that would be a gratituous >compatibility break Ironically dropping the tag entirely would work fine, because of the backwards compatibility backflips already in place to deal with v3 packages. https://github.com/rpm-software-management/rpm/blob/1825dbf8244b129665a69481c4537a57b9e03a8f/lib/depends.c#L71 So... why not? The situation already exists where you need to actually look at the payload to figure out what it is, and use RPM to process it in any case. Alternatively can we at least neuter this check and get that backported, so that `PAYLOADFORMAT` could theoretically be fixed in a couple years. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2919#discussioncomment-8551719 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package generation rough-cut (PR #2920)
@dralley commented on this pull request.
> headerDel(pkg->header, RPMTAG_PAYLOADDIGEST);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGEST, pld);
headerDel(pkg->header, RPMTAG_PAYLOADDIGESTALT);
headerPutString(pkg->header, RPMTAG_PAYLOADDIGESTALT, upld);
pld = _free(pld);
+if (pkg->rpmver >= 6) {
+ headerDel(pkg->header, RPMTAG_PAYLOADSIZE);
+ headerPutUint64(pkg->header, RPMTAG_PAYLOADSIZE, , 1);
+ headerDel(pkg->header, RPMTAG_PAYLOADSIZEALT);
+ headerPutUint64(pkg->header, RPMTAG_PAYLOADSIZEALT, , 1);
I'm not fully sure I understand the use case for this
`RPMTAG_SIZE` / `RPMTAG_LONGSIZE` already covers the "how much space does this
package require once installed" case.
`RPMTAG_ARCHIVESIZE` / `RPMTAG_LONGARCHIVESIZE` already covers the uncompressed
payload size (in theory it should be the same as `RPMTAG_PAYLOADSIZEALT`?), and
it's *supposed* to be in the main header. And I don't think the value
overlaps? Why introduce something new, except to make the name more consistent?
There's no equivalent for compressed payload size, but with either compressed
*or* uncompressed payload size, you can't really usefully extract the
freestanding archive from the RPM, because RPM is (now) the only tool that can
process that archive. It just seems unnecessary to even include that info.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2920#pullrequestreview-1894488539
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
Why can't 6 go there? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8530347 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
Thanks! -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2861#issuecomment-1905116686 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
Closed #2835. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#event-11563746414 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
@dralley commented on this pull request. > @@ -56,6 +56,8 @@ contains an OpenPGP signature on the header + payload data. > The PGP tag is used for RSA signatures and the GPG tag is used for DSA signatures. +Note: the signature tags overlap with those of the main header. Oh, and as per https://github.com/rpm-software-management/rpm/issues/2462#issuecomment-1493217258, `RPMTAG_FILESIGNATURES` and `RPMSIGTAG_FILESIGNATURES` are actually completely different non-overlapping constants, it's just not noticed because of, again, the merging of the signature and main headers during queries. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2861#discussion_r1460236459 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
@dralley commented on this pull request. > @@ -56,6 +56,8 @@ contains an OpenPGP signature on the header + payload data. > The PGP tag is used for RSA signatures and the GPG tag is used for DSA signatures. +Note: the signature tags overlap with those of the main header. The precise meaning of this is a bit ambiguous. It might be possible to read this as "some tags can exist in both headers simultaneously" or "some tags can exist in either header". The latter is technically true but isn't that more an artifact of how the headers get merged together than "correctness"? It's definitely not universally true, as something would have to be seriously broken for a main header checksum/signature to end up in the main header :) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2861#pullrequestreview-1834626951 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
@dralley commented on this pull request. > +short archnum; +char name[66]; +short osnum; +short signature_type; +char reserved[16]; +}; +``` + +and is illustrated with one pulled from the rpm-2.1.2-1.i386.rpm +package: + +``` +: ed ab ee db 03 00 00 00 +``` + +The first 4 bytes (0-3) are "magic" used to uniquely identify an RPM ```suggestion The first 4 bytes (0-3) are the "magic" number used to uniquely identify the file as an RPM package. ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2861#pullrequestreview-1834624557 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
@dralley commented on this pull request.
> +## Lead Format
+
+The Lead is stored as a C structure:
+
+```
+struct rpmlead {
+unsigned char magic[4];
+unsigned char major, minor;
+short type;
+short archnum;
+char name[66];
+short osnum;
+short signature_type;
+char reserved[16];
+};
+```
Should endian-ness be discussed here?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2861#pullrequestreview-1834624461
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
@dralley commented on this pull request.
> +0048: 00 00 00 00 00 01 00 05
+```
+
+Bytes 76-77 ("00 01" above) form an int16 that indicates the OS the
+package was built for. In this case, 1 == Linux. The next 2 bytes
+(78-79) form an int16 that indicates the signature type. This tells
+RPM what to expect in the Signature. For version 3.0 packages, this
+is 5, which indicates the new "Header-style" signatures.
+
+```
+0050: 04 00 00 00 68 e6 ff bf
+0058: ab ad 00 08 3c eb ff bf
+```
+
+The remaining 16 bytes (80-95) are currently unused and are reserved
+for future expansion.
The second half of this line probably ought to be tweaked to be a little more
past-tense.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2861#pullrequestreview-1834623926
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Updated v3 and v4 package + header format documentation (PR #2861)
@dralley commented on this pull request. > + +Field | Value +|-- +tag | Must equal the Index Entry (ie 62 or 63) +type| BIN +offset | Size of the region entries in the Index +count | 16 + +The number of entries in the region (aka region index length) can thus be +calculated as `ril = -offset / sizeof(struct index_entry)`. + +When reading a package from disk, the number of region entries is expected +to be the same as the index length in the Intro. However when a package +is installed, extra data such as the install time is added to the header, +that data falls outside the otherwise invisible region line in the index. +These tags outside the immutable region are called "dribbles" in the RPM This happens to satisfy https://github.com/rpm-software-management/rpm/issues/2462, so thanks for that! Feel free to close it or mark it to be closed automatically on merge of the commit. I do also have a side remark under that issue, and I'm wondering if that should be tracked as a brand new issue, or discussion, etc. https://github.com/rpm-software-management/rpm/issues/2462#issuecomment-1493217258 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2861#pullrequestreview-1834612619 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
Understood, thanks! Feel free to close this once you're done with it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1901738765 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Always use long filesizes on v6 (80a238d)
Technically `totalFileSize <= UINT32_MAX` ought to be OK? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/commit/80a238d01d9587a53983fc090ee5f2827b8725f5#r136850899 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] First commit of rpm v6: make sha1 and md5 inclusion conditional (83c87b1)
```suggest # Which rpm format to generate (4 or 6) ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/commit/83c87b1c63f6f733971675943a2278549ad07a0a#r136849221 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
Updated -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1884986428 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. eb08565561b42ded13fea02054312a75553eebae Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/9f3185cb7bf13f78ad557116325fe75c452944e6..eb08565561b42ded13fea02054312a75553eebae You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
> Yup. The dependency is tracking the use of syntax that will create a package > that won't work quite right with versions of rpm before 3.0.3. ... >Not a bug. The dependency is written with <= so that the range is closed, as >>= would make the implicit promise "forever". Meanwhile, since the matching >capability is `Provides: rpmlib(VersionedDependencies) = 3.0.3-1` there's only >a single point covered by the overlapping dependency ranges. It makes some sense, but it's definitely counterintuitive. The first statement isn't entirely true because of the "or equals". The second statement almost doesn't matter, because rpm presents the exact versions anyway. And if RPM presents them as a list of capabilities, then why not just match on the capabilities rather than dragging version numbers into it? I guess to make error messages more informative -- assuming that is taken advantage of. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8073170 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 3 commits. f161a47fa0ff1349acfd5fa62a58fc2b88a3650d Update format documentation in the manual e452eab72b4df2c9ae8ad8bbcc8a9a2acf1c2b0f Merge header regions document into format document 9f3185cb7bf13f78ad557116325fe75c452944e6 Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/04496586ad15ce3f0fcb724bd69376a6c1386e7d..9f3185cb7bf13f78ad557116325fe75c452944e6 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > @@ -264,3 +256,101 @@ could start at byte 589, byte that is an improper > boundary for an INT32. As a result, 3 null bytes are inserted and the date for the SIZE actually starts at byte 592: "00 09 9b 31", which is 629553). +### Immutable header regions I kept any changes to this document in a separate commit so they can be more easily reviewed. There's plenty of room for improvement still, but this seems halfway reasonable? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1811898925 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > # Package format -This document describes the RPM file format version 3.0, which is used -by RPM versions 2.1 and greater. The format is subject to change, and -you should not assume that this document is kept up to date with the -latest RPM code. That said, the 3.0 format should not change for -quite a while, and when it does, it will not be 3.0 anymore :-). +This document describes the RPM file format version 4.0. The format is subject Done. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1446541624 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. cbebd9eccf2d57132c676a5b14996e8616e4d42b Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/64b4c81b4ae9d1599084676d1a8f999bfc11abfc..cbebd9eccf2d57132c676a5b14996e8616e4d42b You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 3 commits. 1ece805fc54d31715afdc56c7dbb0d35a82863bd Update format documentation in the manual 73403c2ad734c2b816c0f881ac2e822b13bbf7ab Merge header regions document into format document 64b4c81b4ae9d1599084676d1a8f999bfc11abfc Clean up immutable regions section a bit -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/c579fbf1a914f96fa14465acec97390197740f54..64b4c81b4ae9d1599084676d1a8f999bfc11abfc You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > # Package format -This document describes the RPM file format version 3.0, which is used -by RPM versions 2.1 and greater. The format is subject to change, and -you should not assume that this document is kept up to date with the -latest RPM code. That said, the 3.0 format should not change for -quite a while, and when it does, it will not be 3.0 anymore :-). +This document describes the RPM file format version 4.0. The format is subject I can add some descriptions of the immutable region. I believe that's documented somewhere, maybe it's worth merging into this document. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1446446353 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
How would that work exactly? Add a `%doc(README)` to replace `%readme`? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8067851 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > @@ -229,7 +216,7 @@ In our example there would be 32 such 16-byte index > entries, followed by the data section: ``` -0210: 72 70 6d 00 32 2e 31 2e 32 00 31 00 52 65 64 20rpm.2.1.2.1.Red +0210: 72 70 6d 00 32 2e 31 2e 32 00 31 00 52 65 64 20rpm.2.1.2.1.Red Fixed, my editor removed the trailing space -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1444732504 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. c579fbf1a914f96fa14465acec97390197740f54 Update format documentation in the manual -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/dbd7eb8f93c9804ff37ae22ef8d01f507b384318..c579fbf1a914f96fa14465acec97390197740f54 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. dbd7eb8f93c9804ff37ae22ef8d01f507b384318 Update format documentation in the manual -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/f44637672c6096f2dac5e5b87291b9fbb06da6f7..dbd7eb8f93c9804ff37ae22ef8d01f507b384318 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. f44637672c6096f2dac5e5b87291b9fbb06da6f7 Update format documentation in the manual -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/b891bfcbacb824507cd3527cfa5951c24be55bd4..f44637672c6096f2dac5e5b87291b9fbb06da6f7 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > ``` 0008: 00 01 72 70 6d 2d 32 2e..rpm-2. ``` -The next two bytes (8-9) form an int16 that indicates the architecture -the package was built for. While this is used by file(1), the true -architecture is stored as a string in the Header. See, lib/misc.c for -a list of architecture->int16 translations. In this case, 1 == i386. I couldn't find that mapping anymore, but I don't know if we have much need to discuss it anyway. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1807648743 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. b891bfcbacb824507cd3527cfa5951c24be55bd4 Update format documentation in the manual -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/a561596b015506565c2370559586156b5db0293b..b891bfcbacb824507cd3527cfa5951c24be55bd4 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > + +The Signature can contain multiple different types of signatures, stored under +unique tags (just like the Header). Details about these tags and the information +they store can be found [here](signatures_digests.md). + +RPM v4 packages are expected to contain at least one of SHA1HEADER or SHA256HEADER +tags, providing a cryptographic digest of the main header, and may contain one +or both of the PAYLOADDIGEST and PAYLOADDIGESTALT tags, providing a cryptographic +digest of the package payload in the compressed and uncompressed forms, respectively. + +If the package has been cryptographically signed using OpenPGP, an RSAHEADER or +DSAHEADER tag ought to be present, which contains an OpenPGP signature of the +package header. Which tag is present depends on which of the two (supported) +OpenPGP algorithms was used at signing time. Using a key based upon the RSA +algorithm to sign the package will result in the signature being stored in the +RSAHEADER tag, whereas the use of the EdDSA (ed25519) algorithm will use the I'm not a cryptography person, I'm unsure if this is an appropriate way to refer to an EdDSA signature that uses curve ed25519, or if it's OK to just refer to it as EdDSA (as happens in a few other places) > # Package format -This document describes the RPM file format version 3.0, which is used -by RPM versions 2.1 and greater. The format is subject to change, and -you should not assume that this document is kept up to date with the -latest RPM code. That said, the 3.0 format should not change for -quite a while, and when it does, it will not be 3.0 anymore :-). +This document describes the RPM file format version 4.0. The format is subject Is "4.0" fine or ought we to use something along the lines of "V4" instead? > -header structure: - -``` - NameTag Header Type - --- - SIZE1000INT_32 - MD5 1001BIN - PGP 1002BIN -``` - -The MD5 signature is 16 bytes, and the PGP signature varies with -the size of the PGP key used to sign the package. - -As of RPM 2.1, all packages carry at least SIZE and MD5 signatures, -and the Signature section is padded to a multiple of 8 bytes. +"Header-style" signatures (denoted by signature type 5 in the Lead), use the Unsure if "denoted by" should stay - at this point, it should probably be assumed, regardless of what the lead says. No reason to look at the lead at all. > +they store can be found [here](signatures_digests.md). + +RPM v4 packages are expected to contain at least one of SHA1HEADER or SHA256HEADER +tags, providing a cryptographic digest of the main header, and may contain one +or both of the PAYLOADDIGEST and PAYLOADDIGESTALT tags, providing a cryptographic +digest of the package payload in the compressed and uncompressed forms, respectively. + +If the package has been cryptographically signed using OpenPGP, an RSAHEADER or +DSAHEADER tag ought to be present, which contains an OpenPGP signature of the +package header. Which tag is present depends on which of the two (supported) +OpenPGP algorithms was used at signing time. Using a key based upon the RSA +algorithm to sign the package will result in the signature being stored in the +RSAHEADER tag, whereas the use of the EdDSA (ed25519) algorithm will use the +DSAHEADER tag instead. The name of the DSAHEADER tag is a historical artifact, +it originally referred to the long-obsolete DSA algorithm but was later reused +for EdDSA (ed25519) signatures. Is it possible to define an alias? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1807604224 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley pushed 1 commit. 6ede171288e5bb6e565818e988cfa4bf69962367 Update format documentation in the manual -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835/files/5bfcfa058cdd7c6a93c2d96e02dea9fc044b5476..6ede171288e5bb6e565818e988cfa4bf69962367 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > ## Signature -A 3.0 format signature (denoted by signature type 5 in the Lead), uses -the same structure as the Header. For historical reasons, this -structure is called a "header structure", which can be confusing since -it is used for both the Header and the Signature. The details of the -header structure are given below, and you'll want to read them so the -rest of this makes sense. The tags for the Signature are defined in -lib/signature.h. Everywhere that mentioned source code previously was broken :broken_heart: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1807604119 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > ``` : ed ab ee db 03 00 00 00 ``` -The first 4 bytes (0-3) are "magic" used to uniquely identify an RPM -package. It is used by RPM and file(1). The next two bytes (4, 5) -are int8 quantities denoting the "major" and "minor" RPM file format -version. This package is in 3.0 format. The following 2 bytes (6-7) -form an int16 which indicates the package type. As of this writing -there are only two types: 0 == binary, 1 == source. +The first 4 bytes (0-3) are the "magic" number used to uniquely identify a file +as an RPM package. It is used by RPM and file(1). The next two bytes (4, 5) +are int8 quantities denoting the "major" and "minor" RPM file format version. +For legacy reasons, this version is always "3.0" (major version "3", minor +version "0"), even with packages built by RPM 4.0+ (referred to as RPM v4 +packages). The following 2 bytes (6-7) form an int16 which indicates the +package type. As of this writing there are only two types: 0 == binary, +1 == source. Sometimes it's hard to tell what changed apart from the line wrapping, but there are wording adjustments in here I promise :) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1807603861 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
@dralley commented on this pull request. > @@ -23,17 +23,20 @@ package file is divided in 4 logical sections: . Payload -- compressed archive of the file(s) in the package (aka "payload") ``` -All 2 and 4 byte "integer" quantities (int16 and int32) are stored in -network byte order. When data is presented, the first number is the -byte number, or address, in hex, followed by the byte values in hex, -followed by character "translations" (where appropriate). +All 2 and 4 byte "integer" quantities (int16 and int32) are stored in network +byte order (big-endian). When data is presented, the first number is the byte +number, or address, in hex, followed by the byte values in hex, followed by +character "translations" (where appropriate). I figured it would be OK to increase the line wrapping from 70 characters to 80 (roughly). Let me know if that's inappropriate, or if it can be wrapped to e.g. 100 characters. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1807603646 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Update format documentation in the manual (PR #2835)
Make it (mostly) up to date with RPMv4 standards. Also fix some broken links, and mark old signature tags as deprecated. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2835 -- Commit Summary -- * Update format documentation in the manual -- File Changes -- M docs/manual/format.md (193) M docs/manual/signatures_digests.md (27) M docs/manual/tags.md (16) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2835.patch https://github.com/rpm-software-management/rpm/pull/2835.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Documentation refers to %prein and %postin, which do not seem to be supported (Issue #2834)
Unrelated, but this line found in the scriptlet documentation seems rather out of date :) > The %pre script executes just before the package is to be installed. It is > the rare package that requires anything to be done prior to installation; > none of the 350 packages that comprise Red Hat Linux Linux 4.0 make use of > it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2834#issuecomment-1879744872 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Documentation refers to %prein and %postin, which do not seem to be supported (Issue #2834)
I expect it means %pre and %post, which admittedly break the pattern followed by the other scriptlet types. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2834 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %missingok is undocumented (Issue #2833)
%config(missingok) is documented, however, %missingok is not. Presumably there is a lot of overlap, but it is unclear if there are any distinctions in when and how they should be used. vattrtest.spec only tests %missingok, can I presume that they are equivalent in function? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2833 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %caps is undocumented (Issue #2832)
The manual doesn't include any details about %caps, the only mention is in the changelog, a couple of command line flags, and specfiles used for testing purposes. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2832 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
`%readme` is documented as being obsolete, perhaps it should be removed with a shim that behaves as though it was marked as `%doc` instead, with a warning message to change it? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8028452 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
>group tag made optional Come to think of it, is this considered legacy nowadays? IIRC the Fedora packaging guidelines and other distros recommend against it, I believe comps kind of replaced it? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8024405 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
>From a discussion with @Conan-Kudo > (me) what is the intended purpose behind RPM automatically adding a > config($pkgname) dependency to both the provides and requires dependency > lists of a package with a %config declared in the specfile? why self-require > like that? > (neal) My understanding is the original intent is to make it trivial to > identify packages that have config files marked as %config. The self-requires > thing comes as a consequence of the usage of %config triggering that > requirement. But honestly, self-requires should be optimized out in general. > The "other" RPM did this and it nicely reduced the amount of data produced > for repodata. I'm curious whether self-requires are something that could be dropped? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-8016524 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
> rpmlib() dependencies are reset (ideally they'd be replaced by a better > mechanism but that's probably out of scope) Unrelated (or maybe related) question - why are rpmlib dependencies set with less-than or equal-to the version in which the feature was added? Is trying to express that "if the version is <= this version, rpm needs to be patched with this feature to accept the rpm"? I'm not sure I understand why it wouldn't just check for support of the feature, period (if that is indeed what it's doing). Otherwise I would think it would be trying to express "I need at least this version (greater than) because of this feature" -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-7921785 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Examine Compressed Headers (Issue #2220)
How one would compress the header section without altering some aspect of the format significantly (in a way that would not be trivial to backport)? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2220#issuecomment-1841634630 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
I wouldn't say SHA2-256 is falling out of fashion, most crypto-people seem to think there's not much risk of it being broken any time soon. But a bit of future proofing wouldn't hurt. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-7600333 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Remove lead checks other than the "magic number" check (PR #2736)
@dralley pushed 1 commit. 2d69151aa250d1dde056ed009c0fa644685da01c Remove lead checks other than the "magic number" check -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/2736/files/01ae94b0b1cfa60bbd98d050b40aef36701f7190..2d69151aa250d1dde056ed009c0fa644685da01c You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Remove lead checks other than the "magic number" check (PR #2736)
Remove checks on the leads signature type and rpm package format version fields. closes #2423 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2736 -- Commit Summary -- * Remove lead checks other than the magic number check -- File Changes -- M lib/rpmlead.c (12) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2736.patch https://github.com/rpm-software-management/rpm/pull/2736.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2736 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
Relevant https://github.com/rpm-software-management/rpm/issues/2462 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-7149254 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Eliminate RPMDBI_SIGMD5 and RPMDBI_SHA1HEADER rpmdb indexes (Issue #2633)
>(I don't know anybody using them so dunno) @Conan-Kudo I believe you may have mentioned in the past that the MD5 headers (pkgid) are used in some build systems? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2633#issuecomment-1703679446 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Ensure unique tags in signature header (#1570)
I still haven't been able to track down a cause for ^, do you happen to remember anything? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1570#issuecomment-1696001800 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
>MD5 and SHA1 dropped everywhere What about the flags `--hdrid` and `--pkgid`? https://github.com/rpm-software-management/rpm/blob/21457de886faf2415500a8bb7cc6c816d72939ef/docs/man/rpm.8.md?plain=1#L657 and ](https://github.com/rpm-software-management/rpm/blob/21457de886faf2415500a8bb7cc6c816d72939ef/docs/man/rpm.8.md?plain=1#L683) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6826927 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
How would that make using the parallel arrays easier? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6711380 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
re: "crypto modernization", maybe look at supporting SHA-3 checksums? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6675616 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: allow overriding buildtime and hostname via environment variable (Issue #2603)
Yes, `BUILDTIME` at the very least is [complicated](https://github.com/rpm-software-management/rpm/issues/2527). I'm not sure what infrastructure might rely on `BUILDHOST` being present, though. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1667794371 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: allow overriding buildtime and hostname via environment variable (Issue #2603)
As far as BUILDHOST goes, rather than using a default value, it would be better to just disinclude the tag IMO. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2603#issuecomment-1667144083 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Migrate away from SemaphoreCI Classic (Issue #2569)
You can use Fedora as a base image with Github Actions too - of course the VM will still be Ubuntu, but all of the commands can run inside of a container image of your choosing. https://docs.github.com/en/actions/using-jobs/running-jobs-in-a-container#defining-the-container-image -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2569#issuecomment-1639135778 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
@Conan-Kudo Is this making any sense? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6167128 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
>but we of course still store the file mtime in the header. Right, I understand, no disagreement there. If you need a fully reproducible package, you need to set source-date-epoch. But if you don't need or even want a fully reproducible package (but you still want the payload to be reproducible), you no longer need to set source-date-epoch, whereas currently you do (and *also* a bunch of flags to *disable* aspects of it). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6090470 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix an instance that used archivesize where it ought to use size (PR #2531)
Sorry if so, I don't recall seeing a response on that specific topic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2531#issuecomment-1576769144 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
Sorry for the miscommunication. The question I had started out with was >but the point of source_date_epoch is to make packages reproducable right? If >you allow the buildtime to be different, then the package is no longer >reproducable, and there's no reason to use source_date_epoch You pointed out that the purpose of `use_source_date_epoch_as_buildtime` is that various infrastructure needs a meaningful, non-static buildtime to function properly, but that there is still value in payload reproducability. In order to get payload reproducibility you need to clamp the mtimes of the files using SOURCE_DATE_EPOCH, because that metadata is baked into the CPIO. So you want to specify SOURCE_DATE_EPOCH but keep the buildtime independent. My point is that if the payload is always independent from those mtimes as I ?think? it would be with the new non-cpio archive format, then you get payload reproducibility all the time and don't need to set SOURCE_DATE_EPOCH to get it. Therefore, if you want full reproducibility you could specify it, and if you don't want it, you just don't specify it at all, and you still get the property of having a reproducible payload regardless. Granted as this behavior has now been in use for a while, it may not be easy to remove or change by default. I'm just saying that in theory, it could be simplified. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6084969 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix an instance that used archivesize where it ought to use size (PR #2531)
@dralley commented on this pull request. > @@ -104,7 +104,7 @@ static rpmRC markReplacedFiles(const rpmpsm psm) if (!headerGet(h, RPMTAG_FILESTATES, , HEADERGET_MINMEM)) continue; - + Ignore the editor autoformat noise. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2531#pullrequestreview-1461352969 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix an instance that used archivesize where it ought to use size (PR #2531)
Presumably this code is with regards to the installed size, not the size including CPIO headers. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2531 -- Commit Summary -- * Fix an instance that used archivesize where it ought to use size -- File Changes -- M lib/psm.c (8) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2531.patch https://github.com/rpm-software-management/rpm/pull/2531.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2531 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
As per discussion with @Conan-Kudo, the `use_source_date_epoch_as_buildtime` option can be deprecated if the new payload format no longer includes file mtimes, as the option only exists for payload reproducibility. If the payload is reproducible with or without SOURCE_DATE_EPOCH (because the mtimes are stored in the header rather than the payload), then it no longer serves a purpose. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-6084381 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --rebuilddb depends on the optional buildtime tag and breaks if a package without it is present (Issue #2527)
When I think expectation I kind of mean "such that it will fail if not present", but luckily it looks like that is not the case. ``` [dalley@thinkpad rpm-rs]$ rpm -qpi target/test.rpm warning: target/test.rpm: Header V4 RSA/SHA256 Signature, key ID 5ab27f39: NOKEY Name: test Epoch : 0 Version : 1.0.0 Release : 1 Architecture: x86_64 Install Date: (not installed) Group : Unspecified Size: 115241243 License : MIT Signature : RSA/SHA256, Sun 14 May 2023 01:21:34 PM EDT, Key ID cfd331925ab27f39 Source RPM : (none) Build Date : (none) Build Host : (none) Vendor : dummy vendor URL : dummy url Summary : some awesome package Description : ``` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2527#issuecomment-1571978739 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm --rebuilddb depends on the optional buildtime tag and breaks if a package without it is present (Issue #2527)
>Other examples of such tags include RPMTAG_BUILDHOST, RPMTAG_SOURCERPM and >RPMTAG_RPMVERSION, just to name a few. When you say expected, do you know specific examples for these? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2527#issuecomment-1570444195 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpm --rebuilddb depends on the optional buildtime tag and breaks if a package without it is present (Issue #2527)
`RPMTAG_BUILDTIME` is considered by all documentation I've seen so far to be an optional, informational tag as opposed to a mandatory one. However, `rpm --rebuilddb` will encounter issues if an RPM missing the buildtime tag is installed. A "sanity check" is done on all installed packages [ensuring that they all have the name, version, release and buildtime tags set](https://github.com/rpm-software-management/rpm/blob/83413bfd3949d7a1f18f00b0a59f77d41dc1/lib/rpmdb.c#L2474). If any package does not have all 4, then it will be skipped over with the message `error: header # in the database is bad -- skipping` But afterwards, the package is not listed in the database and cannot be uninstalled, but the files installed by the package are still present on disk, which seems like a potential issue with the greater `--repairdb` mechanism. There is some other software such as `mc` that apparently breaks on packages that don't have `RPMTAG_BUILDTIME` present as well. If there is any reason for it to be mandatory (such as being needed by `--repairdb` for some reason other than just a sanity check), then the documentation should be updated to mark it as such. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2527 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Ensure unique tags in signature header (#1570)
>RPMSIGTAG_FILESIGNATURES and RPMSIGTAG_FILESIGNATURELENGTH is a different kind >of mess, needs to be sorted out nevertheless (make RPMTAG_FILESIGNATURES just >an alias for RPMSIGTAG_FILESIGNATURES or something) I noticed that (some?) Fedora 37 packages seem to have RPMTAG_FILESIGNATURES in their signature header, is this part of the mess you're referring to? (it's a non-overlapping value, RPMTAG_FILESIGNATURES = 5090, RPMSIGTAG_FILESIGNATURES = 274) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1570#issuecomment-1546531254 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
How about no longer setting `RPMTAG_GROUP` to `Unspecified` automatically? Just exclude the tag. https://github.com/rpm-software-management/rpm/blob/93ee7d9c6164467608094a7e0652a0e3d84a6715/build/parsePreamble.c#L1239 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5880833 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Either the "legacy header merge" code or the documentation is incorrect (Issue #2498)
Thanks. What is the expected use case of providing the uncompressed archive size? Repository metadata exposes it, but frankly I don't understand why, it doesn't seem like particularly useful information. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2498#issuecomment-1532966234 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Either the "legacy header merge" code or the documentation is incorrect (Issue #2498)
Should this be looking at `RPMTAG_LONGSIZE` instead? https://github.com/rpm-software-management/rpm/blob/13e89c6ae5ff9cb20b0721e80732e7cde55da96c/lib/psm.c#L666 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2498#issuecomment-1530074417 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Either the "legacy header merge" code or the documentation is incorrect (Issue #2498)
Ok: *elsewhere* the documentation claims those tags are the uncompressed sizes >RPMTAG_LONGARCHIVESIZE - uncompressed payload size https://github.com/rpm-software-management/rpm/blob/c21885e6b0e3045dc165d4d7be1911987a9cec9b/docs/manual/large_files.md#64-bit-tags So maybe it's just the documentation that is wrong -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2498#issuecomment-1530070889 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Either the "legacy header merge" code or the documentation is incorrect (Issue #2498)
It looks probable that nothing has written a "correct" `RPMTAG_ARCHIVESIZE` tag since 2007. Given that nobody noticed, is there any reason to keep this stuff in rpm v6? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2498#issuecomment-1528647654 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
I'm not sure if this issue I've just filed calls into question the value of a couple of other tags? https://github.com/rpm-software-management/rpm/issues/2498 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5759752 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Either the "legacy header merge" code or the documentation is incorrect (Issue #2498)
The signature tags "payloadsize" and "longarchivesize" that both claim to be uncompressed payload sizes in the comments alongside. Then we have the main header tags "archivesize" and "longarchivesize" which the documentation describes as being compressed payload sizes. ``` RPMSIGTAG_PAYLOADSIZE = 1007,/*!< internal uncompressed payload size (32bit) in bytes. */ RPMSIGTAG_LONGARCHIVESIZE = RPMTAG_LONGARCHIVESIZE, /*!< internal uncompressed payload size (64bit) in bytes. */ RPMTAG_LONGARCHIVESIZE = RPMTAG_SIG_BASE+15, /* l */ RPMTAG_ARCHIVESIZE = 1046, /* i */ ``` > Archivesize | 1046 | int32 | (Compressed) payload size. > Longarchivesize | 271 | int64 | (Compressed) payload size when > 4GB. (from https://github.com/rpm-software-management/rpm/blob/master/docs/manual/tags.md#scalar-types) Note that the LONGARCHIVESIZE tag in both headers is represented by the same integer value but RPMSIGTAG_PAYLOADSIZE and RPMTAG_ARCHIVESIZE are independent In the "legacy header merge" code, the signature header tag `RPMSIGTAG_PAYLOADSIZE` is inserted into the main header as `RPMTAG_ARCHIVESIZE` and the signature header tag `RPMSIGTAG_LONGARCHIVESIZE` is inserted into the main header as `RPMTAG_LONGARCHIVESIZE` if the main header tags are not present. https://github.com/rpm-software-management/rpm/blob/e9caa60d668c8ae6a9cc83dba7f45792757eac46/lib/package.c#L34-L108 (sidenote: I gather from https://github.com/rpm-software-management/rpm/pull/1688 that these tags aren't supposed to be present in the main header, but I don't really understand why, given that's where the payload digest is?) Anyway, that means that either the documentation or the header merge code is wrong. Because if you fetch the `RPMTAG_ARCHIVESIZE` tag from the header, it would seem that in most cases that value will come from `RPMSIGTAG_PAYLOADSIZE`, and that value is the uncompressed size, contrary to the documentation. You can see this in practice - when printed with `rpm -qp --xml`, the value for `Archivesize` is larger than the entire package file (because the package file has a compressed payload). EL7 package ``` [dalley@thinkpad rpm-rs]$ rpm -qp --xml test_assets/389-ds-base-devel-1.3.8.4-15.el7.x86_64.rpm | rg -i -C 2 archivesize warning: test_assets/389-ds-base-devel-1.3.8.4-15.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY 4294967295 510164 [dalley@thinkpad rpm-rs]$ ls -la test_assets/ . . -rw-r--r--. 1 dalley dalley 277288 Apr 7 16:43 389-ds-base-devel-1.3.8.4-15.el7.x86_64.rpm ``` Fedora 38 package ``` [dalley@thinkpad rpm-rs]$ rpm -qp --xml zlib-1.2.13-3.fc38.x86_64.rpm | rg -i -C 2 archivesize warning: zlib-1.2.13-3.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID eb10b464: NOKEY 4294967295 213472 [dalley@thinkpad rpm-rs]$ ls -la . . -rw-r--r--. 1 dalley dalley 96890 Apr 16 11:26 zlib-1.2.13-3.fc38.x86_64.rpm ``` So the values of querying `RPMTAG_ARCHIVESIZE` (and presumably `RPMTAG_LONGARCHIVESIZE`) are in practice uncompressed, contrary to the documentation -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2498 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM package invariants? (Discussion #2025)
So, not really a question about packages themselves - [`parseEVR()`](https://github.com/rpm-software-management/rpm/blob/4afe2d14d33db82ccb41c0a8d5eb1a4db90762fc/rpmio/rpmver.c#L24-L57) is extremely lax on doing any kind of validation. For example all of these are parsed without complaint * `:` * `-` * `.` * `:-` * `asdf:` * `~:` * `-^` (and so on). Would doing such validation be useful or appropriate? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2025#discussioncomment-5687384 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)
Closed #2486 as not planned. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2486#event-9024780445 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)
Ok. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1511389601 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)
Sure, but in that case it should not look for PAYLOADDIGESTALT at all. Otherwise you'd just be comparing it against a value that it will not match most of the time. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1510445448 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)
@DemiMarie @pmatilai -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1510417707 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)
To reproduce: specfile ``` Name: rpm-test Version:0 License:LGPL Release:0 Summary:"" #BuildRequires: %description %build cat > hello-world.sh < ba21f4cb197179798065399a1551af2727e41efe56daed73ce869549b1280dd0 8 5ac031cfaded6e79dcb59b44946fc24c40e7d775e3ba020a7b4cb66238c4771f ``` Skipping ahead to what happens if you somehow produce a package where both checksums are incorrect, you can see that the checksum that `rpm` is calculating at verification-time for PAYLOADDIGESTALT is the same as the one for PAYLOADDIGEST.  If you do the same thing in a different way by instead writing to the package a PAYLOADDIGESTALT that matches PAYLOADDIGEST, then it verifies OK. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2486#issuecomment-1510415544 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Verification of PAYLOADDIGESTALT is broken (Issue #2486)
There are two components to this 1) `rpm -v --checksig` (also without -v) seems to exclude any digests which fail to verify so long as an equivalent one does verify. This seems to apply even when using `--define "_pkgverify_level all"`. 2) `rpm` appears to fail to verify PAYLOADDIGESTALT in situations where the payload is compressed (but because of #1 it is hidden from `--checksig` output completely). * If the payload is configured to be uncompressed (`w.ufdio`) when the package is built, then both digests will be checked and successfully verify. * If you use compression but manually modify PAYLOADDIGESTALT to match PAYLOADDIGEST, then both digests will be checked and successfully verify * If you manually modify the package so that the PAYLOADDIGEST is *also* wrong (but PAYLOADDIGESTALT ought to be correct) then both digests will appear in the output as having failed to verify. Also, the expected values printed in the error message are the same for PAYLOADDIGEST and PAYLOADDIGESTALT, which makes no sense for a package with a compressed payload. Presumably, the expected value of PAYLOADDIGESTALT during verification is being computed against the compressed payload rather than the uncompressed payload. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2486 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Support alternative (uncompressed) payload digest in packages (#880)
@dralley commented on this pull request.
> @@ -466,6 +483,13 @@ int rpmvsVerify(struct rpmvs_s *sis, int type,
int strength = (sinfo->type | sinfo->strength);
int required = 0;
+ /* Ignore failure if an alternative exists and verifies ok */
+ if (sinfo->rc == RPMRC_FAIL) {
+ const struct rpmsinfo_s * alt = getAlt(sis, sinfo);
+ if (alt && alt->rc == RPMRC_OK)
+ sinfo->rc = RPMRC_NOTFOUND;
+ }
Why do this, why not just verify all checksums? This feels prematurely
permissive and has the effect of potentially hiding bugs.
If you run `rpm -v --checksig` on an RPM with one incorrect checksum it will
tell you that digests are OK and just hide the one that isn't.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/880#pullrequestreview-1386655017
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
What's the background on the issue you are referring to here? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5616514 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM v6 package format, first public draft for commenting (Discussion #2374)
> except for the rpm magic, the lead will be zeros only I'm curious if we want to apply this even to the "major" file format version number in the lead? Of all the fields, that one seems like it could eventually have some potential use. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2374#discussioncomment-5562303 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM package invariants? (Discussion #2025)
> (*) Header tag data entries must be sorted. I'm unclear on what this means, do you mean 1) We cannot require tags to be sorted at parse time for compatibility reasons, or 2) There are certain tags which must be in certain positions in a sort-order violating way? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2025#discussioncomment-5558337 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update list of deprecated / obsolete RPM tags (Issue #2327)
`RPMTAG_CHANGELOG` doesn't seem to be used anywhere anymore, presumably replaced by the combo (`RPMTAG_CHANGELOGNAME`, `RPMTAG_CHANGELOGTIME`, `RPMTAG_CHANGELOGTEXT`) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2327#issuecomment-1496856058 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Update list of deprecated / obsolete RPM tags (Issue #2327)
Well, I did include "deprecated". I think that still applies? IMO if a tag is "stupid and pointless" and doesn't need to be written then it is effectively deprecated and should be documented as such, yes?. My main point is to just have it documented somewhere. There's also a bunch of tags which could be present in either header, but really ought to be in only one of the headers, and that's not very clearly documented right now either. i.e. `RPMSIGTAG_*` tag aliases which it seems shouldn't be used as such. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2327#issuecomment-1493218363 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
