<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 9:13 AM Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 10, 2021 at 10:20 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote:<br>
><br>
> Thanks Quirin for the questions. I put my understanding and recommendations inline. Other devs please share your perspectives and advice, especially if they differ from what is written here. More questions and discussion are welcome. This is complicated stuff, but we want to be here to help.<br>
><br>
> On Wed, Mar 10, 2021 at 11:40 AM Quirin Pamp <<a href="mailto:pamp@atix.de" target="_blank">pamp@atix.de</a>> wrote:<br>
>><br>
>> To summarize: I am uncertain how best to proceed, but perhaps I am overthinking this and simply respecting ALLOWED_CONTENT_CHECKSUMS and letting users decide is best.<br>
><br>
> The question I'll ask to help answer yours is: how much does pulp_deb break with 3.11's defaults? This would be good to know. Want to run a few tests and let us know? Maybe we can help give more info with that.<br>
><br>
> Aside from that, my general advice is to expect that pulp_deb users will change this setting, and to have the pulp_deb code work with the checksums it has available and error when it cannot fulfill their request due to not having the checksums it would need to do so.<br>
<br>
There is one difference between the RPM ecosystem and the Debian<br>
ecosystem here. APT will absolutely choke on a repository if MD5 is<br>
missing, even if it won't use it for "integrity". Various aspects of the Debian<br>
ecosystem still use MD5 because it's the only guaranteed algorithm.<br>
<br>
Two major points where it's still mandatory:<br>
<br>
* Debian Source Control files and repodata generated for "sources".<br>
The dsc file (ex. rpm[1]) uses MD5 for *file list*, and that's *not*<br>
optional. There *are* extra Checksums sections that you're supposed to<br>
use for integrity verification, but they are technically optional, and<br>
the only *guaranteed* algorithm is MD5, which is used for the Files<br>
section.<br>
<br>
* Debian InRelease and other repodata index files. The InRelease file<br>
(ex. Ubuntu 20.04[2]) *guarantees* MD5Sums (note capital "S") for the<br>
file list, and while the current advice is that clients *must* also<br>
request a SHA2 algorithm to verify the integrity of the files, the<br>
first section using MD5 *must* be present or the repodata is invalid.<br>
<br>
The repository format wiki page[3] somewhat details this (though being<br>
a wiki page, it's as inconsistent as any other wiki page, yay?).<br></blockquote><div><br></div><div>Reading this section from the Wiki page you mention, I understand that everything but SHA256 is indeed optional in the Release file (and i assume the InRelease file too).<br></div><div><p class="gmail-line862"><i>Servers shall provide the InRelease file, and might 
provide a Release files and its signed counterparts with at least the 
following keys: <span class="gmail-anchor" id="gmail-line-122"></span><span class="gmail-anchor" id="gmail-line-123"></span></i></p><ul><li><i>Suite and/or Codename <span class="gmail-anchor" id="gmail-line-124"></span></i></li><li><i>Architectures <span class="gmail-anchor" id="gmail-line-125"></span></i></li><li><i>Components <span class="gmail-anchor" id="gmail-line-126"></span></i></li><li><i>Date <span class="gmail-anchor" id="gmail-line-127"></span></i></li><li><i>SHA256 <span class="gmail-anchor" id="gmail-line-128"></span><span class="gmail-anchor" id="gmail-line-129"></span></i></li></ul><p class="gmail-line874"><i>Still having a unsigned Release file and MD5Sum is currently highly recommended. </i></p></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Probably the correct thing to do here is to make it possible to<br>
propagate the correct error information up so that users can be<br>
informed about missing algorithms and *why* so they can enable it. And<br>
if any installer is going to do Pulp with Debian, they also can't ask<br>
for weak algorithms to be disabled.<br>
<br>
[1]: <a href="http://archive.ubuntu.com/ubuntu/pool/universe/r/rpm/rpm_4.14.2.1+dfsg1-1build2.dsc" rel="noreferrer" target="_blank">http://archive.ubuntu.com/ubuntu/pool/universe/r/rpm/rpm_4.14.2.1+dfsg1-1build2.dsc</a><br>
[2]: <a href="http://archive.ubuntu.com/ubuntu/dists/focal/InRelease" rel="noreferrer" target="_blank">http://archive.ubuntu.com/ubuntu/dists/focal/InRelease</a><br>
[3]: <a href="https://wiki.debian.org/DebianRepository/Format" rel="noreferrer" target="_blank">https://wiki.debian.org/DebianRepository/Format</a><br>
<br>
<br>
<br>
--<br>
真実はいつも一つ!/ Always, there's only one truth!<br>
<br>
<br>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://listman.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://listman.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div></div>