Dear Daniel, thanks for your series of questions. Please find my
replies and comments in-line below:

> ## Centurion Dan
> It feels to me like we have a number of key issues in play:
>
> 1) How to allow other distributions to use our CI system without
> compromising on security? To me there are several factors to consider:

there is no need to compromise in security at all. With good design
and cryptographic security (not just by convention). Recent
developments proposed by Katolaz are going into the direction of
improving current security and documentation of ACL changes.

>      a) What benefit does hosting each of these other distributions
> bring to Devuan and does that benefit offset the cost of resources
> required to provide the systems including developer/admin/training
> time?

the benefit is that of growing the developer community and helping
very important distributions as the neo900 by sharing infrastructure

this was already negotiated long ago

>      b) Do we allow them to cherry-pick our resources - ie use jenkins
> without requiring them to use git.devuan.org (because gdo currently
> provides permissions to authorise actions on jenkins)?

right now there is a majority of developers willing to scale down the
dependencies of Devuan's CI to bare Git, to which it can be applied
any frontend later.

>      c) Will their use of our CI system constrain our ability to further
> develop/enhance/augment our CI system?

I don't believe so, but that's an important question.

We may want to arrange a disclaimer about future changes and liability.

>      d) How do we arbitrate potentially scarce resources (ie buildhosts)
> when there is competition for those resources (think when urgent
> security updates need to be built and another project has queued up a
> massive number of jobs?  (_Currently we don't but jenkins does have the
> capability, to set constraints on a per user/group basis for number of
> running builds etc but some time would be required to consider and set
> this up)?

well, you answered this in your note. I believe that we can greatly
grow the buildhost base and at Dyne.org we do have plans to greatly
extend them through contacts we have in both private and public
sector organisations.

>   2) How to make triggering builds in the CI system easier then it is
>      now?

with a simple script that can upload the build, a'la 'debuild'

> 3) How to provide finer grained (ie per suite) build permissions?

This is answered by Katolaz' RFC

>   4) Is there a real security vulnerability with gitlab that makes it a
>      now unwise to continue to use as the federated authentication
>      provider for our git and CI, and Devuan as a whole system?

I believe there is no other way but Evilham disclosing the
vulnerability he has found (thanks for noticing).

> **With respect to the scorsh proposal:
>
> I'll agree that scorsh as designed provides a solution to some of
> these stated problems, but I believe it does so at the cost of
> transparancy, and adds significant complexity and ignores the bigger
> picture beyond just building packages

transarancy is not sacrificed! maybe you wanted to use another term,
indicating that scorsh requires knowledge of git for its usage (which
is mildly false, since it has script wrapping its functioning) and
that it requires knowledge of Go to read its code (which is rather
trivially understood by any programmer knowing C, IMHO)

> **My concerns about scorsh based on it's DPI/RFC:**
>
> - Scorsh has it's own user database that is not representative of the
> existing user database in gitlab. This is problematic as users will
> need to be administered in 2 places.

This is intentional and can be mitigated with a migration of
permissions. We do not want our ACL to depend from records in a DB,
but from cryptographic keys in possession of developers.
This is what I mean by security by convention vs. cryptography.

> ** A possible solution is that scorsh provides an OAuth integrated
> website to allow users to manage their own PGP/GPG keys. **

*LOL*

>   - Scorsh adds a separate permissions system for authorisation - one
> which is entirely disconnected and doesn't respect any of the existing
> gitlab federated permissions.  This means we will have two separate sets
> of permissions to authorise:
>   a) who can upload to git.d.o on a project and branch level
>   b) who can build the package of a project for a suite
>   _ To me there is no reason to differentiate who can commit to
>     suites/jessie and who can build suites/jessie.  If we don't trust
>     the committers commits to be built they shouldn't be directly
>     committed to that branch._

ditto. two answers above.

>

>   ** A solution to this will be to make scorsh use gitlabs permissions
>     (available via the api) to ensure anybody that can push to a branch
>     in gitlab also can trigger the build of that package.  This obviates
>     implementing the user self management of their own keys as suggested
>     above. **

ditto.

>   - The Scorsh design requires a refactored version of releasebot that:
>   i) bypasses releasebots usual permissions model - because scorsh
>      implements it's own
>   ii) potentially requires different templates for other distributions
>      and thus requires adding code to select those different templates.
>      __+ this probably means a fork of releasebot is required, resulting
>     in both duplication of function and risk that templates diverge.
>     Thus a job add or modification in scorsh results in a different
>     jenkins job config to that which is provided by gitlab triggered
>     action.__

as specified previously by Katolaz, the releasebot script can be
triggered by scorsh but is not substituted.


> **Thoughts on Refactoring Releasebot to solve these problems:

Can you please let us know if these thoughts are also Nextime's? I'd
like to know if we have two or three different proposals objecting to
scorsh.

> Adding additional build permissions level "Developers" to allow
> building suites *-proposed* and experimental: _ this is low
> hanging fruit, requires a simple permissions test function and
> another if statement. I can provide this by the weekend

ok, please do it in a branch of the current Git.

Given the current empasse we cannot accept that some developers are
working directly on the production system without reviewing their
code. This is a mandatory condition for any changes to the
infrastructure right now, breach of this condition will erode any
trust in place for this process.

Said that, I'm fine with having another proposal analysed and
ultimately from a position of a security researcher to me is just
enough to put forward the argument of having security by cryptography
of by convention (a flag in a db). Therefore I stand by Katolaz'
proposal, subject to revision by anyone else following.

I'll be reading other proposals, still personally worried that this
process is not really helping to leverage new developers participation
and expertise we need.

ciao