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

[Lee Azzarello]

Jenkins renders web pages with information about what happened on our
full-paranoid Jenkins server today. So yes, I think we'll have a
webpage as the end result. Anyone on the web can read it.

-lee

On Fri, Apr 12, 2013 at 3:12 PM, David Oliver <oliver.david.m at gmail.com> wrote:
> 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 | oliver.david.m at gmail.com | http://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
>> >>
>> >>
>> >>
>> >
>>
>
>
> _______________________________________________
> 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/lee%40guardianproject.info
>
> You are subscribed as: lee at guardianproject.info
>