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.

2011/9/13 Denis Roy <denis.roy@xxxxxxxxxxx>
On 09/13/2011 04:31 PM, Thomas Hallgren wrote:
On 2011-09-13 21:57, Denis Roy wrote:
If someone exploits Hudson, I doubt they are going to actually run your build job.  All they need to do is upload content and new checksums directly to the downloads area to replace your most recent release.  That would raise no red flags  :)

But does that matter really? Let's say all projects create some kind of promotion script that copies the Hudson output

If we assume that Eclipse Member companies are currently downloading your binaries from the Indigo release stream and packaging them into their commercial applications, then preventing Hudson from altering those Indigo binaries after-the-fact really matters.  I think it does, anyway.  If you disagree, I'd like to better understand how.

In my original email, I was suggesting that you perform some kind of validation that the build output you are about to copy is sane, where 'sane' can be as simple as 'weekly builds run at 10:00am on Wednesday, don't copy anything else'.

When Indigo was released, the Hudson build output wasn't just placed up for downloads without many eyeballs scrutinizing it.  This sanitization may not be required for nightly or weekly builds, but for official releases to be consumed by the general public, as a consumer I would be disappointed if projects didn't ensure their binaries were safe.

I think we have to trust Hudson and the plug-ins that we install.
Of course we do.  We also trust Linux, the Apache web server and all the other software packages that are on  But realistically, that doesn't mean those packages cannot be exploited in ways unknown to us today by someone, somewhere, who is just waiting for an opportunity to cause us harm.

If we don't, then we will need very thorough checks of all material that we promote to the download area at all times.

As Eclipse enters embedded, runtime and server markets, doing that would be a bad idea?  Does no one run a network sniffer to see if Eclipse, or any other software, is sending out random data to the world?  Surely I'm not the only one who periodically examines my personal network traffic to see what I'm saying...?

Just removing the ACL will not increase the security.

That is incorrect.  As I've explained, removing the ACL (ie, not allowing Hudson to write to the general downloads area at all) will limit the scope of any damage to that of a single committer's account running a publication process.  Since your publication process doesn't involve overwriting files created in the past, the beginning of any potential damage would be easy to discern and have a clear point-in-time.

Of course, if committers insist their promotion script simply copy $A to $B without any validation whatsoever, then we should just chmod 777 the entire downloads area and be done with it.  But if something breaks, don't ask me to fix it  :-)

All in all, this discussion illustrates that implementing a centralized publishing process would go a long way in solving these potential problems...

I think some of the problems discussed here could be solved following an approach
we are implementing at SAP:
  • for this approach we standardize on Maven/Tycho builds
  • inputs for the builds are: 
    • project meta data maintained in project portal (SAP proprietary Skalli version)
      • sub-project and module hierarchy
      • URL of source code repository
      • reactor pom
      • ...
    • source code repository 
    • binary artifacts stored in central maven repository (Nexus) 
  • CI builds run on a "CI Jenkins"
    • here projects can create and configure jobs as they need
    • installation of plugins and updates are done centrally
    • CI builds can use central "snapshot", "milestone" and "release" maven repository
  • milestone and release builds are run on a separate hardened "Release Jenkins"
    • "Release Jenkins" is firewall-ed to restrict the build to only have access to
      • source code: release branches of official source code repositories
      • binaries (approved 3rd party or from other projects): only those
        available in central "release" maven repository
    • only administrators have shell access to "Release Jenkins"
    • projects can generate release build jobs from project meta data maintained in project portal
      • these standardized release jobs have only few parameters to be filled in by
        the release engineers creating a release like release version etc. so there is no
        way to tweak what Jenkins does with their Maven build, if you want to change
        the build you must change sources in the repository
    • release build jobs do a scratch build on a clean vserver and record all used
      source and binary artifact versions into a "release build audit log"
    • they also run the tests and if successful tag the sources in the source code repository
      with the release version given by the release engineer who started the release build
    • release build job then deploys the release artifacts into the "release" maven repository
    • release reproduction build jobs can be generated from the release build audit logs which 
      can reproduce release builds using the exact same inputs as the original build
    • we plan to enhance this process with a staging process to enable multi-step
      validation of releases until they are finally released to customers


Back to the top