OpenSCA知识小课堂开课了!
今天主要介绍基于composer包管理器的组件成分解析原理。
composer是PHP的依赖管理工具。
开发者受到Node.js的npm及Ruby的bundler启发,composer设计上与两者有诸多相似。
composer的依赖管理文件是composer.json。开发者可以在composer.json中指定每个依赖项的版本范围或使用composer require/update/remove ${name}命令管理依赖项。
如果一个项目中存在composer.json文件,便可以执行composer install命令自动安装当前项目所需的依赖项并生成composer.lock文件
composer.json完整文件结构如下:
{
"name": "cakephp/app",
"type": "project",
"license": "MIT",
"require": {
"php": ">=7.2",
"cakephp/cakephp": "^4.3",
"cakephp/migrations": "^3.2",
"cakephp/plugin-installer": "^1.3",
"mobiledetect/mobiledetectlib": "^2.8"
},
"require-dev": {
"cakephp/bake": "^2.6",
"cakephp/cakephp-codesniffer": "^4.5",
"cakephp/debug_kit": "^4.5",
"josegonzalez/dotenv": "^3.2",
"phpunit/phpunit": "~8.5.0 || ^9.3"
},
}
其中name为项目名称;type为包的类型,有library、project、metapackage和composer-plugin四种类型,默认情况下为library;license为项目声明的许可证,可以是一个字符串或是一个字符串数组。
require-dev为开发环境或测试使用的依赖,require为生产环境使用的依赖,依赖写法为"name":"version",版本可以指定准确版本或一个范围。
composer.lock
composer.lock文件为自动生成的文件,可以准确定位到PHP项目使用的依赖及版本,所以优先解析composer.lock文件。
composer.lock文件结构如下:
{
"packages": [
{
"name": "a",
"version": "1.1.0",
"require": {
"c": "1.1.*"
}
},
{
"name": "b",
"version": "1.2.2",
"require": {
"c": "^1.0.2"
}
},
{
"name": "c",
"version": "1.1.2"
}
],
"packages-dev": []
}
其中packages和packages-dev字段包含项目使用的所有直接和间接依赖,而且记录了组件间的依赖关系,packages为生产环境的依赖,packages-dev为开发环境的依赖。
示例:
{
"name": "a",
"version": "1.1.0",
"require": {
"c": "1.1.*"
}
}
代表项目依赖1.1.0版本的组件a,且该组件依赖版本约束为1.1.*的组件c。
同理可知项目依赖1.2.2版本的组件b,且该组件依赖版本约束为^1.0.2的组件c。
且组件a和组件b都没有被其他依赖所依赖,所以可知这两个组件是项目的直接依赖。
注:
1.1.*代表版本号需要>=1.1.0且<1.2.0
^1.0.2代表版本号需要>=1.0.2且<2.0.0
由此可以构建出当前项目的依赖结构:
实线代表直接依赖,虚线代表间接依赖
composer.json
composer.json为开发者管理的依赖管理文件,在未找到composer.lock文件时将解析该文件。
composer.json仅包含直接依赖,在项目构建时会从composer仓库下载需要的间接依赖并构建为composer.lock文件,因此可以模拟composer构建流程来获取项目引用的组件依赖。
composer.json文件结构如下:
{
"name": "foo",
"type": "project",
"license": "MIT",
"require": {
"a": "^1.1.0",
"b": "^1.2.0",
},
"require-dev": {},
}
require为项目实际使用的直接依赖,require-dev为项目开发时使用的直接依赖。
例如:
"a": "^1.1.0"代表项目依赖版本约束为^1.1.0的组件a。
"b": "^1.2.0"代表项目依赖版本约束为^1.2.0的组件b。
分析到这里我们可以总结出如下图依赖关系:
实线代表直接依赖
通过该依赖关系可以看出项目组件的直接依赖及组件的版本范围,但无法得知组件依赖的具体版本。
在没有composer.lock文件的情况下,为了进一步获取依赖的准确版本及间接依赖,需要从composer仓库下载对应组件的详细信息。
例如组件a的详细信息结构为:
{
"packages": {
"a": [
{
"version": "1.0.1",
"require": {
"c": "^1.0.0"
}
},
{
"version": "1.1.0",
"require": {
"c": "^1.1.0"
}
}
]
}
}
其中packages字段为组件及各个版本信息的映射,require字段为组件的依赖信息。
对于本例来说,组件a的约束为^1.1.0,要求版本号>=1.1.0且<2.0.0,所以选择1.1.0版本。
因此组件依赖结构就变成了:
按照这种方式层级解析便可获取整个项目的依赖信息。
感谢每一位开源社区成员对OpenSCA的支持和贡献。
OpenSCA的代码会在GitHub和Gitee持续迭代,欢迎Star和PR,成为我们的开源贡献者,也可提交问题或建议至Issues。我们会参考大家的建议不断完善OpenSCA开源项目,敬请期待更多功能的支持。
OpenSCA官网:
GitHub:
https://github.com/XmirrorSecurity/OpenSCA-cli/releases
Gitee:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。