Hi,

To me Scorsh is starting to sound like a security nightmare, and an
information hog.

It also appears that nobody has taken a deep dive into understanding the
whole stack from gitlab issues through devuan-releasebot to jenkins and
jenkins-debian-glue. It's becoming a fools errand and is as it stands
looking entirely misguided.


Lets instead take a look at how it currently works.
- So to start off with, devuan-releasebot does 2 jobs. It sets the
jobs, and it triggers the jobs. Setting up the jobs consists of
providing a bunch of parameters and little snippets of script that are
laid on templates that make up the jenkins jobs. The builds themselves
various bits of script provided via jenkins-debian-glue that do the
actual work of building sources and packages. The built packages to are
deployed to the respective repo in the repo job that has a script that
signs and uploads the files to dak and then tells dak to get to work.

Devuan-releasebot doesn't store specific user, or job specific data. It
has fairly minimal configuration at the moment (although it could be
improved). There is no reason why devuan-releasebot couldn't gain other
methods to trigger it, so there's no hard tie to gitlab, except that's
the only input it has currently. Whilst the code is inelegant, it has a
pretty simple job and none of the required features for multi-repo setup
couldn't be easily added here.


Triggering builds using git commits/tags:

The scorch proposal is terrible in that it will leak potentially
sensitive information and clog up the list of git tags with build
requests with all manner of detail and information. This is an abuse of
tags and stupidity and will make developers scream in anguish when the
have to trawl through the maddening list of pointless git tags looking
for an actual release version.

The right way to do this is to add a plugin to either jenkins or
jenkins-debian-glue to validate the uploader that signed the commit or
tag (for release versions) and is either one of the maintainers or
uploaders in the control file, and that they are in the projects web of
trust. Jenkins already has the capability to watch for and start a
build based on a commit or tag, so it's only the committer authorisation
that is of concern and needs to be checked here. Anyone not listed as
can use the devuan-releasebot path to trigger builds. This would be a
trivial plugin to develop.

For setting the target repo's this would be done by adding a fairly
simple patch to devuan-releasebot to make it pass the repo type and
target for the setting up the repo-job.

So the configuration for repo-jobs is stored in the projects repo-job,
and the git commit triggered builds can be also added easily with better
security and without adding anything other then a pgp web of trust.

I simply don't see what scorsh would actually acheive that
devuan-releasebot and jenkins can't deliver with a few fairly trivial
patches...

Just my 2c

Dan.



On 20/07/17 21:33, Ivan J. wrote:
> Jaromil, Katolaz, and went over the status of jenkins builds briefly
> this morning on #devuan-dev IRC and I just wanted to recap here and see
> of others are fine with it and hear comments.
>
> From reading the devuan-releasebot source code I realize it's basically
> pooling gitlab for issues and holding the logic for different suites.
> scorsh is reimplementing this in a better way and I think once scorsh is
> finished, we can retire devuan-releasebot because it does only that and
> actually depends on Gitlab, whereas scorsh does not.
>
> Another thing is Jenkins and its logic to push the built packages.
> scorsh is able to recognize different distros and suites and probably
> able to communicate this to Jenkins. My question is: how does Jenkins
> become aware on where to push the built .deb files? Is this a part of
> Jenkins, or a Jenkins plugin, or something third?
>
>
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722