While we're in a security-conscious frame-of-mind...
Many projects allow the Hudson user account to write to their
download directories. Projects use one of these two ways to do
this:
1. They add an ACL on their download directory that allows the
Hudson Build user to write there.
2. They chmod 777 their downloads directory, thus allowing everyone
full access to their downloads directory.
Most of you understand that #2 is a clear violation of any kind of
security we hope to maintain here at Eclipse. Don't do it.
Please ask us for alternatives.
While #1 may seem like a better option, it has implications.
Allowing Hudson to alter downloads means that other committers can
alter your downloads via a Hudson job. I am not worried about this
since I trust our committers.
The issue is about trusting a public-facing application
(Hudson)
and all its plugins, each of which may contain security
vulnerabilities. If unauthorized control of Hudson was achieved,
downloads could be replaced with compromised ZIP and JAR files.
As Hudson can sign on behalf of the Eclipse Foundation, compromised
downloads would appear authentic with digital signatures and valid
checksums. A keystroke logger could leak sensitive credentials to a
third party. This is how unauthorized root access begins.
Far-fetched? Not at all.
The above is not a stab at Hudson, Winstone or any other specific
software -- all software may contain a vulnerability, including the
Apache webserver and the Linux Kernel.
Hence, I strongly recommend you use a promotion job on
build.eclipse.org which publishes known-good content from Hudson. A
simple script which reads a state from Hudson, runs some sanity
checks and wget's files and saves them in the downloads directory is
a great start.
I appreciate your taking the time to read this. My goal is not to
encumber you with senseless, counter-productive dogma, but to strike
a balance between security and convenience... with a slight bias
towards security :-)
Denis
|