Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Improving Hudson (was Why allowing Hudson to write to your downloads is a Bad Idea.)

On 09/14/2011 01:27 PM, Pascal Rapicault wrote:
I think everybody understands the possibilities/benefits of a CI system because they've experienced it at their companies but the one available at Eclipse is hard to work with

I seem to be missing the URL to your company's CI system... I searched a bit on Sonatype's site and using Google, but I couldn't find anything.

I'd like to poke around a little bit and see how you guys are set up.

Thanks.


because of the restrictions imposed. Your initial suggestion of reducing the ability to move files around, which IMO is fundamental to a build system, is just causing all these moments of pain dealing with hudson at eclipse to resurface.

At a time where the foundation is thinking of providing a common build infrastructure in the context of the LTS initiative, it seems that this decisions / recommendations are being at odds with the overall goal of making it easy to build at Eclipse (and fuel the discussions of continuing building things being corporate firewalls: the infrastructure is hard to work with and can't be trusted (this is the conclusion someone would get looking at this thread)).

At this point I don't have a particular solution to offer for the given problem and instead I'm proposing to start list of the "freedoms" committers need to have to be able to successfully leverage the infrastructure put in place. So here it is:
- Need to request creation of a build job. 
you trust me to write code and commit it but not to create a job
- Difficulties to follow the typical workflows of deploying from Hudson (be it a file system, or a maven repo)
Btw, the cron approach may ends up partially copying repos. Also it does not anyone to control the complete end to end build from Hudson.
- Inability to get a stack dump from a slave when the test are the build is stuck

HTH

PaScaL


On 2011-09-14, at 11:27 AM, Denis Roy wrote:

I never said anyone should do any of that. I never said you shouldn't trust the output of Hudson either.

I only suggested what is in the subject line of this email: allowing Hudson to write to your downloads is a Bad Idea.  And I explained why.

We simply got here for argument's sake.

Denis



On 09/14/2011 11:15 AM, Chris Recoskie wrote:

So... suddenly our builds will take days for someone to build it, grab it, test it, and promote it, and even then it's highly unlikely that they'd catch anything that a somewhat competent attacker would throw at us. There's no way anyone is going to take on this overhead.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

<unnamed.gif>Denis Roy ---09/14/2011 10:09:39 AM---On 09/14/2011 10:02 AM, Ed Merks wrote: > I agree with Doug.

<unnamed.gif>
From:
<unnamed.gif>
Denis Roy <denis.roy@xxxxxxxxxxx>
<unnamed.gif>
To:
<unnamed.gif>
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
<unnamed.gif>
Date:
<unnamed.gif>
09/14/2011 10:09 AM
<unnamed.gif>
Subject:
<unnamed.gif>
Re: [cross-project-issues-dev] Why allowing Hudson to write to your downloads is a Bad Idea.
<unnamed.gif>
Sent by:
<unnamed.gif>
cross-project-issues-dev-bounces@xxxxxxxxxxx





On 09/14/2011 10:02 AM, Ed Merks wrote:
      I agree with Doug.

      At no point have I seen anyone answer this question:
          What can be done manually to determine if what's produced by Hudson is compromised or not?
Off the top of my head:

1. run a build on a remote system and compare the pre-signed binaries.

2. run a past build and compare today's binaries with those in the past.

3. run a build and examine the execution trace.

4. run a build, run the executable and examine network output for unknown activity.


      I also have to question whether this change during the SR1 shutdown phase is appropriate timing...
Go download the latest Linux Kernel from Kernel.org and tell me if there is ever a more appropriate time than 'now' to discuss security.

Denis


      Regards,
      Ed


      On 14/09/2011 6:55 AM, Schaefer, Doug wrote:
          I'll come back to something Dave Carver mentioned yesterday. If we don't trust Hudson, then we shouldn't be using it, or at least should be wrapping it up in tighter security, like a VPN for example. If someone is going to do something malicious and they're smart, you're likely not going to be able to discover it. You have to cut it at the source.

          And is this not an issue other Hudson/Jenkins users have run into? What are they doing for security. Or do they trust Hudson as much as they do ssh.

          Doug.

          _______________________________________________

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

--
Denis Roy
Director, IT Services
Eclipse Foundation, Inc. -- http://www.eclipse.org/
Office: 613.224.9461 x224 (Eastern time)
denis.roy@xxxxxxxxxxx

EclipseCon
          Europe 2011

Back to the top