Re: What makes a .changes file source-only?
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
Reply to: