Your message dated Sun, 08 Feb 2026 09:46:09 -0800
with message-id <[email protected]>
and subject line Re: Bug#1057057: debian-policy: Please make Checksums-Sha1
optional
has caused the Debian Bug report #1057057,
regarding debian-policy: Please make Checksums-Sha1 optional
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1057057: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057057
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: debian-policy
Version: 4.6.2.0
Severity: wishlist
Tags: patch
Dear Maintainer,
SHA1 is an obsolete checksum method. For example NIST recommends to
phase out all usage of SHA1 by 2030. Currently it is generated in .dsc
and .changes files and validated. It does not bring any additional
security measures over SHA256 that is already present. Unlike
Files/Md5 it is in fact optional and is trivial to drop.
Please consider making Checksums-Sha1 optional in .dsc and .changes.
All basic tooling handles lack of Checksums-Sha1 gracefully, as they
are already not treated as trusted.
Launchpad accepts uploads without Checksums-Sha1.
Dak currently requires Checksums-Sha1, but I am happy to facilitate in
patching dak to make Checksums-Sha1 optional if this bug report is
accepted.
I have not checked other tools like Open Build Service, Artifactory,
etc.
Example files:
https://ppa.launchpadcontent.net/yolo4k/kernels/ubuntu/pool/main/h/hello/hello_2.10-2ubuntu5.dsc
https://launchpadlibrarian.net/699972411/hello_2.10-2ubuntu5_source.changes
Regards,
Dimitri.
>From 95a090af0ced9c04a79da7c006655388fd41a188 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov <[email protected]>
Date: Tue, 28 Nov 2023 17:00:20 +0000
Subject: [PATCH] policy: Make Checksums-Sha1 optional
Make Checksums-Sha1 optional as it is redundant compared to Sha256,
and Sha1 usage should be phased out by 2030. Making Checksums-Sha1
optional is relatively easy and backwards compatible with many
tools. dak will require a change to allow uploads without
Checksums-Sha1, prior to releasing policy & dpkg update.
Signed-off-by: Dimitri John Ledkov <[email protected]>
---
policy/ch-controlfields.rst | 19 +++++++++++--------
policy/upgrading-checklist.rst | 9 +++++++++
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 2871658f57..d125994b0b 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -243,8 +243,9 @@ is described above, in :ref:`s-controlsyntax`.
- :ref:`Package-List <s-f-Package-List>` (recommended)
-- :ref:`Checksums-Sha1 and Checksums-Sha256 <s-f-Checksums>`
- (mandatory)
+- :ref:`Checksums-Sha1 <s-f-Checksums>` (optional)
+
+- :ref:`Checksums-Sha256 <s-f-Checksums>` (mandatory)
- :ref:`Files <s-f-Files>` (mandatory)
@@ -297,8 +298,9 @@ The fields in this file are:
- :ref:`Changes <s-f-Changes>` (mandatory)
-- :ref:`Checksums-Sha1 and Checksums-Sha256 <s-f-Checksums>`
- (mandatory)
+- :ref:`Checksums-Sha1 <s-f-Checksums>` (optional)
+
+- :ref:`Checksums-Sha256 <s-f-Checksums>` (mandatory)
- :ref:`Files <s-f-Files>` (mandatory)
@@ -1026,10 +1028,11 @@ such as ``<>``.
``Checksums-Sha1`` and ``Checksums-Sha256``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-These multiline fields contain a list of files with a checksum and size
-for each one. Both ``Checksums-Sha1`` and ``Checksums-Sha256`` have the
-same syntax and differ only in the checksum algorithm used: SHA-1 for
-``Checksums-Sha1`` and SHA-256 for ``Checksums-Sha256``.
+These multiline fields contain a list of files with a checksum and
+size for each one. Both ``Checksums-Sha1`` (optional) and
+``Checksums-Sha256`` (mandatory) have the same syntax and differ only
+in the checksum algorithm used: SHA-1 for ``Checksums-Sha1`` and
+SHA-256 for ``Checksums-Sha256``.
``Checksums-Sha1`` and ``Checksums-Sha256`` are multiline fields. The
first line of the field value (the part on the same line as
diff --git a/policy/upgrading-checklist.rst b/policy/upgrading-checklist.rst
index c772b7e178..4cb37cf624 100644
--- a/policy/upgrading-checklist.rst
+++ b/policy/upgrading-checklist.rst
@@ -39,6 +39,15 @@ The sections in this checklist match the values for the
except in the two anomalous historical cases where normative
requirements were changed in a minor patch release.
+Version 4.6.3
+-------------
+
+UNRELEASED
+
+
+5.4 & 5.5
+ Checksums-Sha1 are now optional.
+
Version 4.6.2
-------------
--
2.34.1
--- End Message ---
--- Begin Message ---
Dimitri John Ledkov <[email protected]> writes:
> SHA1 is an obsolete checksum method. For example NIST recommends to
> phase out all usage of SHA1 by 2030. Currently it is generated in .dsc
> and .changes files and validated. It does not bring any additional
> security measures over SHA256 that is already present. Unlike Files/Md5
> it is in fact optional and is trivial to drop.
> Please consider making Checksums-Sha1 optional in .dsc and .changes.
> All basic tooling handles lack of Checksums-Sha1 gracefully, as they
> are already not treated as trusted.
> Launchpad accepts uploads without Checksums-Sha1.
> Dak currently requires Checksums-Sha1, but I am happy to facilitate in
> patching dak to make Checksums-Sha1 optional if this bug report is
> accepted.
Per the discussion when this bug was opened in 2023, Policy here is
downstream of DAK (and potentially other archive software such as
snapshot.debian.org). I have no objections to making the fields optional,
but that change has to happen in at least the services that consume the
fields first or it would be misleading to tell Policy readers that they
could be omitted.
I'm therefore closing this as wontfix, but not because I have any
objections to the work, only because of the ordering constraint. As soon
as DAK and other archive software treats the fields as optional, please
open a new Policy bug and we can coordinate with Guillem on how to express
that.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
--- End Message ---
