如何在高度受限的 Azure DevOps Pipeline 环境中使用与驱动程序相关的 CLI 来创建驱动程序?

How to use driver-related CLIs for driver creation in a highly restricted Azure DevOps Pipeline environment?

我正在将一些 Jenkins 构建移植到高度受限的 ADO 管道环境中。在制作一些 CAT 文件时,使用了 MakeCAT utility was being used and when verifying INF files the InfVerif 工具。在我们公司高度受限的 ADO 环境中,我似乎无法在工作构建目录之外的任何地方直接访问工具,并且被告知不会有任何妥协。

我能想到的最好办法是直接将文件及其依赖项下载为安全文件,并将每个所需工具的工具目录组合在一起。这是一个肮脏的 hack,并且在使用工具许可的情况下绕过合法的灰色区域,所以我不喜欢这种方法。但这就是说我使用 DUMPBIN /IMPORTS 来查看每个相应的工具需要哪些:

InfVerif.exe:

    msvcrt.dll
    ntdll.dll
    api-ms-win-core-libraryloader-l1-1-0.dll
    KERNEL32.dll
    VERSION.dll
    ADVAPI32.dll

MakeCAT.exe:

    msvcrt.dll
    KERNEL32.dll
    WINTRUST.dll
    USER32.dll

在创建驱动程序和驱动程序相关文件时,我们希望在具有这些限制的 ADO 管道中使用什么?我不介意使用替代工具,只要它能实现完全相同的目标。

ps:我继续复制每个工具目录中的所有 DLL 并播放“删除 DLL,直到此工具开始损坏," 以缩小实际需要在本地系统上打包的范围。 InfVerif 不需要额外的 DLL,MakeCAT 只需要添加 wintrust.dll。请注意,这仅限于我们自己对每个工具的使用,您的使用可能与我们的不同,并且需要额外的依赖项来打包。

一般来说,构建代理的要点是 运行 作业利用代理的功能来创建构建。

要求开发人员self-package将每个依赖项放入管道并将可执行文件和 dll 拼凑在一起以用于通用 SDK 工具,这将是相当晦涩的。

大概这些构建代理安装了 .NET SDK 之类的东西供构建使用。这也不例外。您应该要求管理构建代理的团队安装相关的 SDK,并确保路径已配置且可用于构建代理。

(例如构建代理中的 echo PATH 应该包括安装这些 SDK 的目录)

要求开发人员签入打包的 exe 和 dll 更有安全风险。谁知道他们来自哪里,是否安全?