Re: [PATCH 07/22] tests/acceptance/virtiofs_submounts.py: evaluate string not length

[Cleber Rosa <crosa@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]

On Tue, Feb 09, 2021 at 06:15:26PM +0100, Philippe Mathieu-Daudé wrote:
> > 
> > I've actually done this with some Xen patches I'm working on at the
> > moment. I'll probably decorate the test with:
> > 
> >   @skipUnless(os.getenv('AVOCADO_ALLOW_UNTRUSTED_CODE'), 'untrusted code')
> > 
> > with a comment explaining what's waiting to be upstreamed. Once there
> > are upstream binaries I plan on transitioning the test to those.
> 
> Instead of a binary AVOCADO_ALLOW_UNTRUSTED_CODE variable, we could
> have a list allowed domains/namespaces, that can be increased on the
> tester discretion.
> 
> For example these are assumed trusted:
> 
> . archives.fedoraproject.org
> . archive.debian.org
> . cdn.netbsd.org
> . github.com/torvalds
> . people.debian.org/~aurel32
> . snapshot.debian.org
> . storage.kernelci.org
> . www.qemu-advent-calendar.org
> 
> Then personally interested in testing ARM boards I'd amend:
> 
> . apt.armbian.com
> . github.com/philmd
> . github.com/groeck
> . github.com/hskinnemoen
> . github.com/pbatard
> 
> and Max's repo since I'm interested in testing virtiofs_submounts.
> 

Hi Phil,

I think I follow your idea, but I see two issues here:

 1) Functional area (subsystem / architecture / machine type, etc)
 2) Trustfulness of the code

WRT 1, the domains do not contain meaning onto themselves, so a
secondary mapping of subsystem/architecture/machine to the domain
would be needed.  Also, wouldn't it be common to end up needing a N:N
mapping between domains and subsystem/architecture/machine?

WRT 2, while limiting download from a number of domains can add some
protection, the ultimate trust is achieved by setting a hash to the
exact code we will download/run.

If those points seem valid, then I believe it's better to continue
thinking of subsystem/architecture/machine because of the usability
aspects, and possibly improve the perceived level of trust/stability
of the assets by adding a "tier" classification.  That one, one could
pick, say:

 * board|machine_type == "foo" AND
 * tier == 1

And exclude what is considered inferior tiers.  How does that sound?

Regards,
- Cleber.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]