Hello Guillem and Ian,

Thank you for such a quick reply!

On Wed, May 24, 2017 at 01:57:54AM +0200, Guillem Jover wrote:
> 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).

So BY-HAND .changes could have "Architecture: source" but contain binary
files?  If so, we would definitely need to check all file extensions,
instead of relying on the Architecture field.

> 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.

That's a great idea.  By checking against the .dsc, we can avoid having
to update dgit if a new source format is added.  Though, we would also
need to permit the .buildinfo, which is not part of the .dsc

> OOC, what would be the purpose of checking what is shipped on a binary
> upload?

I think Ian just saw the opportunity to add a new sanity check to dgit.

Ian: given that BY-HAND uploads could contain a lot of different kinds
of file, maybe we should stick to the option of only checking purported
source-only .changes files, abandoning this extra check?

> > (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>

Thank you for confirming this, and for the FAQ link.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to