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

[Abel Luck]

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
>>
>>
>>
>