setup.py downloads possibly evil file via unsecured connection

[sils]

I got this comment on my blog recently:

Interesting project! Just one minor issue: Why has setup.py code in it to download a jar file? What is supposed to be in the file? If it is free software, why not use its source code and compile it? Why download it over unsecured HTTP? Is the content not relevant? Thanks!

And I think we should think about that. We're downloading checkstyle.jar there which shouldn't be evil. Compiling it from source though sounds like to be avoided IMO.

[AbdealiLoKo]

Bear binary would solve this to some extent.

On Thu, Feb 11, 2016 at 7:10 PM, Lasse Schuirmann notifications@github.com
wrote:

I got this comment on my blog recently:

Interesting project! Just one minor issue: Why has setup.py code in it to
download a jar file? What is supposed to be in the file? If it is free
software, why not use its source code and compile it? Why download it over
unsecured HTTP? Is the content not relevant? Thanks!

And I think we should think about that. We're downloading checkstyle.jar
there which shouldn't be evil. Compiling it from source though sounds like
to be avoided IMO.

—
Reply to this email directly or view it on GitHub
#1410.

[sils]

Yes that is related though it only moves the problem to some other script.

[Makman2]

To solve that cleanly imo we have two options:

1. Don't download the .jar, implement prerequisites for the bear to require the .jar and java. If it's not installed it's the users fault and he needs to install the packages on his platform himself. Since we don't install java itself on that way, this would be a viable solution.
2. If we want to install the .jar anyway over our setup, we need some python-platform-cross-dependency mechanism that matches the according package on the used platform and installs/references/... it. But this would be problematic inside windows...

I consider the sourceforge link in our setup.py trusted source (even without secured connection). So I would say this bug has low priority and as @AbdealiJK states we will move someday bears to an own package/repository where we could concentrate more on that dependency handling.

[sils]

This issue was moved to coala/coala-bears#48