[RFC] Toaster access control

[RFC] Toaster access control

[Barros Pena, Belen]

One of the new features we are supposed to deliver in Toaster 1.8 is
access control: i.e. the concept of users and permissions. This is the
Bugzilla entry for the design

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6233

I think there are basically 2 approaches we can take for access control:

1. Top-down approach
2. Distributed approach

1. The top-down approach

This is the approach where there is an all powerful administrator that
creates users, grants them permissions and administers them. The all
powerful administrator is the access gatekeeper. If you want to use
Toaster you need to request access somehow. The all powerful administrator
will (or will not) grant you access, and will decide what you can and
cannot do in Toaster.

This is a very common approach: Bugzilla works like this. Moderated
mailing lists work essentially like this. I believe Jenkins works like
this too. 

2. Distributed approach

User management is a shared responsibility between all users who can
create Toaster projects. Users are invited to join a particular project by
the project creator. Project creators decide what the people they invite
can do within that project and within Toaster.

This is the approach used by the Basecamp project management tool
(https://basecamp.com/).

How both approaches compare?

* In the top-down approach, the fundamental unit for user management is a
Toaster instance; in the distributed approach, the fundamental unit for
user management is a Toaster project.

* The top-down approach requires a central place for user management that
can only be accessed by the all powerful administrator(s). This central
place is outside and above Toaster projects. In the distributed approach,
user management takes place within a Toaster project.

* In the top-down approach, the user management task falls on the all
powerful administrator(s). In the distributed approach, user management is
shared between all project creators.

* The top-down approach is request-based: I must solicit access to Toaster
to the all powerful administrator, who then decides which projects I can
access and what I can do in Toaster. The distributed approach is
invitation-based: the project creator invites me to access her project.

* In the top-down approach, there is normally one all powerful
administrator and then a whole bunch of Toaster users. In the distributed
approach, there are a whole bunch of project creators and a whole bunch of
project users.

Which approach do I like best? The distributed one, of course. This is why:

1. Because so far we have designed Toaster to be project based. For
example, although there is a global layer list in the Toaster database
that spans all projects, layers are only exposed in the context of a
certain project. There are no Toaster pages outside of projects, apart
from the landing page. The distributed approach to access control reflects
this currently existing structure, which keeps things nice and simple.

2. Because it avoids the need for a global administration interface. There
are Toaster projects, and within a project you have a list of the people
who have access to that project.

3. Because it shares the responsibility of user management: no single
person has to deal with this very annoying task. The responsibility is
shared between all project creators.

4. Because it makes user management easier: no need to deal with a list of
a million users, and give each of them access to 50 projects. User lists
are broken down by project, which means shorter lists. Project access
granting happens organically, instead of in a single go. Inviting existing
users to a project is easy because we keep a global list of users that
spans all projects, even if we choose not to show it: typing a name should
provide you suggestions from existing users, and you can select one of
them or create a new one as needed.

5. Because it avoids the need for sophisticated user management features,
such as Active Directory integration (don't laugh:
https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin),
which we are in no position to deliver.

But I am just the designer: what the hell do I know? So it would be good
to find out which approach you prefer and why.

Thanks!

Belén

Re: [RFC] Toaster access control

[Mihail, StanciuX]

Hello Belén,

While I agree with your assessment in general, there is one possible problem I foresee:
If I understand it right, in the distributed approach anyone can create a new project whenever they want to. 
While this shouldn't be a problem under normal working conditions for a small to medium user base, I feel that for a public implementation or a very large user base this might present a resource problem in that, due to a large number of active projects, queues might grow to become far too large for normal use. 
By extension, I think this might also be a vulnerability for malicious users to exploit.

If I might suggest a hybrid of the two approaches, as follows:

3. The Hybrid
Basically, this is a distributed approach, with an additional layer on top -  a moderately powerful administrator that grants project-creation rights to users, as needed.
This way I feel we maintain most of the benefits of the distributed approach, as opposed to the top-down approach, but with the added security of not allowing just anyone who gets access to the toaster server to create a project and request resources without some supervision, be it from the "administrator" that granted them project creation rights or the project owner that granted them access to their project.

Of course, I just might be overly paranoid :)

