Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

功能建议 : 可以是用git地址直接安装 #45

Open
zzhgithub opened this issue May 27, 2019 · 3 comments
Open

功能建议 : 可以是用git地址直接安装 #45

zzhgithub opened this issue May 27, 2019 · 3 comments

Comments

@zzhgithub
Copy link

这里看到 raven 基本比较类似 node的npm.
但是我觉得应该 支持像npm 一样直接通过 git地址直接安装 之后在后面加上一定的参数。 这样有两个好处。

  1. 方便开发者本地测试库的行为。当然这里指的是复杂的调用。当然如果分离模块后进行测试,是不需要 用户在raven install 一次再测试的。 但是实际业务代码中很有可能出现了,写好了觉得没有问题后已经发生问题的情况。(当然 如果有一种 类似maven安装 可以本地mvn install 就安装到本地的方法就更好了。)
  2. 不需要用户 过分依赖官方库。这样其实是更加自由的。应该让他们按照raven的标准去开发和使用,但是不用为他们写的“垃圾”代码买单。 我是说:允许他们畅通无阻的使用 raven 官方的库,只要慢慢的审核他们的提交请求就好了。

我看了项目的源码。希望支持这一特性,但是我并不清楚您是否认同上面的观点和特性。所以并没有开始添加功能的工作。我发现这里的代码
image
中 入参和调用的位置要进行改造。 还有 在package.cs文件中的定义方式和install 参数的方式也要改造。任务是个我不能决策的改动所以来征求你的意见。如果你打算实现那么太好了。期待你的回复。

@guenchi
Copy link
Owner

guenchi commented Jun 5, 2019

这是一个很有意义的提议:

但是存在一些担忧:

Raven是存在一定的系统调用功能的,那么当安装第三方地址的库,也就是说未经过严格审核的代码,会导致一定的安全问题。

这些问题包括但不限于:

Raven官方认为,如果你使用git地址,但并不是官方仓库时,代表你了解其中隐含的安全问题。而你必须自己为这些问题负责。

但不一定每一个Raven的用户,都非常清楚以上的约定。他们其中一些人,比如说一些比较新的用户,默认Raven的安装是安全的。而另一些用户也许在安装时,因为某种情况忽略了这个安全提示。

还有一种更大的可能是,也许使用者严格的审核了导入的代码,但是在后续的更新中,git合并了不安全的代码。同时由于Raven的自动更新机制,这些不安全的代码被无意的导入了。

当库进行嵌套时,这个问题变得愈发严重。

开发者并不一定清楚它的依赖的依赖的依赖...到底引用了一个什么东西,在这种情况下,要求每个库使用者进行严格的代码审核是一项不可能的任务。

即使是NPM,也遭到了黑客的渗透攻击,那么,从git引入库结果可能更糟。

在这个环境下,进行官方的严格代码审核在我看来是很有必要的一件事情。

我没有完全拒绝社区提议的这种方式,但我认为,在未解决我提出的安全问题之前,这个更改还需要探讨。

@zzhgithub
Copy link
Author

感谢你的回复:
我想我明白你的意思了。很遗憾我在之前安全上没有深入考虑。

我不了解Raven现在对于提交上来的库的审核进度和具体情况。如果都进行审核我相信也是很大的工作量。所以我还是建议使用一定的折中方案。

  1. 保证官方库了的包和他们的依赖都是被审核了的。也就是说官方认可的包都不会在dependencies里出现直接从git地址上的依赖。这样就可以保证官方库的安全纯净。(也就是说在提交到官方库的代码审核时 如果出现了直接依赖git上地址的库直接打回去或者等待它依赖的库被审核通过)
  2. 让用户可以使用自己还是可以安装自己的git包。并且保证git包的依赖和官方的库不一样。
  3. 一旦用户使用了用git地址的依赖,在install的时候应该给出一个明确的提示。

或者这种方案可以兼容安全和和我说的需求呢?

最后无论如何感谢你在scheme生态建设上提供的帮助。

@guenchi
Copy link
Owner

guenchi commented Jun 6, 2019

感谢你的回复:
我想我明白你的意思了。很遗憾我在之前安全上没有深入考虑。

我不了解Raven现在对于提交上来的库的审核进度和具体情况。如果都进行审核我相信也是很大的工作量。所以我还是建议使用一定的折中方案。

  1. 保证官方库了的包和他们的依赖都是被审核了的。也就是说官方认可的包都不会在dependencies里出现直接从git地址上的依赖。这样就可以保证官方库的安全纯净。(也就是说在提交到官方库的代码审核时 如果出现了直接依赖git上地址的库直接打回去或者等待它依赖的库被审核通过)
  2. 让用户可以使用自己还是可以安装自己的git包。并且保证git包的依赖和官方的库不一样。
  3. 一旦用户使用了用git地址的依赖,在install的时候应该给出一个明确的提示。

或者这种方案可以兼容安全和和我说的需求呢?

最后无论如何感谢你在scheme生态建设上提供的帮助。

我和你的想法差不多:

  1. 提供 --url / -u 选项 方便直接从git库地址安装。
  2. 当使用这个选项时,检测用户是否使用了root/sudo,如果是,强制中止并提示用户使用非root模式安装。
  3. 这个选项与 -g选项不兼容。也就是只能安装到当前文件夹的lib文件下。
  4. 当使用这个选项时,用红字警告用户,应在安装前验证源是否含有恶意代码,并需要用户输入 Y/N 的方式才能继续。
  5. 此选项下载完成 可以考虑自动makefile 或者不。需要讨论。
  6. 在使用此选项时,无法递归的下载依赖的依赖(如果此依赖也是一个git地址)。也就是说,无法自动下载依赖(git地址)。换句话说,所有发布或未发布到官方源的库,它自身的依赖必须是官方源,而不能依赖另一个git地址。

欢迎实现和PR。如果你觉得在如此严苛的限制下,还有必要的话。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants