Please raise on legal-discuss or in a legal jira. On Mon, Dec 17, 2018 at 3:59 PM Naveen Swamy <mnnav...@gmail.com> wrote:
> 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 understand the legal lingo > > @Hen <bay...@apache.org> : Could you provide input to this? > > Thanks, Naveen > > On Mon, Dec 17, 2018 at 3:29 PM Davydenko, Denis < > dzianis.davydze...@gmail.com> wrote: > >> 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 whether it is OK from legal >> perspective to download CUDA by literally running wget during one of the >> jobs in publishing pipeline. The fact it is not available by just simple >> URL download raises concern: whether it is a protective measure from >> downloads by unauthenticated users or just inconvenience that has not been >> addressed by nVidia yet. >> >> [1]: >> https://lists.apache.org/thread.html/464712f0136fb51916ca9f1b702b99847e108dbdbd0b6a2b73fc91f1@%3Cdev.mxnet.apache.org%3E >> >> >> On 12/17/18, 2:48 PM, "kellen sunderland" <kellen.sunderl...@gmail.com> >> wrote: >> >> 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 >> (correct >> me if I'm wrong). >> >> To your second point, it shouldn't be too hard for us to maintain all >> the >> deps for our packages in Dockerfiles which are checked into source and >> built on a regular basis. To publish these artifacts I'd recommend >> doing >> this from a separate, secure environment. The flow I'd recommend >> would be >> something like: (1) Developers commit PRs with verification that the >> artifacts build properly on a continual basis from the CI. (2) In a >> separate, secure environment we do the same artifact build generation >> again, but this time we publish to various repos as a convenience to >> our >> MXNet users. >> >> On Mon, Dec 17, 2018 at 2:34 PM Qing Lan <lanking...@live.com> wrote: >> >> > 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 accessible. I am not sure how secure the restricted node >> is. >> > However, the only way I can think of from your end is to >> downloading all >> > deps in a single machine and run everything there (disconnected from >> > internet). It would bring us the best security we have. >> > >> > Thanks, >> > Qing >> > >> > On 12/17/18, 2:06 PM, "kellen sunderland" < >> kellen.sunderl...@gmail.com> >> > wrote: >> > >> > 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 >> > code from the internet. It is a real possibility that an >> attacker >> > could >> > pivot from any Jenkins based CI system to infect artifacts >> which would >> > then >> > potentially be pushed to repositories our users would consume. >> I would >> > consider any system using Jenkins as insecure-by-design, and >> encourage >> > us >> > to air-gapped any artifact generation (websites, jars, PyPi >> packages) >> > completely from a system like that. >> > >> > An alternative I could see is a simple Dockerfile (no Jenkins) >> that >> > builds >> > all artifacts end-to-end and can be run in an automated account >> well >> > outside our CI account. >> > >> > On Mon, Dec 17, 2018 at 1:53 PM Qing Lan <lanking...@live.com> >> wrote: >> > >> > > 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. Sheng has >> > provided a >> > > script here: >> https://github.com/apache/incubator-mxnet/pull/13646. >> > This >> > > provide a very concrete and automatic solution from >> downloading to >> > > installing on the system. The only scenario we are facing is: >> It >> > seemed >> > > NVIDIA has a restriction on distributing CUDA. We are not >> sure if it >> > is >> > > legally-safe for us to use this in public. >> > > >> > > We would be grateful if somebody has a better context on it >> and help >> > us >> > > out! >> > > >> > > Thanks, >> > > Qing >> > > >> > >> > >> > >> >> >> >>
