技术文档 | OpenSCA技术原理之composer依赖解析

OpenSCA知识小课堂开课了!

今天主要介绍基于composer包管理器的组件成分解析原理。

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官网:

https://opensca.xmirror.cn/

GitHub:

https://github.com/XmirrorSecurity/OpenSCA-cli/releases

Gitee:

https://gitee.com/XmirrorSecurity/OpenSCA-cli/releases

你可能感兴趣的:(php安全开源)