<div dir="ltr"><div>Well, just because it's documented does not mean it's true. Seems like the wiki is expressing a dream then.</div><div>Thank you for sharing your experience. </div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 11, 2021 at 9:44 AM Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Mar 11, 2021 at 3:31 AM Matthias Dellweg <<a href="mailto:mdellweg@redhat.com" target="_blank">mdellweg@redhat.com</a>> wrote: > > > > On Thu, Mar 11, 2021 at 9:13 AM Neal Gompa <<a href="mailto:ngompa13@gmail.com" target="_blank">ngompa13@gmail.com</a>> wrote: >> >> On Wed, Mar 10, 2021 at 10:20 PM Brian Bouterse <<a href="mailto:bmbouter@redhat.com" target="_blank">bmbouter@redhat.com</a>> wrote: >> > >> > 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. >> > >> > On Wed, Mar 10, 2021 at 11:40 AM Quirin Pamp <<a href="mailto:pamp@atix.de" target="_blank">pamp@atix.de</a>> wrote: >> >> >> >> 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. >> > >> > 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. >> > >> > 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. >> >> There is one difference between the RPM ecosystem and the Debian >> ecosystem here. APT will absolutely choke on a repository if MD5 is >> missing, even if it won't use it for "integrity". Various aspects of the Debian >> ecosystem still use MD5 because it's the only guaranteed algorithm. >> >> Two major points where it's still mandatory: >> >> * Debian Source Control files and repodata generated for "sources". >> The dsc file (ex. rpm[1]) uses MD5 for *file list*, and that's *not* >> optional. There *are* extra Checksums sections that you're supposed to >> use for integrity verification, but they are technically optional, and >> the only *guaranteed* algorithm is MD5, which is used for the Files >> section. >> >> * Debian InRelease and other repodata index files. The InRelease file >> (ex. Ubuntu 20.04[2]) *guarantees* MD5Sums (note capital "S") for the >> file list, and while the current advice is that clients *must* also >> request a SHA2 algorithm to verify the integrity of the files, the >> first section using MD5 *must* be present or the repodata is invalid. >> >> The repository format wiki page[3] somewhat details this (though being >> a wiki page, it's as inconsistent as any other wiki page, yay?). > > > 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). > > Servers shall provide the InRelease file, and might provide a Release files and its signed counterparts with at least the following keys: > > Suite and/or Codename > Architectures > Components > Date > SHA256 > > Still having a unsigned Release file and MD5Sum is currently highly recommended. Unsigned Release is probably the only truly optional part (and that's needed for pre-2016 APT versions), but in practice, I haven't been able to leave out MD5Sum from APT repository metadata without breaking clients. Admittedly, I haven't tried recently (as in not in the last couple of years, the last time I tried was in the Ubuntu 17.04 timeframe). -- 真実はいつも一つ！/ Always, there's only one truth! </blockquote></div>