I hope my description was clear both regarding my concerns and the proposed implementation.

Cheers,
Mihail

-----Original Message-----
From: toaster-bounces@yoctoproject.org [mailto:toaster-bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
Sent: Friday, October 24, 2014 6:38 PM
To: toaster@yoctoproject.org
Subject: [Toaster] [RFC] Toaster access control

One of the new features we are supposed to deliver in Toaster 1.8 is access control: i.e. the concept of users and permissions. This is the Bugzilla entry for the design

https://bugzilla.yoctoproject.org/show_bug.cgi?id=6233

I think there are basically 2 approaches we can take for access control:

1. Top-down approach
2. Distributed approach

1. The top-down approach

This is the approach where there is an all powerful administrator that creates users, grants them permissions and administers them. The all powerful administrator is the access gatekeeper. If you want to use Toaster you need to request access somehow. The all powerful administrator will (or will not) grant you access, and will decide what you can and cannot do in Toaster.

This is a very common approach: Bugzilla works like this. Moderated mailing lists work essentially like this. I believe Jenkins works like this too. 

2. Distributed approach

User management is a shared responsibility between all users who can create Toaster projects. Users are invited to join a particular project by the project creator. Project creators decide what the people they invite can do within that project and within Toaster.

This is the approach used by the Basecamp project management tool (https://basecamp.com/).

How both approaches compare?

* In the top-down approach, the fundamental unit for user management is a Toaster instance; in the distributed approach, the fundamental unit for user management is a Toaster project.

* The top-down approach requires a central place for user management that can only be accessed by the all powerful administrator(s). This central place is outside and above Toaster projects. In the distributed approach, user management takes place within a Toaster project.

* In the top-down approach, the user management task falls on the all powerful administrator(s). In the distributed approach, user management is shared between all project creators.

* The top-down approach is request-based: I must solicit access to Toaster to the all powerful administrator, who then decides which projects I can access and what I can do in Toaster. The distributed approach is
invitation-based: the project creator invites me to access her project.

* In the top-down approach, there is normally one all powerful administrator and then a whole bunch of Toaster users. In the distributed approach, there are a whole bunch of project creators and a whole bunch of project users.

Which approach do I like best? The distributed one, of course. This is why:

1. Because so far we have designed Toaster to be project based. For example, although there is a global layer list in the Toaster database that spans all projects, layers are only exposed in the context of a certain project. There are no Toaster pages outside of projects, apart from the landing page. The distributed approach to access control reflects this currently existing structure, which keeps things nice and simple.

2. Because it avoids the need for a global administration interface. There are Toaster projects, and within a project you have a list of the people who have access to that project.

3. Because it shares the responsibility of user management: no single person has to deal with this very annoying task. The responsibility is shared between all project creators.

4. Because it makes user management easier: no need to deal with a list of a million users, and give each of them access to 50 projects. User lists are broken down by project, which means shorter lists. Project access granting happens organically, instead of in a single go. Inviting existing users to a project is easy because we keep a global list of users that spans all projects, even if we choose not to show it: typing a name should provide you suggestions from existing users, and you can select one of them or create a new one as needed.

5. Because it avoids the need for sophisticated user management features, such as Active Directory integration (don't laugh:
https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin),
which we are in no position to deliver.

But I am just the designer: what the hell do I know? So it would be good to find out which approach you prefer and why.

Thanks!

Belén

--
_______________________________________________
toaster mailing list
toaster@yoctoproject.org
https://lists.yoctoproject.org/listinfo/toaster

Re: [RFC] Toaster access control

[Richard Purdie]

On Fri, 2014-10-24 at 15:37 +0000, Barros Pena, Belen wrote:
> How both approaches compare?
> 
> * In the top-down approach, the fundamental unit for user management is a
> Toaster instance; in the distributed approach, the fundamental unit for
> user management is a Toaster project.
> 
> * The top-down approach requires a central place for user management that
> can only be accessed by the all powerful administrator(s). This central
> place is outside and above Toaster projects. In the distributed approach,
> user management takes place within a Toaster project.
> 
> * In the top-down approach, the user management task falls on the all
> powerful administrator(s). In the distributed approach, user management is
> shared between all project creators.
> 
> * The top-down approach is request-based: I must solicit access to Toaster
> to the all powerful administrator, who then decides which projects I can
> access and what I can do in Toaster. The distributed approach is
> invitation-based: the project creator invites me to access her project.
> 
> * In the top-down approach, there is normally one all powerful
> administrator and then a whole bunch of Toaster users. In the distributed
> approach, there are a whole bunch of project creators and a whole bunch of
> project users.
> 
> Which approach do I like best? The distributed one, of course. This is why:
> 
> 1. Because so far we have designed Toaster to be project based. For
> example, although there is a global layer list in the Toaster database
> that spans all projects, layers are only exposed in the context of a
> certain project. There are no Toaster pages outside of projects, apart
> from the landing page. The distributed approach to access control reflects
> this currently existing structure, which keeps things nice and simple.
> 
> 2. Because it avoids the need for a global administration interface. There
> are Toaster projects, and within a project you have a list of the people
> who have access to that project.
> 
> 3. Because it shares the responsibility of user management: no single
> person has to deal with this very annoying task. The responsibility is
> shared between all project creators.
> 
> 4. Because it makes user management easier: no need to deal with a list of
> a million users, and give each of them access to 50 projects. User lists
> are broken down by project, which means shorter lists. Project access
> granting happens organically, instead of in a single go. Inviting existing
> users to a project is easy because we keep a global list of users that
> spans all projects, even if we choose not to show it: typing a name should
> provide you suggestions from existing users, and you can select one of
> them or create a new one as needed.
> 
> 5. Because it avoids the need for sophisticated user management features,
> such as Active Directory integration (don't laugh:
> https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin),
> which we are in no position to deliver.
> 
> But I am just the designer: what the hell do I know? So it would be good
> to find out which approach you prefer and why.

I think this is fine, however there is a "but" coming. I believe there
will be some "site" configuration which people will desire, for example
whether users can or cannot invite other users to projects or can create
new users. Some of these operations will need to be restricted to some
set of users.

So whilst I like the idea, there will be a pressure towards elements of
the other model and there are some reasons for that which we should try
and consider if we can.

I feel I'm explaining that badly, I hope this is understandable...

Cheers,

Richard

Re: [RFC] Toaster access control

[Barros Pena, Belen]

Hi Mihail,

Thanks for taking the time to read this and give feedback. Much
appreciated.

On 28/10/2014 12:02, "Mihail, StanciuX" <stanciux.mihail@intel.com> wrote:

>Hello Belén,
>
>While I agree with your assessment in general, there is one possible
>problem I foresee:
>If I understand it right, in the distributed approach anyone can create a
>new project whenever they want to.
>While this shouldn't be a problem under normal working conditions for a
>small to medium user base, I feel that for a public implementation or a
>very large user base this might present a resource problem in that, due
>to a large number of active projects, queues might grow to become far too
>large for normal use.
>By extension, I think this might also be a vulnerability for malicious
>users to exploit.
>
>If I might suggest a hybrid of the two approaches, as follows:
>
>3. The Hybrid
>Basically, this is a distributed approach, with an additional layer on
>top -  a moderately powerful administrator that grants project-creation
>rights to users, as needed.

Well spotted: my email made no mention to the permissions system. I think
the plan is to put in place very simple permissions initially, mainly to
make sure we hit our 1.8 target. The permissions you can grant a user will
be something like:

* Access to a project, which is binary (i.e. If you have access, you can
see the configuration and the build information, you can download
artifacts, you can change the configuration and you can start builds)

* Creating projects, which is also binary (either you can create new
Toaster projects or you can't).

* Administering Toaster: this gives a user the ability to access and edit
the Toaster configuration using the Django admin interface.

>This way I feel we maintain most of the benefits of the distributed
>approach, as opposed to the top-down approach, but with the added
>security of not allowing just anyone who gets access to the toaster
>server to create a project and request resources without some
>supervision, be it from the "administrator" that granted them project
>creation rights or the project owner that granted them access to their
>project.
>
>Of course, I just might be overly paranoid :)

I think you are not overly paranoid: I think you are being pretty
reasonable. I, however, still would argue for the distributed approach
when it comes to granting permissions like creating projects. We don't
only spread the workload of user management: we also spread the
responsibility. If you give someone the rights to create Toaster projects,
we hope you know what you are doing.

Of course, I just might be overly optimistic (I do tend to think the best
of people) ;)

Cheers

Belén


>
>I hope my description was clear both regarding my concerns and the
>proposed implementation.
>
>Cheers,
>Mihail
>
>-----Original Message-----
>From: toaster-bounces@yoctoproject.org
>[mailto:toaster-bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
>Sent: Friday, October 24, 2014 6:38 PM
>To: toaster@yoctoproject.org
>Subject: [Toaster] [RFC] Toaster access control
>
>One of the new features we are supposed to deliver in Toaster 1.8 is
>access control: i.e. the concept of users and permissions. This is the
>Bugzilla entry for the design
>
>https://bugzilla.yoctoproject.org/show_bug.cgi?id=6233
>
>I think there are basically 2 approaches we can take for access control:
>
>1. Top-down approach
>2. Distributed approach
>
>1. The top-down approach
>
>This is the approach where there is an all powerful administrator that
>creates users, grants them permissions and administers them. The all
>powerful administrator is the access gatekeeper. If you want to use
>Toaster you need to request access somehow. The all powerful
>administrator will (or will not) grant you access, and will decide what
>you can and cannot do in Toaster.
>
>This is a very common approach: Bugzilla works like this. Moderated
>mailing lists work essentially like this. I believe Jenkins works like
>this too. 
>
>2. Distributed approach
>
>User management is a shared responsibility between all users who can
>create Toaster projects. Users are invited to join a particular project
>by the project creator. Project creators decide what the people they
>invite can do within that project and within Toaster.
>
>This is the approach used by the Basecamp project management tool
>(https://basecamp.com/).
>
>How both approaches compare?
>
>* In the top-down approach, the fundamental unit for user management is a
>Toaster instance; in the distributed approach, the fundamental unit for
>user management is a Toaster project.
>
>* The top-down approach requires a central place for user management that
>can only be accessed by the all powerful administrator(s). This central
>place is outside and above Toaster projects. In the distributed approach,
>user management takes place within a Toaster project.
>
>* In the top-down approach, the user management task falls on the all
>powerful administrator(s). In the distributed approach, user management
>is shared between all project creators.
>
>* The top-down approach is request-based: I must solicit access to
>Toaster to the all powerful administrator, who then decides which
>projects I can access and what I can do in Toaster. The distributed
>approach is
>invitation-based: the project creator invites me to access her project.
>
>* In the top-down approach, there is normally one all powerful
>administrator and then a whole bunch of Toaster users. In the distributed
>approach, there are a whole bunch of project creators and a whole bunch
>of project users.
>
>Which approach do I like best? The distributed one, of course. This is
>why:
>
>1. Because so far we have designed Toaster to be project based. For
>example, although there is a global layer list in the Toaster database
>that spans all projects, layers are only exposed in the context of a
>certain project. There are no Toaster pages outside of projects, apart
>from the landing page. The distributed approach to access control
>reflects this currently existing structure, which keeps things nice and
>simple.
>
>2. Because it avoids the need for a global administration interface.
>There are Toaster projects, and within a project you have a list of the
>people who have access to that project.
>
>3. Because it shares the responsibility of user management: no single
>person has to deal with this very annoying task. The responsibility is
>shared between all project creators.
>
>4. Because it makes user management easier: no need to deal with a list
>of a million users, and give each of them access to 50 projects. User
>lists are broken down by project, which means shorter lists. Project
>access granting happens organically, instead of in a single go. Inviting
>existing users to a project is easy because we keep a global list of
>users that spans all projects, even if we choose not to show it: typing a
>name should provide you suggestions from existing users, and you can
>select one of them or create a new one as needed.
>
>5. Because it avoids the need for sophisticated user management features,
>such as Active Directory integration (don't laugh:
>https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin),
>which we are in no position to deliver.
>
>But I am just the designer: what the hell do I know? So it would be good
>to find out which approach you prefer and why.
>
>Thanks!
>
>Belén
>
>--
>_______________________________________________
>toaster mailing list
>toaster@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/toaster

Re: [RFC] Toaster access control

[Barros Pena, Belen]

On 28/10/2014 13:43, "Richard Purdie" <richard.purdie@linuxfoundation.org>
wrote:
>
>I think this is fine, however there is a "but" coming. I believe there
>will be some "site" configuration which people will desire, for example
>whether users can or cannot invite other users to projects or can create
>new users. Some of these operations will need to be restricted to some
>set of users.

Indeed. I spoke about the permissions system in my reply to Mihail. For
1.8, permissions will be very simple:
 
* Access to a project

* Creating projects

* Administering Toaster


>
>So whilst I like the idea, there will be a pressure towards elements of
>the other model and there are some reasons for that which we should try
>and consider if we can.

In this 'distributed' approach, you can grant permissions that match your
own permissions, so:

* Users who can only access projects cannot create users, and cannot grant
permissions of any kind

* Users that can create projects can grant access to other users and can
grant rights to create projects.

* Toaster administrators can grant access, grant rights to create projects
and create other Toaster administrators.

So as I mentioned before, we don't only distribute the workload: we also
distribute the responsibility. If you give someone the rights to
administer Toaster, we hope you know what you are doing.

I hope this makes sense.

Cheers

Belén


>
>I feel I'm explaining that badly, I hope this is understandable...
>
>Cheers,
>
>Richard
>
>
>

Re: [RFC] Toaster access control

[Richard Purdie]

On Wed, 2014-10-29 at 12:16 +0000, Barros Pena, Belen wrote:
> Well spotted: my email made no mention to the permissions system. I think
> the plan is to put in place very simple permissions initially, mainly to
> make sure we hit our 1.8 target. The permissions you can grant a user will
> be something like:
> 
> * Access to a project, which is binary (i.e. If you have access, you can
> see the configuration and the build information, you can download
> artifacts, you can change the configuration and you can start builds)

I'd propose one change here, splitting this into two. "read" and "write"
access. "read" covered most things except changing configuration and
starting builds.

Cheers,

Richard

Re: [RFC] Toaster access control

[Barros Pena, Belen]

On 29/10/2014 13:11, "Richard Purdie" <richard.purdie@linuxfoundation.org>
wrote:

>On Wed, 2014-10-29 at 12:16 +0000, Barros Pena, Belen wrote:
>> Well spotted: my email made no mention to the permissions system. I
>>think
>> the plan is to put in place very simple permissions initially, mainly to
>> make sure we hit our 1.8 target. The permissions you can grant a user
>>will
>> be something like:
>> 
>> * Access to a project, which is binary (i.e. If you have access, you can
>> see the configuration and the build information, you can download
>> artifacts, you can change the configuration and you can start builds)
>
>I'd propose one change here, splitting this into two. "read" and "write"
>access. "read" covered most things except changing configuration and
>starting builds.

Absolutely, that¹s the end goal, although I am not sure if we'll manage
within 1.8. So for the 1.8 release we might end up with simple binary
access to projects, where if you have access you can do everything. We'd
then introduce more granular permissions during 1.9.

Cheers

Belén


>
>Cheers,
>
>Richard
>
>

Re: [RFC] Toaster access control

[Reyna, David]

Hi Belen,

Here is my take, and it is basically the same as before.

1) Your proposal is fine in the context of a community use of Toaster, for example within a relatively trusted network, especially if we are thinking about implementing this as the default Out-Of-Box access control system.

2) This would unfortunately not work in the context of professional system providers like Wind River and their customers, things that are of course far beyond the scope of normal Toaster.

  * Our customers will need have integration with their corporate access control, whether it is Unix-based, Radius, Active Directory, home grown, and so forth.

  * We have to be ultra-ultra-paranoid, because of potential of exposure of internal corporate resources, export control, legal liabilities, and tax law. There is real money on the line here.

  * We have to also worry about things like billing and provisioning, things beyond the scope of a community Toaster.

  
3) So let us discuss the balance of these needs

  * The access model should be above all modular so that it is relatively easy to substitute an alternate model. Commercial vendors will need this, plus we ourselves should be able to change our minds as some point.

  * We should have a default model so that there is out-of-box support, plus it acts as an example implementation that customers can build upon, and your proposal can be that model.

  * We need to have the hooks in the view classes to support the different models, specifically at the line level. They would be normally passive with the default model.

  * The vendors and/or customers would be fully responsible for their access model.

