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

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


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/c48ec778/attachment.html>