[guardian-dev] [Guardian-internal] Proposal: Public Jenkins

[David Oliver]

So, you DON'T want a "public Jenkins server".  What you want is "public
availability of the information that comes from our private Jenkins
server".  Why does that require a 2nd Jenkins server, indeed a "server" at
all?  Why can't it be just a webpage "here is what happened on our
full-paranoid Jenkins server today"?



David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
http://<http://olivercoady.com>
davidmoliver.com | http://dmo.tel | @davidmoliver | +1 970 368 2366


On Fri, Apr 12, 2013 at 3:06 PM, Abel Luck <abel at guardianproject.info>wrote:

> David Oliver:
> > Then I am unclear what Abel means at all.  Abel can you help this poor
> > elder understand?
> >
> > Abel: I think it's OK to have a public Jenkins server and here's a way
> > (plug-in) to make sure only we can edit the info
> > Hans: To ensure that only we can edit.  Jenkins is not the most secure
> > piece of software...
> >
> > What am I misunderstanding?
> >
>
> Sorry. Here's the breakdown
>
> 1. our new build box is our "Secure full-paranoid build server"
>
>    our source code and the binaries we compile it into is our lifeblood.
> Our users trust what we publish. We need to trust what we publish. We
> can trust what comes out of the secure build server.
>
> 2. Our secure build box is our private Jenkins instance
>
>    private because it directly handles our source code and binaries
>
> 3. the proposed public jenkins server would be a mirror of the
> _information_ contained in the private instance
>
>    While the private server handles our source code and binaries, it
> produces useful information that the world should know about (e.g., the
> build status of our projects)
>
> Using the plugin I mentioned, the pubic server would never actually
> touch our sourcecode nor our binaries, but merely mirror the information
> generated by the private server.
>
> ~abel
>
>
> >
> > David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
> > http://<http://olivercoady.com>
> > davidmoliver.com | http://dmo.tel | @davidmoliver | +1 970 368 2366
> >
> >
> > On Fri, Apr 12, 2013 at 2:56 PM, Hans of Guardian <
> hans at guardianproject.info
> >> wrote:
> >
> >>
> >> On Apr 12, 2013, at 2:51 PM, David Oliver wrote:
> >>
> >> 1. can we run the public one in the cloud somewhere instead of buying
> >> another short-useful-lifetime box to decorate our office?
> >>
> >>
> >> No one is talking about more hardware.  Abel wants to put it on the same
> >> host as dev.guardianproject.info, where redmine is installed.  It
> seems a
> >> natural place for it.
> >>
> >> 2. Jenkins builds our source code. We are open-source, so we have
> nothing
> >> to hide.  As Abel suggests, we only want certain people to edit (for
> which
> >> he has a solution).  Thus, why do we need a "full-paranoid" build
> server at
> >> all?
> >>
> >>
> >> To ensure that only we can edit.  Jenkins is not the most secure piece
> of
> >> software...
> >>
> >> .hc
> >>
> >>
> >>
> >>
> >> David M. Oliver | o <david at olivercoady.com>liver.david.m at gmail.com |
> >> http:// <http://olivercoady.com/>davidmoliver.com | http://dmo.tel |
> @davidmoliver
> >> | +1 970 368 2366
> >>
> >>
> >> On Fri, Apr 12, 2013 at 1:35 PM, Abel Luck <abel at guardianproject.info
> >wrote:
> >>
> >>> Heya,
> >>>
> >>> So our desire to be full paranoid wrt the build server is of course
> >>> justified, but conflicts up against our desire to be transparent in
> >>> our processes as well.
> >>>
> >>> None of the info in Jenkins is confidential, it's just sensitive, we
> >>> only want approved peeps to be able to edit it.
> >>>
> >>> There's no reason the info couldn't be exposed to the world read-only.
> >>>
> >>> Of course we don't want to expose the secure Jenkins publicly as that
> is
> >>> a huge attack surface.
> >>>
> >>> However, there is a plugin called Build Publisher Plugin
> >>>
> >>>  "This plugin allows records from one Jenkins to be published on
> another
> >>> Jenkins. The typical use case is for you to run builds within the
> >>> firewall, then send the results to another Jenkins which is facing the
> >>> outside world. "
> >>>
> >>> Proposal:
> >>> We run a public jenkins instance on the dev.gp.i box, that slurps up
> >>> data from the private secure jenkins.
> >>>
> >>> We could then also integrate jenkins with redmine [2], which will make
> >>> dev.guardianproject.info the foci of our development effors.
> >>>
> >>> Thoughts?
> >>>
> >>> ~abel
> >>>
> >>>
> >>> [1]:
> https://wiki.jenkins-ci.org/display/JENKINS/Build+Publisher+Plugin
> >>> [2]: http://www.r-labs.org/projects/r-labs/wiki/Hudson_En
> >>> _______________________________________________
> >>> Guardian-internal mailing list
> >>>
> >>> Post: Guardian-internal at lists.mayfirst.org
> >>> List info:
> https://lists.mayfirst.org/mailman/listinfo/guardian-internal
> >>>
> >>> To Unsubscribe
> >>>         Send email to:
> Guardian-internal-unsubscribe at lists.mayfirst.org
> >>>         Or visit: %(user_optionsurl)s
> >>>
> >>> You are subscribed as: %(user_address)s
> >>>
> >>
> >> _______________________________________________
> >> Guardian-dev mailing list
> >>
> >> Post: Guardian-dev at lists.mayfirst.org
> >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> >>
> >> To Unsubscribe
> >>
> >>        Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
> >>        Or visit:
> >>
> https://lists.mayfirst.org/mailman/options/guardian-dev/hans%40guardianproject.info
> >>
> >> You are subscribed as: hans at guardianproject.info
> >>
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130412/76e9f628/attachment.html>