The above is exactly what we did with my old company Rapid Logic, which had a similar web-based product and a similar community verses customer model.

- David



> -----Original Message-----
> From: toaster-bounces@yoctoproject.org [mailto:toaster-
> bounces@yoctoproject.org] On Behalf Of Barros Pena, Belen
> Sent: Friday, October 24, 2014 8:38 AM
> To: toaster@yoctoproject.org
> Subject: [Toaster] [RFC] Toaster access control
> 
> One of the new features we are supposed to deliver in Toaster 1.8 is
> access control: i.e. the concept of users and permissions. This is the
> Bugzilla entry for the design
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=6233
> 
> I think there are basically 2 approaches we can take for access control:
> 
> 1. Top-down approach
> 2. Distributed approach
> 
> 1. The top-down approach
> 
> This is the approach where there is an all powerful administrator that
> creates users, grants them permissions and administers them. The all
> powerful administrator is the access gatekeeper. If you want to use
> Toaster you need to request access somehow. The all powerful administrator
> will (or will not) grant you access, and will decide what you can and
> cannot do in Toaster.
> 
> This is a very common approach: Bugzilla works like this. Moderated
> mailing lists work essentially like this. I believe Jenkins works like
> this too.
> 
> 2. Distributed approach
> 
> User management is a shared responsibility between all users who can
> create Toaster projects. Users are invited to join a particular project by
> the project creator. Project creators decide what the people they invite
> can do within that project and within Toaster.
> 
> This is the approach used by the Basecamp project management tool
> (https://basecamp.com/).
> 
> How both approaches compare?
> 
> * In the top-down approach, the fundamental unit for user management is a
> Toaster instance; in the distributed approach, the fundamental unit for
> user management is a Toaster project.
> 
> * The top-down approach requires a central place for user management that
> can only be accessed by the all powerful administrator(s). This central
> place is outside and above Toaster projects. In the distributed approach,
> user management takes place within a Toaster project.
> 
> * In the top-down approach, the user management task falls on the all
> powerful administrator(s). In the distributed approach, user management is
> shared between all project creators.
> 
> * The top-down approach is request-based: I must solicit access to Toaster
> to the all powerful administrator, who then decides which projects I can
> access and what I can do in Toaster. The distributed approach is
> invitation-based: the project creator invites me to access her project.
> 
> * In the top-down approach, there is normally one all powerful
> administrator and then a whole bunch of Toaster users. In the distributed
> approach, there are a whole bunch of project creators and a whole bunch of
> project users.
> 
> Which approach do I like best? The distributed one, of course. This is why:
> 
> 1. Because so far we have designed Toaster to be project based. For
> example, although there is a global layer list in the Toaster database
> that spans all projects, layers are only exposed in the context of a
> certain project. There are no Toaster pages outside of projects, apart
> from the landing page. The distributed approach to access control reflects
> this currently existing structure, which keeps things nice and simple.
> 
> 2. Because it avoids the need for a global administration interface. There
> are Toaster projects, and within a project you have a list of the people
> who have access to that project.
> 
> 3. Because it shares the responsibility of user management: no single
> person has to deal with this very annoying task. The responsibility is
> shared between all project creators.
> 
> 4. Because it makes user management easier: no need to deal with a list of
> a million users, and give each of them access to 50 projects. User lists
> are broken down by project, which means shorter lists. Project access
> granting happens organically, instead of in a single go. Inviting existing
> users to a project is easy because we keep a global list of users that
> spans all projects, even if we choose not to show it: typing a name should
> provide you suggestions from existing users, and you can select one of
> them or create a new one as needed.
> 
> 5. Because it avoids the need for sophisticated user management features,
> such as Active Directory integration (don't laugh:
> https://wiki.jenkins-ci.org/display/JENKINS/Active+Directory+plugin),
> which we are in no position to deliver.
> 
> But I am just the designer: what the hell do I know? So it would be good
> to find out which approach you prefer and why.
> 
> Thanks!
> 
> Belén
> 
> --
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster