[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] dpkg-scanpackages: Add sha512 support



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;"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


Reply to: