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
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. > ## 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 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. > + +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. 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. > ``` 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. 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 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)
@jobol 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 IMHO The trail space is expected in that particular case -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1808238410 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 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)
@pmatilai 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 This does not describe v4 file format, so we should not bump the number either. For v4, the by far most important item is the immutable region and that is not even mentioned anywhere here. Not surprising since most of the content is from the initial commit in 1996 (cdd4c29192131e1b6a3369b10f324928336a63da) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445773446 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)
@pmatilai 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'd not touch the wrapping because it makes it difficult to see the actual content change. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445775312 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)
@pmatilai 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. No wonder, the arch translations have been in the declarative rpmrc config file for over twenty years. This is one of the docs thats *so old* it makes you wonder if its worth trying to patch it up... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445778572 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)
@pmatilai commented on this pull request. > -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 Rpm doesn't look at the lead except for the magic, so it's totally irrelevant. Even rpm v3 only supported header-style signatures IIRC. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445781579 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)
@pmatilai commented on this pull request. > +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 +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 It's not a historical artifact in the context of package format, there exists mountains of DSA signed rpm v4 content. That the algorithm is now obsolete is of little consequence when we're describing a format with a timespan of > 15 years. But yes, EdDSA and DSA share the same tag. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1810658045 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)
@pmatilai commented on this pull request. > Tag Name | Value| Type | Description --|--|--| -Dsaheader | 267 | bin | OpenPGP DSA signature of the header (if thus signed) -Longsigsize | 270 | int64| Header+payload size if > 4GB. +Dsaheader | 267 | bin | OpenPGP EdDSA signature of the header (if thus signed) This needs to be "DSA or EdDSA" really, EdDSA is a *very* new addition in the v4 timescale. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1810668237 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)
@pmatilai commented on this pull request. > @@ -435,7 +435,7 @@ typedef enum rpmSigTag_e { RPMSIGTAG_RESERVEDSPACE = 1008,/*!< internal space reserved for signatures */ RPMSIGTAG_BADSHA1_1= RPMTAG_BADSHA1_1, /*!< internal Broken SHA1, take 1. */ RPMSIGTAG_BADSHA1_2= RPMTAG_BADSHA1_2, /*!< internal Broken SHA1, take 2. */ -RPMSIGTAG_DSA = RPMTAG_DSAHEADER, /*!< internal DSA header signature. */ +RPMSIGTAG_DSA = RPMTAG_DSAHEADER, /*!< internal EdDSA header signature. */ Ditto here, DSA or EdDSA. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1810668926 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)
@pmatilai commented on this pull request. > +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. Possible? Technically yes but it doesn't make it any more right or any easier for the user, only more confusing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1445797752 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] 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 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 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 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 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)
@pmatilai 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 There's lots in the hregion text that fits neither the style or content otherwise (like lack of technical detail), but it's a start. Documenting the details is going to be quite a bit of work that I need to do anyhow sooner than later. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#discussion_r1447153959 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)
@pmatilai commented on this pull request. > @@ -24,16 +24,19 @@ package file is divided in 4 logical sections: ``` All 2 and 4 byte "integer" quantities (int16 and int32) are stored in Sorry, forgot to mention this yesterday: we also have 64bit integers where this also applies. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#pullrequestreview-1812853018 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] 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)
The more I looked at this and the existing docs, the more clear it became that the stuff needs more than a touch-up job to be credible. I ended up rewriting much of bit of it, updating and preserving the v3 docs too for historians and the like: #2861. That was quite the pile to chew out in a day, so there will be gaps and mistakes and all but I think it's now a more solid place to build on now. After that churn, this PR wont be anywhere near applicable, but. There's good stuff in this PR and I initially tried to pull as much content from this PR as possible but got nowhere with that approach, because the initial state is what it is. I'll go through this once more once the dust settles to double-check what additions I missed and apply manually. Thanks for the patch and initiative to get this updated! Getting v4 documented was one of my goals for last year and this PR was apparently the necessary kick to get started :smile: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1900542163 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] 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] Update format documentation in the manual (PR #2835)
I'm not actually finished with this, but I do have a local backup anyway, closing is okay. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2835#issuecomment-1905561075 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