Hi! On Tue, 2017-05-23 at 18:17:18 +0100, Sean Whitton wrote: > (1) > > I am teaching dgit to verify whether a .changes file is source-only. > This is for a new 'push-source' subcommand.
Ah, interesting question. :) IMO, in theory, a source-only .changes is primarily defined by its Architecture field containing only "source" as value. As a consequence of only containing references to a .dsc and any further file referenced within. Even though this might seem backwards, my reasoning is that the Architecture field values are extremely well defined, while going based on filenames requires extension scrapping, which while also well defined always seems a bit icky to me. Of course, in practice, if going just by the Architecture field, you need to trust that the software generating the .changes (and the .dsc) is not buggy, and the entity that commissioned its creation is not trying to bypass the checks. But for BY-HAND artifacts that do not follow the well defined name_version_arch.type filename form, then this will not be represented in the Architecture field, which is something that should probably be fixed by annotating the field with some value (probably the host architecture to be conservative). Also, even though I could imagine someone injecting non-source artifacts from within the debian/rules clean target even for source only builds, I'd consider that to be just broken. But, if your intention is to verify the .changes file, you might as well perform more extensive sanity checks to be extra sure. > My first attempt simply looked for any .deb or .udeb entries in the > Files: field. However, dgit's maintainer would prefer a strict > whitelist: check that each entry in Files: is a .dsc, or an .orig.tar.*, > or a .debian.tar.*, etc. > Is this the preferred way to confirm whether a .changes file is > source-only? Yeah, the former would miss .ddebs (used only on Ubuntu and derivatives), the old proposed .tdebs (although I don't think this got much buy-in), or probably other custom Package-Type(s). It would also miss BY-HAND artifacts, as injected by dpkg-distaddfile. For source-only, I think going by a whitelist is indeed more sensible, but I'd just check whether there is a .dsc, and whether the rest of the references in the .changes are just the files referenced in the .dsc. > (2) > > We are also thinking about a strict whitelist for all .changes files -- > the whitelist mentioned above, plus *.deb, *.udeb etc. > > Are there currently any plans to add new categories of binary files to > uploads, that we should include in our whitelist? As mentioned above, this would not cover BY-HAND artifacts, and other current or future Package-Type(s). OOC, what would be the purpose of checking what is shipped on a binary upload? > (3) > > We observed that .buildinfo files are included in purportedly > source-only changes files by `dpkg-buildpackage -S`. > > Is this correct? Why are they included in source-only uploads? Yes, this is correct, although I've noticed again (as I did in the past but seem to have forgotten) that the dpkg-buildpackage man page is out-of-sync regarding this, which I'll be fixing. In any case the other day I just added a FAQ entry, given that this seems a recurring question. :) <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F> If there's anything that does not seem to hold, or is unclear I'm happy to clarify it further. Thanks, Guillem
