Re: [cross-project-issues-dev] Why allowing Hudson to write to your down

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

So, while we wait around for a full on build to publish architecture
to be assembled...what do we do in the meantime.

The message here appears to be 'Do not trust anything out of Hudson.
period.  full stop.'

With that in mind, do we cancel the SR1 indigo release now?  If we
can't trust anything out of Hudson then its doomed at this point.

Lets see, we can start from scratch, we can contribute most of the
jetty contribution to Indigo.  We can't use the bundles that we have
signed with the eclipse public key because that was done on hudson,
but we can trust the ones in maven central cause those are all built
by me, on my machine using my private key, with full checksums and
whatnot on the key file and the binaries, and source bundles, javadoc
bundles, etc.  Unless my machine has been compromised...

Did something happen that we don't know about with hudson?  Its not
clear, was eclipse.org attacked and the hudson instance compromised?
If so should the eclipse signing key be revoked now?  How much of this
thread is academic and how much is in response to an actual threat as
opposed to perceived general one?

If it is academic, then can we decide at what point in time we have
trust in what has been produced and work up from there to address
these issues?

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Wed, Sep 14, 2011 at 09:30, Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx> wrote:
> This thread is a getting a little long and a little confrontational, which
> is unfortunate. Obviously, good security is paramount, but it needs to be
> achieved in a manner that doesn’t place unreasonable burden on projects. It
> should be recognized that it is unreasonable to expect every project to have
> someone with SSH, cron, ACL, security, etc. expertise. Frankly, the only way
> we will ever have a secure build-to-publish process is if it isn’t in the
> hands of individual projects. The only thing that committers should have
> access to is the source code repository. If the build-to-publish process is
> provided by eclipse.org it can be secured as necessary and there will be no
> risk that the projects will open security holes.
>
>
>
> - Konstantin
>
>
>
>
>
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer,
> Doug
> Sent: Wednesday, September 14, 2011 7:18 AM
>
> To: Cross project issues
> Subject: Re: [cross-project-issues-dev] Why allowing Hudson to write to your
> downloads is a Bad Idea.
>
>
>
> 1 optimizes to “don’t use Hudson”.
>
>
>
> 2 and 3 require deeper understanding than I think any project has of their
> code or have the resources to do. Sounds like patterns a secure JVM could
> detect, assuming there is such a beast.
>
>
>
> 4 isn’t very reliable since the malware could wake up 6 months from now. And
> the user’s firewall should be covering that.
>
>
>
> Understanding the security weaknesses of Hudson (versus ssh at least) would
> be helpful to this discussion. Then we could figure ways to mitigate those.
>
>
>
> :D
>
>
>
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Denis Roy
> Sent: Wednesday, September 14, 2011 10:09 AM
> To: Cross project issues
> Subject: Re: [cross-project-issues-dev] Why allowing Hudson to write to your
> downloads is a Bad Idea.
>
>
>
> 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
>
>