• [PATCH] dpkg-scanpackages: Add sha512 support

    From sweetyfish@deepin.org@21:1/5 to All on Wed May 31 10:50:01 2023
    From: 李成刚 <lichenggang@uniontech.com>

    ---
    man/dpkg-scanpackages.pod | 2 +-
    man/po/de.po | 2 +-
    man/po/dpkg-man.pot | 2 +-
    man/po/es.po | 2 +-
    man/po/fr.po | 2 +-
    man/po/hu.po | 2 +-
    man/po/it.po | 2 +-
    man/po/ja.po | 2 +-
    man/po/nl.po | 2 +-
    man/po/pl.po | 2 +-
    man/po/pt.po | 2 +-
    man/po/pt_BR.po | 2 +-
    man/po/ru.po | 2 +-
    man/po/sv.po | 2 +-
    man/po/zh_CN.po | 2 +-
    scripts/Dpkg/Checksums.pm | 6 ++++++
    script
  • From Guillem Jover@21:1/5 to sweetyfish@deepin.org on Wed May 31 23:40:01 2023
    Hi!

    On Wed, 2023-05-31 at 16:15:32 +0800, sweetyfish@deepin.org wrote:
    From: 李成刚 <lichenggang@uniontech.com>

    Thanks for the patch! Although I've had this implemented with <https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=pu/sha-512&id=4df34f697309a816f6e137f13296270ea84ed938>
    for some time. The problem is that this would require first checking
    that consumers can cope with the new field, and do not reject files
    containing them (.dsc, .buildinfo, .changes, Packages, Sources, etc).
    Then at least in Debian checking whether the added fields incur too
    much bloat, for the potential security benefit they might bring.
    (Offsetting this by removing fields would probably imply having to
    bump the format versions for various of the involved files containing
    these removed files.)

    I'd be interested to know the motivation for this submission, and
    depending on the reasoning perhaps I could modify the original patch
    and make the support available but disabled by default. Also I've for
    long been unsatisfied that the available support implies automatic
    addition to all supported file formats, so I might also end up
    untangling them.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to All on Thu Jun 1 19:10:01 2023
    Hi!

    (I assume this didn't reach the mailing list as it was trapped in some
    spam filter, probably best to disable HTML format. Also rearranged the
    mail to avoid the top-posting. :)

    ------------------&nbsp;原始邮件&nbsp;------------------ 发件人:&nbsp;"Guillem&nbsp;Jover"<guillem@debian.org&gt;; 发送时间:&nbsp;2023年6月1日(星期四) 凌晨5:33 收件人:&nbsp;"sweetyfish"<sweetyfish@deepin.org&gt;; 抄送:&nbsp;"debian-dpkg"<debian-dpkg@lists.debian.org&gt;; "lichenggang"<lichenggang@uniontech.com&gt;;
    主题:&nbsp;Re: [PATCH] dpkg-scanpackages: Add sha512 support

    Thanks for the patch! Although I've had this implemented with <https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=pu/sha-512&amp;id=4df34f697309a816f6e137f13296270ea84ed938&gt;
    for some time. The problem is that this would require first checking
    that consumers can cope with the new field, and do not reject files containing them (.dsc, .buildinfo, .changes, Packages, Sources, etc).
    Then at least in Debian checking whether the added fields incur too
    much bloat, for the potential security benefit they might bring.
    (Offsetting this by removing fields would probably imply having to
    bump the format versions for various of the involved files containing
    these removed files.)

    I'd be interested to know the motivation for this submission, and
    depending on the reasoning perhaps I could modify the original patch
    and make the support available but disabled by default. Also I've for
    long been unsatisfied that the available support implies automatic
    addition to all supported file formats, so I might also end up
    untangling them.

    On Thu, 2023-06-01 at 09:27:09 +0800, 李成刚 wrote:
    Thank you very much for your work, we use obs
    (https://openbuildservice.org/) to build the platform, obs uses dpkg-scanpackages to generate warehouses, dpkg-scanpackages does
    not support sha512, and there are some wrong behaviors when mixed
    with our other warehouses

    As discussed on IRC with sweetyfish, it looks like apt and Ubuntu's
    archive software (via Launchpad.net) at least support SHA512 hashes.
    I see reprepro gained support for them last year. So I assume things
    in general would not break. But if you are seeing breakage somewhere
    that's worth investigating as these should be optional fields that
    would in general only cause failures if they are missing and there are
    only weak ones present.

    As mentioned above, and on IRC, adding support for this
    unconditionally would require checking whether DAK (the Debian Archive
    Kit software that manages the Debian archive) does not reject uploads
    using those hashes, and if so adding support for them, and then for
    Debian a discussion would be needed to see whether the potential bloat
    is worth it.

    If you manage to find the reason for your issues, and that requires
    adding these hashes, then I could see adding support for conditionally
    enabling them, but that might end up not being a trivial change, as
    this would need to be passed down from dpkg-buildpackage to dpkg-source
    and dpkg-genbuildinfo for example, although not an insurmountable one.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to Guillem Jover on Fri Jun 2 10:00:01 2023
    Hi!

    On Thu, 2023-06-01 at 19:06:34 +0200, Guillem Jover wrote:
    ------------------&nbsp;原始邮件&nbsp;------------------ 发件人:&nbsp;"Guillem&nbsp;Jover"<guillem@debian.org&gt;; 发送时间:&nbsp;2023年6月1日(星期四) 凌晨5:33 收件人:&nbsp;"sweetyfish"<sweetyfish@deepin.org&gt;; 抄送:&nbsp;"debian-dpkg"<debian-dpkg@lists.debian.org&gt;; "lichenggang"<lichenggang@uniontech.com&gt;;
    主题:&nbsp;Re: [PATCH] dpkg-scanpackages: Add sha512 support

    Thanks for the patch! Although I've had this implemented with <https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=pu/sha-512&amp;id=4df34f697309a816f6e137f13296270ea84ed938&gt;
    for some time. The problem is that this would require first checking
    that consumers can cope with the new field, and do not reject files containing them (.dsc, .buildinfo, .changes, Packages, Sources, etc).
    Then at least in Debian checking whether the added fields incur too
    much bloat, for the potential security benefit they might bring. (Offsetting this by removing fields would probably imply having to
    bump the format versions for various of the involved files containing
    these removed files.)

    On Thu, 2023-06-01 at 09:27:09 +0800, 李成刚 wrote:
    Thank you very much for your work, we use obs (https://openbuildservice.org/) to build the platform, obs uses dpkg-scanpackages to generate warehouses, dpkg-scanpackages does
    not support sha512, and there are some wrong behaviors when mixed
    with our other warehouses

    As discussed on IRC with sweetyfish, it looks like apt and Ubuntu's
    archive software (via Launchpad.net) at least support SHA512 hashes.
    I see reprepro gained support for them last year. So I assume things
    in general would not break. But if you are seeing breakage somewhere
    that's worth investigating as these should be optional fields that
    would in general only cause failures if they are missing and there are
    only weak ones present.

    As mentioned above, and on IRC, adding support for this
    unconditionally would require checking whether DAK (the Debian Archive
    Kit software that manages the Debian archive) does not reject uploads
    using those hashes, and if so adding support for them, and then for
    Debian a discussion would be needed to see whether the potential bloat
    is worth it.

    This has been discussed in the past and there didn't seem much
    enthusiasm at the time, but then that was 10 years ago:

    https://lists.debian.org/debian-devel/2012/10/msg00159.html
    https://lists.debian.org/debian-devel/2013/08/msg00033.html

    For reference there's also this draft spec that is relevant here:

    https://wiki.debian.org/Teams/Dpkg/Spec/ChangesFormat2.0

    If you manage to find the reason for your issues, and that requires
    adding these hashes, then I could see adding support for conditionally enabling them, but that might end up not being a trivial change, as
    this would need to be passed down from dpkg-buildpackage to dpkg-source
    and dpkg-genbuildinfo for example, although not an insurmountable one.

    After discussion this further on IRC, AFAIUI this was just a request
    to add the support simply to use it, apparently nothing was breaking,
    I just got that impression from the original mail.

    In any case I started to look into untangling this yesterday, and have
    some code which would be targeted at 1.22.x.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)