Re: Please verify that buster related suites are functional

[Santiago Vila <sanvila@unex.es>]

On Mon, Apr 15, 2019 at 07:57:20AM +0200, Salvatore Bonaccorso wrote:
> Hi Niels, release team and ftp-masters,
> 
> [dropping backports list for this reply, adding ftp-masters]
> 
> On Sun, Apr 14, 2019 at 09:02:00PM +0000, Niels Thykier wrote:
> > Hi Security team and backports team,
> > 
> > According to the release team's checklist we have the following TODO for
> > you:
> > 
> > """
> > Check with security team and backports team that it is possible to build
> > uploads for -security and -backports
> > """
> > 
> > To our knowledge, the relevant suites have already been created
> > (#917537) and ask that you kindly smoke test them to ensure they work as
> > intended.
> > 
> >  * Please let us know when you have verified these relevant suites or if
> >    you have any issues with them.
> 
> The easiest thing is still to do as in previous releases and prepare a
> src:hello as follows (which have done locally):
> 
>  hello (2.10-1+deb10u1) buster-security; urgency=high
>  .
>    * Non-maintainer upload by the Security Team.
>    * No-change test upload for buster-security
> 
> upload it, verify it get's correctly processed into the embargoed
> queues, buildd's pick it up for build on all supported architectures.
> 
> Then the next step was to actually dak install it  and verify it
> correctly land in the security archive.
> 
> But after that we have a hello/2.10-1+deb10u1 in the security archive.
> Question to FTP master, can we just after this test dak remove the
> package again and let forget the test version?
> 
> I'm asking  because Santiago, maintainer of src:hello raised concern
> that we should not use src:hello for this final infrastructure test.
> Obviously we otherwise can just fork it. But as package it has nice
> characteristics as testpackage.

Exactly. Leaving aside the fact that we are highly skilled people
that could use all sort of sandboxes to test things and not the real
thing, if you absolutely must use a real package, for all means
use one that either:

a) Has a real security problem.
b) Has a real security history that will surely make subsequent security
uploads to supersede the "fake" one, for example, the linux package.

If this is not possible, I offered Salvatore and Security People to
upload base-files in a way that leaves no traces after the test has
been made. I still have to upload base-files_10.2 for buster with the
final changes, if you can upload base-files_10.1+deb1 and we can have
any assurance that this will not prevent base-files_10.2 from
propagating from unstable to testing, that would be a lot better than
a fake upload of src:hello.

Thanks.