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

[Salvatore Bonaccorso]

Hi,

On Sat, Mar 09, 2019 at 03:00:10PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> The following question goes maybe specifically to Ansgar, from
> dak/ftp-master perspective:
> 
> On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > Hi Guillem!
> > 
> > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > Hi!
> > > 
> > > On Thu, 2018-11-08 at 20:28:57 +0000, Holger Levsen wrote:
> > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > We were again biten by this issue for some security-updates (most
> > > > > recent one nginx). Do any involved parties know, was there any
> > > > > progress in adressing this problem? 
> > > 
> > > Sorry, had your earlier mail from July marked for reply, but it seems
> > > I missed that. :/
> > > 
> > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > wrote:
> > > > 
> > > >    Perhaps the simplest and more correct might be to name it using
> > > >    something like source+amd64 as the arch name, which seems like a
> > > >    dubious arch, but at least is accurate and might be trivial to
> > > >    implement, taking care of not ending up with such fake arch in
> > > >    unexpected places…
> > > > 
> > > > and I cannot find anything wrong with this simple solution and have
> > > > already asked Guillem in August to implement this ;)
> > > 
> > > So, as I mentioned at the time this would require modifing the internal
> > > filtering of the debian/files entries to cover this case in several of
> > > the tools. It also modifies the documented filename pattern in
> > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > But this breaks previous public filename "interfaces", seems rather
> > > intrusive, and entirely inappropriate for a stable update, which means
> > > it would not fix your immediate problems anyway, only starting with
> > > Buster. :/
> > 
> > Although this would not help us for stretch-security uploads, such a
> > move starting from buster would be very appreciated!
> > 
> > Thanks a lot for your time investing in it, very much appreicated.
> 
> We regularly get issue still with that given one easily forgets about
> the issue (the last occurence whas the php7.0 upload for
> stretch-security as of yesterday). I wonder thus: would it be easily
> workaroundable on ftp-master/dak's side to perform some additional
> checks in that direction and reject such uploads wich would contain a
> _${arch}.buildinfo file?
> 
> Any help in this regard would be very welcome from security team's
> perspective, as we -- although an easy step -- need to fetch rejected
> packages, rename files, resign and upload.
> 
> Sorry for always returning with this issue to both you and dpkg
> maintainers.

We regularly get biten by this issue when contributors to security
uploads, most recently with the bind9 upload but as well others.

Would it be possible to at least workaround this on dak's side?
Disabling source-only uploads completely would seem to be a step back
on that regards.

Though if that's the only way  out of having to regularly fetch the
rejected builds, do manual renamings and resigning and reuploading of
files, then we should then just disable source-only uploads for the
security suites again.

So I think we pretty much would prefer to be able to continue so.

Just to be clear, thanks a lot for your work, this is not meant as
critique, just hilighting that we have recurring issues due to this
bug when people perform uploads for security.

Regards,
Salvatore