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
We simply got here for argument's sake.
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.
Team Lead, IBM CDT and RDT
Roy ---09/14/2011 10:09:39 AM---On 09/14/2011 10:02 AM, Ed
Merks wrote: > I agree with Doug.
On 09/14/2011 10:02 AM, Ed Merks wrote:
Off the top of my head:
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?
1. run a build on a remote system and compare the pre-signed
2. run a past build and compare today's binaries with those in
3. run a build and examine the execution trace.
4. run a build, run the executable and examine network output
for unknown activity.
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.
I also have to question whether this change
during the SR1 shutdown phase is appropriate timing...
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.