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.

+1 to Ed's comments

We can only mitigate the security risks to a reasonable extent.  When we start compromising our ability to do our jobs and produce builds for our consumers due to very expensive overhead of verifying each that each build has not been compromised, we might as well stay home.

It's similar to the risk of dying in a car accident.  It's a 1 in 4000 lifetime risk (See  We wear seatbelts and cars are equipped with air bags to reduce this risk.  Nevertheless, deaths still happen, but we accept the small probability of risk for in return for the reward of convenient travel.

Yes, it's unfortunate that other open source sites were hacked.  But if our fear of being hacked means that our processes grind to a halt, the hackers have attacked us too.


From:        Ed Merks <ed.merks@xxxxxxxxx>
To:        cross-project-issues-dev@xxxxxxxxxxx
Date:        09/14/2011 10:28 AM
Subject:        Re: [cross-project-issues-dev] Why allowing Hudson to write to your downloads is a Bad Idea.
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx


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
cross-project-issues-dev mailing list

Back to the top