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.
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
