Hi,
sorry for derailing the discussion another time (I'm slow to respond,
sorry) but I just wanted to give a little statement about the security
aspect of Jenkins.
Kellen is right that Jenkins is by its nature quite insecure due to the
high frequency of discovered security vulnerabilities. These
Attempting to answer Qing's question
--
If you can digest the legal terms:
https://docs.nvidia.com/cuda/eula/index.html#distribution-requirements.
It sounds its OK("
1. Your application must have material additional functionality, beyond
the included portions of the SDK.")
but I not don't
Kellen, please see conversation [1] on previously published proposal re: maven
publishing pipeline. I think your concerns are valid and we should look into
security aspect of running our CI on a broader scope, not bound to just
artifact publishing.
I believe right now Qing's question is
Restricted nodes may provide enough security for some use cases, but in my
opinion they don't provide enough for artifact publishing. An example would
be if there were a exploit available that worked against a Jenkins master.
In this case I think an attacker code still pivot to a secure node
Hi Kellen,
Firstly the restricted node is completely isolated to the PR-checking CI system
(physically) which is explained in here:
https://cwiki.apache.org/confluence/display/MXNET/Restricted+jobs+and+nodes.
What you are mentioning: the Public CIs are all having troubles if they are
public
I'm not in favour of publishing artifacts from any Jenkins based systems.
There are many ways to bundle artifacts and publish them from an automated
system. Why we would use a CI system like Jenkins for this task? Jenkins
frequently has security vulnerabilities and is designed to run arbitrary
Dear community,
Currently me and Zach are working on the Automated-publish pipeline on Jenkins
which is a pipeline used to publish Maven packages and pip packages nightly
build. We are trying to use NVIDIA deb which could help us to build different
CUDA/CUDNN versions in the publish system.
