Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Ansgar Burchardt]

Mattia Rizzolo writes:
> On Tue, Jun 18, 2019 at 06:29:12PM +0200, Ansgar Burchardt wrote:
>> The .buildinfo files are referred to in the .changes files; renaming
>> them would require updating the .changes file.  The .changes files are
>> used to upload the security updates to ftp-master.
>
> With .changes being ephemeral, it feels to me that using them to cross
> the archive is not really a good solution, and whatever is used to copy
> packages from one archive to another (is it dak itself?) should instead
> re-create the upload and re-sign it.  Also because that way it would be
> perfectly able to "upload" all of the sources+binaries from sec-master
> to ftp-master in a single go, which can't be bad.

We also currently require .dsc to be signed by the same key as the
.changes; that wouldn't work either.

There are some advantages to changing the way the sync works, but it's
not a priority to look at.  There are enough other things...

>> ftp-master also has the same problem when uploads end up in policy
>> queues (the renaming to .buildinfo.N is only done when dak is "done"
>> with the file and will never touch it again).
>
> Also here, it feels to me that once something is accepted into a policy
> queue, dak should already consider it something controlled by itself,
> store checksums in the database and be done, not keep the .changes
> around as a "source of truth" for additional processing, imho.

Throwing away .changes doesn't help with .buildinfo name conflicts.

> Sure, I understand that things works like that, I'm just showing a few
> design points that could potentially be done differently.

We could also just not accept .buildinfo uploads when they don't contain
useful information about published binaries, that is for source-only
uploads.

Maybe I should reenable the check for this at least on security-master?
It was rejecting uploads that are okay for unstable/experimental so I
disabled it again the last time.

Ansgar