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

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Ansgar Burchardt-8
Package: dpkg
Version: 1.18.24
Severity: important

source-only uploads sometimes include a _amd64.buildinfo (or other
architecture).  This sometimes causes problems as the amd64 buildd
upload will include a file using the same name.

In particular, it breaks any uploads going to policy queues
(e.g. security's embargoed, proposed-updates) and the sync of uploads
from security-master to ftp-master.

The same is true for maintainer source+all uploads: if the source also
builds arch-indep binaries, the .buildinfo files from maintainer and
buildd might end using the same name.

Please don't include _amd64.buildinfo in source-only or source+all
uploads.  Just changing the name is enough to make me happy
(e.g. _source.buildinfo).

It might also be worth having an option to change the suffix of all
such names (.changes, .buildinfo) easily so that buildds could use
_${arch}-buildd.changes or something.

Ansgar

Reply | Threaded
Open this post in threaded view
|

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

Ansgar Burchardt-8
Hi,

> source-only uploads sometimes include a _amd64.buildinfo (or other
> architecture).  This sometimes causes problems as the amd64 buildd
> upload will include a file using the same name.

This broke two uploads to the security archive again.  That's not great,
so this bug really should be fixed in stable too (or we could disallow
source-only uploads, or source-only uploads including a .buildinfo for
stable).

Ansgar

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
Hi Ansgar,

On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:

> Hi,
>
> > source-only uploads sometimes include a _amd64.buildinfo (or other
> > architecture).  This sometimes causes problems as the amd64 buildd
> > upload will include a file using the same name.
>
> This broke two uploads to the security archive again.  That's not great,
> so this bug really should be fixed in stable too (or we could disallow
> source-only uploads, or source-only uploads including a .buildinfo for
> stable).

and unfortunately another one (libvirt). Should we maybe disalow
source-only uploads including a buildinfo file for now? Completely
disalowing source-only uploads would be a major drawback IMHO.

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
Hello,

On Thu, Oct 19, 2017 at 03:13:15PM +0200, Salvatore Bonaccorso wrote:

> Hi Ansgar,
>
> On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> > Hi,
> >
> > > source-only uploads sometimes include a _amd64.buildinfo (or other
> > > architecture).  This sometimes causes problems as the amd64 buildd
> > > upload will include a file using the same name.
> >
> > This broke two uploads to the security archive again.  That's not great,
> > so this bug really should be fixed in stable too (or we could disallow
> > source-only uploads, or source-only uploads including a .buildinfo for
> > stable).
>
> and unfortunately another one (libvirt). Should we maybe disalow
> source-only uploads including a buildinfo file for now? Completely
> disalowing source-only uploads would be a major drawback IMHO.

Any news regarding this proposal from Ansgar? We were biten now
several times already by this (e.g. php update, curl via
security.d.o).

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Guido Günther
Hi,
On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:

> Hello,
>
> On Thu, Oct 19, 2017 at 03:13:15PM +0200, Salvatore Bonaccorso wrote:
> > Hi Ansgar,
> >
> > On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> > > Hi,
> > >
> > > > source-only uploads sometimes include a _amd64.buildinfo (or other
> > > > architecture).  This sometimes causes problems as the amd64 buildd
> > > > upload will include a file using the same name.
> > >
> > > This broke two uploads to the security archive again.  That's not great,
> > > so this bug really should be fixed in stable too (or we could disallow
> > > source-only uploads, or source-only uploads including a .buildinfo for
> > > stable).
> >
> > and unfortunately another one (libvirt). Should we maybe disalow
> > source-only uploads including a buildinfo file for now? Completely
> > disalowing source-only uploads would be a major drawback IMHO.
>
> Any news regarding this proposal from Ansgar? We were biten now
> several times already by this (e.g. php update, curl via
> security.d.o).

Is this just a configuration thing? If so I'd say it would be good to
activate. I'm adding Thorsten to cc: since he might know.
Cheers,
 -- Guido

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
In reply to this post by Salvatore Bonaccorso-4
Hi

On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:

> Hello,
>
> On Thu, Oct 19, 2017 at 03:13:15PM +0200, Salvatore Bonaccorso wrote:
> > Hi Ansgar,
> >
> > On Thu, Oct 05, 2017 at 09:01:59PM +0200, Ansgar Burchardt wrote:
> > > Hi,
> > >
> > > > source-only uploads sometimes include a _amd64.buildinfo (or other
> > > > architecture).  This sometimes causes problems as the amd64 buildd
> > > > upload will include a file using the same name.
> > >
> > > This broke two uploads to the security archive again.  That's not great,
> > > so this bug really should be fixed in stable too (or we could disallow
> > > source-only uploads, or source-only uploads including a .buildinfo for
> > > stable).
> >
> > and unfortunately another one (libvirt). Should we maybe disalow
> > source-only uploads including a buildinfo file for now? Completely
> > disalowing source-only uploads would be a major drawback IMHO.
>
> Any news regarding this proposal from Ansgar? We were biten now
> several times already by this (e.g. php update, curl via
> security.d.o).

The recent xmltooling update caused the same problem :(

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Salvatore Bonaccorso-4
On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> Any news regarding this proposal from Ansgar? We were biten now
> several times already by this (e.g. php update, curl via
> security.d.o).

Guilem, what's your stance on this bug?

We (reproducible builds) really dont want "our" tools (=.buildinfo files)
to cause grief to other teams in Debian, and especially not on a regular
basis... so as a first step to fix this, I'd like to collect opinions
how to best fix this issue here.


--
cheers,
        Holger

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
On Thu, 2018-03-01 at 15:22:30 +0000, Holger Levsen wrote:
> On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> > Any news regarding this proposal from Ansgar? We were biten now
> > several times already by this (e.g. php update, curl via
> > security.d.o).
>
> Guilem, what's your stance on this bug?

I think it should be fixed. I've just not come up with something that
would seem a generic/clean way to do that. :(

> We (reproducible builds) really dont want "our" tools (=.buildinfo files)
> to cause grief to other teams in Debian, and especially not on a regular
> basis... so as a first step to fix this, I'd like to collect opinions
> how to best fix this issue here.

The problem got introduced when I proposed changing the filename
format, and dropping the annoying timestamp. I also though there was
talk at some point initially about DAK renaming those files to cope
with possible multiple uploads if the conflicting names?

Renaming the arch buildinfo to _source.buildinfo seems wrong, and even
then I'm not sure how to cleanly transfer that knowledge from
dpkg-buildpackage to dpkg-genbuildinfo.

I guess, the ideal solution would be to qualify the buildinfo file
with the builder user and hostname, because that in a way denotes the
build environment. But that seems like too much leakage. As in:

  [hidden email]

Perhaps just using the maintainer email address might be enough though,
the one from the -m option or from the changelog, which AFAIR buildds
do set? But this seems like it can produce quite ugly filenames:

  [hidden email]

not to mention that both of these "break" the conventional pattern, which
is still used by things like the debian/files parser and injector.

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…

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
Hi Guillem,

On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover wrote:

> On Thu, 2018-03-01 at 15:22:30 +0000, Holger Levsen wrote:
> > On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
> > > Any news regarding this proposal from Ansgar? We were biten now
> > > several times already by this (e.g. php update, curl via
> > > security.d.o).
> >
> > Guilem, what's your stance on this bug?
>
> I think it should be fixed. I've just not come up with something that
> would seem a generic/clean way to do that. :(
>
> > We (reproducible builds) really dont want "our" tools (=.buildinfo files)
> > to cause grief to other teams in Debian, and especially not on a regular
> > basis... so as a first step to fix this, I'd like to collect opinions
> > how to best fix this issue here.
>
> The problem got introduced when I proposed changing the filename
> format, and dropping the annoying timestamp. I also though there was
> talk at some point initially about DAK renaming those files to cope
> with possible multiple uploads if the conflicting names?
>
> Renaming the arch buildinfo to _source.buildinfo seems wrong, and even
> then I'm not sure how to cleanly transfer that knowledge from
> dpkg-buildpackage to dpkg-genbuildinfo.
>
> I guess, the ideal solution would be to qualify the buildinfo file
> with the builder user and hostname, because that in a way denotes the
> build environment. But that seems like too much leakage. As in:
>
>   [hidden email]
>
> Perhaps just using the maintainer email address might be enough though,
> the one from the -m option or from the changelog, which AFAIR buildds
> do set? But this seems like it can produce quite ugly filenames:
>
>   [hidden email]
>
> not to mention that both of these "break" the conventional pattern, which
> is still used by things like the debian/files parser and injector.
>
> 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…

Do you know, was there any (non-logged) progress for this issue? I'm
asking back since we had for security uploads now since then several
times problems were we had to workaround it by reuploading the buildd
uploads renamed.

Thanks all for your work!

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Guillem Jover
Hi Guillem,

people are still affected by this bug...

On Fri, Mar 02, 2018 at 01:25:51AM +0100, Guillem Jover 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…

could we have this simple migation for now, please?


--
cheers,
        Holger

-------------------------------------------------------------------------------
                    holger@(debian|reproducible-builds).org

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Vagrant Cascadian-4
In reply to this post by Guillem Jover
On 2018-03-01, Guillem Jover wrote:

> On Thu, 2018-03-01 at 15:22:30 +0000, Holger Levsen wrote:
>> On Wed, Jan 24, 2018 at 04:05:39PM +0100, Salvatore Bonaccorso wrote:
>> We (reproducible builds) really dont want "our" tools (=.buildinfo files)
>> to cause grief to other teams in Debian, and especially not on a regular
>> basis... so as a first step to fix this, I'd like to collect opinions
>> how to best fix this issue here.
>
> The problem got introduced when I proposed changing the filename
> format, and dropping the annoying timestamp. I also though there was
> talk at some point initially about DAK renaming those files to cope
> with possible multiple uploads if the conflicting names?
It seems DAK is doing this, at least in some cases:

vagrant@coccia:/srv/ftp-master.debian.org/buildinfo/2018/08/01$ ls /srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai*amd64*

/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai_0.1.28-1_amd64.buildinfo
/srv/ftp-master.debian.org/buildinfo/2018/08/01/libthai_0.1.28-1_amd64.buildinfo.0

I'm fairly sure in this case the .0 one is from the buildd.

Could something similar be done with the security and other upload
queues? maybe even appending .quename.N or something. e.g. security.0.


> I guess, the ideal solution would be to qualify the buildinfo file
> with the builder user and hostname, because that in a way denotes the
> build environment. But that seems like too much leakage. As in:
>
>   [hidden email]

What about having an option to enable this, and the buildd's would
enable it, and it otherwise defaults to false?


Do binNMUs produce a distinct .buildinfo filename? I seem to recall
local builds with sbuild producing an identical .buildinfo filename to
the regular build using --append-to-version and re-building the .dsc,
but I'm not sure about how the official buildds work with binNMUs.


live well,
  vagrant

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
In reply to this post by Salvatore Bonaccorso-4
Hi

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 I know, probably patches and ideas welcome, but I cannot
contribute here, take my question please just from my "users"
point of view.

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
Hi,

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?

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 ;)


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
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. :/

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
Hi!

On Fri, 2018-11-09 at 11:48:27 +0100, Guillem Jover wrote:

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

Actually, I guess the other option that might be an option for stable is
to make dpkg-buildpackage generate the buildinfo file itself, and on
source-only uploads force the name to be _source.buildinfo regardless
of the options passed down to dpkg-genbuildinfo (even if the contents
will end up not matching the name).

This would seem rather less intrusive, as that only changes the
behavior in a "corner-case" (even though documented and recommended
one), when using «dpkg-buildpackage --changes-option=-S». And while it
could be considered to produce confusing filenames, it sticks to the
current pattern. It would also fix the other bug where running
dpkg-genbuildinfo leaves debian/files around, even on source only
builds.

So, I might go with that instead.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Guillem Jover
On Fri, 2018-11-09 at 11:55:38 +0100, Guillem Jover wrote:

> Actually, I guess the other option that might be an option for stable is
> to make dpkg-buildpackage generate the buildinfo file itself, and on
> source-only uploads force the name to be _source.buildinfo regardless
> of the options passed down to dpkg-genbuildinfo (even if the contents
> will end up not matching the name).
>
> This would seem rather less intrusive, as that only changes the
> behavior in a "corner-case" (even though documented and recommended
> one), when using «dpkg-buildpackage --changes-option=-S». And while it
> could be considered to produce confusing filenames, it sticks to the
> current pattern. It would also fix the other bug where running
> dpkg-genbuildinfo leaves debian/files around, even on source only
> builds.

Err, ugh, disregard all the above. This would still generate the
_<arch>.buildinfo pattern, because we are under a full build, and
the only option passed is for .changes, an option which we do not
parse from dpkg-buildpackage anyway. If the .changes file was generated
by dpkg-genchanges itself then it could end up generating
_source.changes, but that would not help here at all anyway…

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
In reply to this post by Guillem Jover
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.

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
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.

Regards,
Salvatore

Reply | Threaded
Open this post in threaded view
|

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

Salvatore Bonaccorso-4
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

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
Hi,

On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote:

> > On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > > 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:
> > > > > 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!
Guillem, back in November Salvatore said they would appreciate this
"source+amd64 as the arch name" solution for this bug (see above), while
now (because nothing happened I believe) he suggests disabling source
all uploads for security builds, which IMO would be a *very* bad and sad
outcome, as I believe source only security uploads are even more desired
than regular source only uploads...

> 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.
sigh, understandable...


--
tschau,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
12