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
Re: [Rpm-maint] [rpm-software-management/rpm] Create Issue templates for Bug reports and RFEs (PR #2823)
@Conan-Kudo commented on this pull request. > @@ -0,0 +1,22 @@ +--- +name: Feature request +about: Suggest an idea for this project +title: '' +labels: RFE +assignees: '' + +--- + +If your feature need figuring out how to implement it or needs feedback from the wider comunity, please open a [Discussion](https://github.com/rpm-software-management/rpm/discussions) instead. If the discussion has solidified into a plan of action it is time to create an issue for actually implementing it. I don't think that's necessary, since Issues can be converted into Discussions and back. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2823#discussion_r1443692028 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
