Skip to main content

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

BTW, Just found a talk by Kohsuke on Jenkins/Hudson security. The last part of it talks about these issues.




From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ed Merks
Sent: Wednesday, September 14, 2011 10:27 AM
To: cross-project-issues-dev@xxxxxxxxxxx
Subject: Re: [cross-project-issues-dev] Why allowing Hudson to write to your downloads is a Bad Idea.



Comments below.

On 14/09/2011 7:09 AM, Denis Roy wrote:

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.

Compare binaries? Builds often produce different results because some aspect of a time stamp is encoded in the build result, e.g., the qualifier...  (Eike was telling me that his Javadoc build produces different results from time-to-time when applied to the same source.)

Getting one build working is already a huge challenge getting two producing identical results.  Have fun release engineers....

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

Same problem as before.  We do expect each build to be different.  So this suggestion comes down to replicating builds such that they produce identical results and then relying on the replicas having different security characteristics such that they won't both be compromised in the same way.  It's a nice idea, but, good luck to the release engineers on that one...

3. run a build and examine the execution trace.

I can feel my brain overflowing and numbing just at the thought of this.

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

When I hack it, I'll make sure it doesn't do anything until the 10th time someone runs it, or until the next leap day, or at a random point in the future.

I also have to question whether this change during the SR1 shutdown phase is appropriate timing...

Go download the latest Linux Kernel from and tell me if there is ever a more appropriate time than 'now' to discuss security.

No, but it's still a reasonable question.  In the end, it's all about balancing risks and so intelligent people will differ in their opinion.



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.

cross-project-issues-dev mailing list

Back to the top