[gentoo-dev] [PATCH data/xml-schema 2/2] metadata.xsd: Add freedestkop remote-id
Signed-off-by: Matt Turner --- metadata.xsd | 1 + 1 file changed, 1 insertion(+) diff --git a/metadata.xsd b/metadata.xsd index cced33d..a8a1467 100644 --- a/metadata.xsd +++ b/metadata.xsd @@ -281,6 +281,7 @@ + -- 2.35.1
[gentoo-dev] [PATCH data/xml-schema 1/2] metadata.xsd: Add gnome remote-id
Signed-off-by: Matt Turner --- metadata.xsd | 1 + 1 file changed, 1 insertion(+) diff --git a/metadata.xsd b/metadata.xsd index 87972cb..cced33d 100644 --- a/metadata.xsd +++ b/metadata.xsd @@ -279,6 +279,7 @@ + -- 2.35.1
[gentoo-dev] Last rites: app-portage/repoman
# Mike Gilbert (2022-09-12) # repoman is no longer maintained and has been removed from the portage # git repository. Please use dev-util/pkgcheck and dev-util/pkgdev instead. # Removal on 2022-11-11. Bug #835013. app-portage/repoman
[gentoo-dev] [PATCH v2 3/3] glep-0074: Specify compressed file formats
Signed-off-by: Michał Górny --- glep-0074.rst | 81 --- 1 file changed, 71 insertions(+), 10 deletions(-) diff --git a/glep-0074.rst b/glep-0074.rst index 9a0e92b..6523272 100644 --- a/glep-0074.rst +++ b/glep-0074.rst @@ -27,7 +27,8 @@ Changes === v1.3 - Formally specified the current set of hash algorithms supported. + Formally specified the current set of hash algorithms and compressed + Manifest formats supported. v1.2 Specified the newline convention used for Manifests. @@ -432,9 +433,8 @@ compression and this specification. The compressed Manifest files are required to be suffixed for their compression algorithm. This suffix should be used to recognize -the compression and decompress Manifests transparently. The exact list -of algorithms and their corresponding suffixes are outside the scope -of this specification. +the compression and decompress Manifests transparently. The supported +formats are specified in `compressed file formats`_ section. The top-level Manifest file must not be compressed. Since the OpenPGP signature covers the uncompressed text and is compressed itself, @@ -455,6 +455,46 @@ uncompressed content and the specification is free to choose either of the files using the same base name. +Compressed file formats +--- + +.. table:: Table 2. Defined compressed file formats + :widths: auto + + === == === + Tool nameSuffix Specification Notes + === == === + bzip2.bz2(none known) + gzip .gz RFC 1952 [#RFC1952]_ Recommended + lz4 .lz4(none known) + lzip .lz RFC draft [#LZIP]_ + lzma .lzma (none known) Deprecated + lzop .lzo(none known) + xz .xz xz [#XZ]_ + zstd .zstRFC 8878 [#RFC8878]_ + === == === + +Any new formats must be added to this specification prior to being used +for Manifest files. Adding a new compressed file format is considered +a backwards-compatible change to the GLEP. It is recommended that new +formats use their reference (most common) file suffixes. + +An implementation can implement an arbitrary subset of the listed +formats. For best interoperability, it should implement at least +the recommended formats. Using deprecated formats should be avoided. + +If multiple Manifest variants coexist using different compressed file +formats, the implementation may choose to use an arbitrary subset +of them. However, all of them must be verified against the hashes stored +in the containing Manifest. Should they be decompressed, the resulting +contents must be identical. + +If the compressed file format is unsupported and a variant using +a supported format coexists, the other variant should be used. However, +at least one supported variant must exist for the verification +to succeed. + + Combining multiple Manifest trees (informational) - @@ -996,12 +1036,19 @@ into a compressed sub-Manifest in the top directory (e.g. ``Manifest.sub.gz``), and including a ``MANIFEST`` entry for this file in a signed, uncompressed top-level Manifest. -The existence of additional entries for uncompressed Manifest checksums -was debated. However, plain entries for the uncompressed file would -be confusing if only the compressed file existed, and conflicting -if both uncompressed and compressed variants existed. Furthermore, -it has been pointed out that ``DIST`` entries do not have -an uncompressed variant either. +The existence of additional entries for checksums of Manifest contents +after uncompressing was debated. However, plain entries for +the uncompressed file would be confusing if only the compressed file +existed. Furthermore, it has been pointed out that ``DIST`` entries +do not have an uncompressed variant either. + +The specification permits coexistence of multiple variants of the same +Manifest file using different compression for historical compatibility. +However, there does not seem to be any real benefit from including +a compressed Manifest file if the uncompressed variant needs to exist +anyway. Providing different compressed variants could technically +improve interoperability, though the same result could probably +be achieved by using a more commonly supported format (e.g. gzip). Performance considerations @@ -1134,6 +1181,20 @@ References (archived at 2017-11-29) (https://web.archive.org/web/20171129084214/http://www.larc.usp.br/~pbarreto/WhirlpoolPage.html) +.. [#RFC1952] RFC 1952: GZIP file format specification version 4.3 + (https://www.rfc-editor.org/rfc/rfc1952) + +.. [#LZIP] RFC draft: Lzip Compressed Format and the 'application/lzip' + Media Type + (https://datatracker.ietf.org/doc/html/draft-diaz-lzip) + +.. [#XZ] The .xz
[gentoo-dev] [PATCH v2 2/3] glep-0074: Specify supported hash algorithms
Replace the informational hash name section with a formal specification of allowed hash algorithms. The original reasoning for leaving them implementation-defined was poor. After all, not a single new hash was added since the initial version of the GLEP. At the same time, ensuring consistent support for at least a minimal set of hash algorithms is crucial to interoperability. Given that the effort needed to update the GLEP is relatively small, it is better to require all algorithms to be formally listed than to have to track all implementations for new hashes and hope for consistency. Signed-off-by: Michał Górny --- glep-0074.rst | 136 -- 1 file changed, 88 insertions(+), 48 deletions(-) diff --git a/glep-0074.rst b/glep-0074.rst index 8cec618..9a0e92b 100644 --- a/glep-0074.rst +++ b/glep-0074.rst @@ -6,7 +6,7 @@ Author: Michał Górny , Ulrich Müller Type: Standards Track Status: Final -Version: 1.2 +Version: 1.3 Created: 2017-10-21 Last-Modified: 2022-09-11 Post-History: 2017-10-26, 2017-11-16, 2018-02-08, 2022-09-08, 2022-09-11 @@ -26,6 +26,9 @@ efficient and provide means of backwards compatibility. Changes === +v1.3 + Formally specified the current set of hash algorithms supported. + v1.2 Specified the newline convention used for Manifests. @@ -364,27 +367,60 @@ up to and including the *original* directory. Note that those sub-Manifests can use different filenames than ``Manifest``. -Checksum algorithms (informational) - -This section is informational only. Specifying the exact set -of supported algorithms is outside the scope of this specification. - -The algorithm names reserved at the time of writing are: - -- ``MD5`` [#MD5]_, -- ``RMD160`` -- RIPEMD-160 [#RIPEMD160]_, -- ``SHA1`` [#SHS]_, -- ``SHA256`` and ``SHA512`` -- SHA-2 family of hashes [#SHS]_, -- ``WHIRLPOOL`` [#WHIRLPOOL]_, -- ``BLAKE2B`` and ``BLAKE2S`` -- BLAKE2 family of hashes [#BLAKE2]_, -- ``SHA3_256`` and ``SHA3_512`` -- SHA-3 family of hashes [#SHA3]_, -- ``STREEBOG256`` and ``STREEBOG512`` -- Streebog family of hashes - [#STREEBOG]_. - -The method of introducing new hashes is defined by GLEP 59 [#GLEP59]_. -It is recommended that any new hashes are named after the Python -``hashlib`` module algorithm names, transformed into uppercase. +Checksum algorithms +--- + +.. table:: Table 1. Defined hash algorithms + :widths: auto + + +-+---+--+--+-+ + | Name| Specification | Bits | Enc. | Notes | + +=+===+==+==+=+ + | ``BLAKE2B`` | | 512 | Hex | Recommended | + +-+ RFC 7693 [#RFC7693]_ +--+--+-+ + | ``BLAKE2S`` | | 256 | Hex | | + +-+---+--+--+-+ + | ``MD5`` | RFC 1321 [#RFC1321]_ | 128 | Hex | Deprecated | + +-+---+--+--+-+ + | ``RMD160`` | RIPEMD-160 [#RMD160]_ | 160 | Hex | Deprecated | + +-+---+--+--+-+ + | ``SHA1``| | 160 | Hex | Deprecated | + +-+ +--+--+-+ + | ``SHA256`` | FIPS 180-4 [#SHS]_| 256 | Hex | | + +-+ +--+--+-+ + | ``SHA512`` | | 512 | Hex | Recommended | + +-+---+--+--+-+ + | ``SHA3_256``| | 256 | Hex | | + +-+ FIPS 202 [#SHA3]_ +--+--+-+ + | ``SHA3_512``| | 512 | Hex | | + +-+---+--+--+-+ + | ``STREEBOG256`` | | 256 | Hex | | + +-+ RFC 6986 [#RFC6986]_ +--+--+-+ + | ``STREEBOG512`` | | 512 | Hex | | + +-+---+--+--+-+ + | ``WHIRLPOOL`` | Whirlpool [#BARRETO]_ | 512 | Hex | | + +-+---+--+--+-+ + +Any new hashes must be added to this specification prior to being used +in Manifest files. Adding a new hash is considered +a backwards-compatible change to the GLEP. It is recommended that new +hashes are named after the Python ``hashlib`` module algorithm names, +transformed into uppercase, with dashes replaced by underscores. + +An implementation can implement an arbitrary subset of the listed +hashes. For best interoperability, it should
[gentoo-dev] [PATCH v2 1/3] glep-0074: Add a changelog
Signed-off-by: Michał Górny --- glep-0074.rst | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/glep-0074.rst b/glep-0074.rst index 182a871..8cec618 100644 --- a/glep-0074.rst +++ b/glep-0074.rst @@ -8,8 +8,8 @@ Type: Standards Track Status: Final Version: 1.2 Created: 2017-10-21 -Last-Modified: 2022-09-08 -Post-History: 2017-10-26, 2017-11-16, 2018-02-08, 2022-09-08 +Last-Modified: 2022-09-11 +Post-History: 2017-10-26, 2017-11-16, 2018-02-08, 2022-09-08, 2022-09-11 Content-Type: text/x-rst Requires: 59, 61 Replaces: 44, 58, 60 @@ -23,6 +23,17 @@ integrity and authenticity checks. The format aims to be future-proof, efficient and provide means of backwards compatibility. +Changes +=== + +v1.2 + Specified the newline convention used for Manifests. + +v1.1 + Removed the restriction that all files covered by a Manifest tree + must reside on the same filesystem. + + Motivation == -- 2.37.3
[gentoo-dev] [PATCH v2 0/3] glep-0074: Explicitly specify hashes and compressed Manifest formats
Hi, Here's v2 of the patches. Change from v1: removed explicit Bootstrap table classes (they don't really belong in GLEPs) in favor of fixed table rendering in docutils-glep 1.5 / matching www.g.o update. Use rowspan="" instead of "ditto"s for hashes using the same spec. Michał Górny (3): glep-0074: Add a changelog glep-0074: Specify supported hash algorithms glep-0074: Specify compressed file formats glep-0074.rst | 230 +- 1 file changed, 171 insertions(+), 59 deletions(-) -- 2.37.3
Re: [gentoo-dev] [PATCH 2/3] glep-0074: Specify supported hash algorithms
On Mon, 2022-09-12 at 10:28 +0200, Florian Schmaus wrote: > On 11/09/2022 15.14, Michał Górny wrote: > > +.. table:: Table 1. Defined hash algorithms > > + :widths: auto > > + :class: table table-bordered table-striped > > + > > + === === === > > + NameSpecification Bits Enc. Notes > > + === === === > > + ``BLAKE2B`` RFC 7693 [#RFC7693]_512 Hex Recommended > > + ``BLAKE2S`` ditto 256 Hex > > + ``MD5`` RFC 1321 [#RFC1321]_128 Hex Deprecated > > + ``RMD160`` RIPEMD-160 [#RMD160]_ 160 Hex Deprecated > > + ``SHA1``FIPS 180-4 [#SHS]_ 160 Hex Deprecated > > + ``SHA256`` ditto 256 Hex > > + ``SHA512`` ditto 512 Hex Recommended > > + ``SHA3_256``FIPS 202 [#SHA3]_ 256 Hex > > + ``SHA3_512``ditto 512 Hex > > + ``STREEBOG256`` RFC 6986 [#RFC6986]_256 Hex > > + ``STREEBOG512`` ditto 512 Hex > > + ``WHIRLPOOL`` Whirlpool [#WHIRLPOOL]_ 512 Hex > > + === === === > > Personally, I would slightly prefer repeating the source specification, > instead of using "ditto". > Unfortunately, that would mean each of them would have 2-3 backreferences in the 'References' section. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH 2/3] glep-0074: Specify supported hash algorithms
On 11/09/2022 15.14, Michał Górny wrote: +.. table:: Table 1. Defined hash algorithms + :widths: auto + :class: table table-bordered table-striped + + === === === + NameSpecification Bits Enc. Notes + === === === + ``BLAKE2B`` RFC 7693 [#RFC7693]_512 Hex Recommended + ``BLAKE2S`` ditto 256 Hex + ``MD5`` RFC 1321 [#RFC1321]_128 Hex Deprecated + ``RMD160`` RIPEMD-160 [#RMD160]_ 160 Hex Deprecated + ``SHA1``FIPS 180-4 [#SHS]_ 160 Hex Deprecated + ``SHA256`` ditto 256 Hex + ``SHA512`` ditto 512 Hex Recommended + ``SHA3_256``FIPS 202 [#SHA3]_ 256 Hex + ``SHA3_512``ditto 512 Hex + ``STREEBOG256`` RFC 6986 [#RFC6986]_256 Hex + ``STREEBOG512`` ditto 512 Hex + ``WHIRLPOOL`` Whirlpool [#WHIRLPOOL]_ 512 Hex + === === === Personally, I would slightly prefer repeating the source specification, instead of using "ditto". - Flow OpenPGP_0x8CAC2A9678548E35.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
