On Thu, Dec 19, 2013 at 10:40 AM, Henry Saputra <henry.sapu...@gmail.com> wrote:
> So the point of concern is the "external" jars, but jars that are
> generated by the project itself (for example for tests) should be
> fine?
One main concern is oversight for what goes into an an Apache release.
It's not realistic to perform a line-by-line review for all source code in a
release candidate, but if we trust our version control and our commit
notification systems, we can have confidence that the what goes into a release
has been reviewed over time by the PMC. Checking that the expanded content of
the source archive matches an export from a version control tag is a useful
(albeit not universally appropriate) way of verifying that the release is what
it says it is.
A compiled binary, on the other hand, is an opaque product of source code plus
build environment. It can't be reviewed, and the build machine is potentially
a target for crackers.
Hence, these quotes from Roy:
http://s.apache.org/roy-binary-deps-2
I consider them to be trojan horses. I wouldn't hesitate for a second
to delete them outright. Actually, what I've done in the past (yes,
I have done this before) is move them to a subdir of my homedir and
then tell the relevant project to WTFU and do it right. Note, however,
I would not delete the ones in archive -- that would be silly.
http://s.apache.org/roy-binary-deps-3
People have to understand this. There will always be a role for
downstream commercial or non-commercial redistributions of Apache
products. Why? Because the ASF is incapable of taking on the enormous
liability associated with released binaries that are not produced in
a controlled environment with a controlled set of tools.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
