Why Software Supply Chain Security is important?

Software supply chain security is the act of securing the components, activities, and practices involved in creating software.

Attacks in the software supply chain have become more and more frequent in recent years, SonaType reported more than 700% of attacks in open-source software from 2019 to 2022.

In this Google Security Blog, there are many real examples of software supply chain attacks that pose growing threats to users and Google proposed a solution called SLSA in 2021.

Also, some well-known organizations such as Linux Foundation and CNCF have created standards and tools to address the issue of how to produce trusted software and attestations.

Based on this background, many organizations want to incorporate best practices from the open-source community into our CICD pipeline.

How to adopt Supply Chain Security for GitHub and Non-GitHub projects

Next, I will show you how to adopt on both GitHub and Rocket Bitbucket as an example to show you how we integrate software supply chain security

GitHub projects

On GitHub, the easiest and most popular option is to use slsa-github-generator, a tool provided by the official slsa-framework for native GitHub projects to create attestations during the build process and upload signed attestations to Rekor a transparency log system created by Sigstore. Here is the demo reposistory for reference.

Before installing your product package, the user can download the package and verify the provenance file at the end of .intoto.jsonl first, then run the following command manually or in their CI pipeline to verify whether the artifact is tampered with or not

bash-4.4$ slsa-verifier verify-artifact test-1.0.0-py3-none-any.whl --provenance-path test-1.0.0-py3-none-any.whl.intoto.jsonl --source-uri github.com/shenxianpeng/slsa-provenance-demo
Verified signature against tlog entry index 49728014 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77af7063689e8760fd7134f37e17251ec1d5adc16af64cb5cb579493278f7686e77
Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0" at commit fb7f6df9f8565ed6fa01591df2af0c41e5573798
Verifying artifact test-1.0.0-py3-none-any.whl: PASSED

PASSED: Verified SLSA provenance

Non-GitHub projects

However, there are many organizations’ codes are hosted on Non-GitHub SCM, so you can use the Witness, a tool from CNCF in-toto, which can help us generate and verify attestations.

It’s easy to scale Witness to your products, just integrate witness command into the existing build command it will generate proof of the software build and release execution process and can be verified.

You can follow this demo to integrate with witness, then will generate the build package along with attestations file, policy-signed.json file, and a public key.

Before user installing your product package, they can run the following command manually or in their CI pipeline to verify whether the artifact is tampered or not.

witness verify -f dist/witness_demo-1.0.0-py3-none-any.whl -a witness-demo-att.json -p policy-signed.json -k witness-demo-pub.pem
INFO    Using config file: .witness.yaml
INFO    Verification succeeded
INFO    Evidence:
INFO    0: witness-demo-att.json

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

由于近些年针对软件的供应链的攻击越来越频繁，因此 Google 在 2021 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）

本篇将介绍在非 GitHub 生态系统中，我们如何生成和验证软件工件的来源，从而提高你的项目的 SLSA Level。

Witness 是一个可插拔的软件供应链风险管理框架，它能自动、规范和验证软件工件出处。它是 in-toto 是 CNCF 下的项目之一。它的最初作者是 Testifysec，后来捐赠给了 in-toto。

什么是 Witness

Witness 是一个可插拔的供应链安全框架，可创建整个软件开发生命周期（SDLC）的证据（Provenance）跟踪，确保软件从源代码到目标的完整性。它支持大多数主要的 CI 和基础架构提供商，是确保软件供应链安全的多功能、灵活的解决方案。

安全 PKI (Public Key Infrastructure - 公钥基础设施)分发系统的使用和验证 Witness 元数据的能力进一步增强了流程的安全性，并有助于减少许多软件供应链攻击向量。

Witness 的工作原理是封装在持续集成流程中执行的命令，为软件开发生命周期（SDLC）中的每个操作提供证据跟踪，这样就可以详细、可验证地记录软件是如何构建的、由谁构建以及使用了哪些工具。

这些证据可用于评估政策合规性，检测任何潜在的篡改或恶意活动，并确保只有授权用户或机器才能完成流程中的某一步骤。

总结 - Witness 可以做什么

• 验证软件由谁构建、如何构建以及使用了哪些工具
• 检测任何潜在的篡改或恶意活动
• 确保只有经授权的用户或机器才能完成流程的每一步
• 分发证词（Attestations）和策略（Policy）

如何使用 Witness

主要分三步：

1. witness run - 运行提供的命令并记录有关执行的证词。
2. witness sign - 使用提供的密钥签署提供的文件。
3. witness verify - 验证 witness 策略。

快速开始

这是我创建的 Witness Demo 仓库用于演示 witness 的工作流程，具体可以根据如下步骤进行。

Read More

由于近些年针对软件的供应链的攻击越来越频繁，据 SonaType 的统计从 2019 年到 2022 年针对开源软件的攻击增长了 742%，因此 2021 年 Google 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）

本篇将介绍在 Python 生态系统中，我们如何使用 SLSA 框架来生成和验证 Python 工件的来源，从而让你的 SLSA Level 从 L0/L1 到 L3。

注意：本文介绍的是针对托管在 GitHub 上的 Python 项目。SLSA 框架可通过 GitHub Actions 来实现开箱即用，只需较少的配置即可完成。

对于托管在非 GitHub 上的项目（例如 Bitbucket）可以尝试 Witness，下一篇我将更新关于如何使用 Witness。

内容

1. 构建纯净的Python包
2. 生成出处证明
3. 上传到PyPI
4. 验证Python包的来源
5. 文中用到的项目

下面是从维护人员到用户的端到端工作流程：从构建 Wheel package -> 生成出处 -> 验证出处 -> 发布到 PyPI -> 以及用户验证出处 -> 安装 wheel。接下来让我们一起来完成这其中的每一步。

如果你想了解 Python 打包的流程或是术语可以参见Python 打包用户指南。

Read More

In this article, I would like to document the problems encountered when upgrading from IBM XLC 10.1 to XLC 17.1 (IBM Open XL C/C++ for AIX 17.1.0) and how to fix the following 12 errors.

If you’ve encountered any other errors, feel free to share your comments with or without a solution.

1. Change cc to ibm-clang

First you need to change all the related cc to ibm-clang in the the global Makefile. for example:

- CC=cc
- CXX=xlC_r
- XCC=xlC_r
- MAKE_SHARED=xlC_r
+ CC=ibm-clang
+ CXX=ibm-clang_r
+ XCC=ibm-clang_r
+ MAKE_SHARED=ibm-clang_r

And check following link of Mapping of options to map new Clang options if any.

2. error: unknown argument: ‘-qmakedep=gcc’

- GEN_DEPENDENTS_OPTIONS=-qmakedep=gcc  -E -MF $@.1 > /dev/null
+ GEN_DEPENDENTS_OPTIONS= -E -MF $@.1 > /dev/null

3. should not return a value [-Wreturn-type]

- return -1;
+ return;

4. error: non-void function ‘main’ should return a value [-Wreturn-type]

- return;
+ return 0;

5. error: unsupported option ‘-G’ for target ‘powerpc64-ibm-aix7.3.0.0’

- LIB_101_FLAGS := -G
+ LIB_101_FLAGS := -shared -Wl,-G

6. Undefined symbol (libxxxx.so)

- LIB_10_FLAGS := -bexport:$(SRC)/makefiles/xxxx.def
+ LIB_10_FLAGS := -lstdc++ -lm -bexport:$(SRC)/makefiles/xxxx.def

7. unsupported option -qlongdouble

- drv_connect.c.CC_OPTIONS=$(CFLAGS) -qlongdouble -brtl
+ drv_loadfunc.c.CC_OPTIONS=$(CFLAGS) $(IDIR) -brtl

8. Undefined symbol: ._Z8u9_closei

- extern int u9_close(int fd) ;
+ extern "C" int u9_close(int fd) ;

9. ERROR: Undefined symbol: .pow

- CXXLIBES = -lpthread -lC -lstdc++
+ CXXLIBES = -lpthread -lC -lstdc++ -lm

10. ‘main’ (argument array) must be of type ‘char **’

- d_char *argv[];
+ char *argv[];

11. first parameter of ‘main’ (argument count) must be of type ‘int’

- int main(char *argc, char *argv[])
+ int main(int argc, char *argv[])

12. ERROR: Undefined symbol: ._ZdaPv

- LIB_3_LIBS	:= -lverse -llog_nosig
+ LIB_3_LIBS	:= -lverse -llog_nosig -lstdc++

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

2202-23 世界质量报告（World Quality Report 简称 WQR）是一项全球研究，不论是作为软件测试、开发工程师，关注这类软件质量报告可以帮助我们快速了解软件行业的现状和趋势。

七个主题

今年的 WQR 的关键趋势和推荐包括包括以下七个关键建议：

• 敏捷质量调配 (DONE)
• 质量自动化 (DONE)
• 测试基础设施测试和配置 (DONE)
• 测试数据提供和数据验证 (WIP)
• 质量和可持续的 IT (NOT START)
• 新兴技术趋势的质量工程 (NOT START)
• 价值流管理 (NOT START)

Read More

最近遇到了通过 Jenkins agent 无法上传 artifacts 到 Artifactory 的情况，具体错误如下：

[2023-09-11T08:21:53.385Z] Executing command: /bin/sh -c git log --pretty=format:%s -1
[2023-09-11T08:21:54.250Z] [consumer_0] Deploying artifact: https://artifactory.mycompany.com/artifactory/generic-int-den/my-project/hotfix/1.2.0.HF5/3/pj120_bin_opt_SunOS_3792bcf.tar.Z

[2023-09-11T08:21:54.269Z] Error occurred for request GET /artifactory/api/system/version HTTP/1.1: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
[2023-09-11T08:21:54.282Z] Error occurred for request PUT /artifactory/generic-int-den/my-project/hotfix/1.2.0.HF5/3/pj120_bin_opt_SunOS_3792bcf.tar.Z;build.timestamp=1694418199972;build.name=hotfix%2F1.2.0.HF5;build.number=3 HTTP/1.1: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target.
[2023-09-11T08:21:54.284Z] [consumer_0] An exception occurred during execution:
[2023-09-11T08:21:54.284Z] java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
[2023-09-11T08:21:54.284Z] 	at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecDeploymentConsumer.consumerRun(SpecDeploymentConsumer.java:44)
[2023-09-11T08:21:54.284Z] 	at org.jfrog.build.extractor.producerConsumer.ConsumerRunnableBase.run(ConsumerRunnableBase.java:11)
[2023-09-11T08:21:54.284Z] 	at java.lang.Thread.run(Thread.java:745)
[2023-09-11T08:21:54.285Z] Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

这个问题产生的原因是通过 HTTPS 来上传文件的时候没有通过 Java 的安全认证。解决这个问题的办法就是重新生成认证文件，然后导入即可，具体的步骤如下。

生成安全认证（Security Certificate）文件

步骤如下：

1. 首先生成通过浏览器打开的你的 Artifactory 网址
2. 在网址的左侧应该有一个锁的图标，点击 Connection is secure -》Certificate is valid -》Details -》 Export
3. 选择 DER-encoded binary, single certificate (*.der) 生成认证文件

比如我生成的安全认证文件的名字叫：artifactory.mycompany.der（名字可以任意起，只要后缀名不变即可）

通过命令行导入安全认证

登录到那台有问题的 Solaris agent，上传 artifactory.mycompany.der 到指定目录下，然后找到 cacerts 的路径，执行如下命令：

root@mysolaris:/# keytool -import -alias example -keystore /usr/java/jre/lib/security/cacerts -file /tmp/artifactory.mycompany.der
# 然后选择 yes

这时候会提示你输入密码，默认密码为 changeit，输入即可。然后重启你的 JVM 或是 VM。等再次通过该 Agent 上传 artifacts，一切恢复正常。

可参考： https://stackoverflow.com/questions/21076179/pkix-path-building-failed-and-unable-to-find-valid-certification-path-to-requ

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

最近又遇到了在 AIX 上通过 Jenkins agent 无法下载代码的情况，报了如下错误：

16:42:47  Caused by: hudson.plugins.git.GitException: Command "git init /disk1/agent/workspace/e_feature-aix-ci-build" returned status code 255:
16:42:47  stdout:
16:42:47  stderr: exec(): 0509-036 Cannot load program git because of the following errors:
16:42:47  	0509-150   Dependent module /usr/lib/libiconv.a(libiconv.so.2) could not be loaded.
16:42:47  	0509-152   Member libiconv.so.2 is not found in archive
16:42:47
16:42:47  	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2734)
16:42:47  	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2660)
16:42:47  	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2656)
16:42:47  	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1981)
16:42:47  	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:1047)

上次遇到在 AIX 遇到的 git clone 问题总结在这里 https://shenxianpeng.github.io/2021/06/git-clone-failed-on-aix/

而我在 AIX 机器上手动执行 git clone 命令却没有这个错误发生，从失败的 log 和 ldd /usr/bin/git 发现 libiconv.a 的路径不同，推测问题应该出在 LIBPATH 环境变量上。

因为在本地（AIX）执行 git 命令的时候 LIBPATH 是为空，如果设置了 LIBPATH 路径为 /usr/lib/ 会出上面一样的错误。

$ ldd /usr/bin/git
/usr/bin/git needs:
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libpthreads.a(shr_xpg5_64.o)
         /opt/freeware/lib/libintl.a(libintl.so.8)
         /opt/freeware/lib/libiconv.a(libiconv.so.2)
         /opt/freeware/lib/libz.a(libz.so.1)
         /unix
         /usr/lib/libcrypt.a(shr_64.o)
         /opt/freeware/lib64/libgcc_s.a(shr.o)
$

但 Jenkins agent 在执行的时候有默认的 LIBPATH，查看这个变量可以通过 Jenkins Agent 上的 Script Console 执行如下命令打印出来

println System.getenv("LIBPATH")

# 返回的结果
/usr/java8_64/jre/lib/ppc64/j9vm:/usr/java8_64/jre/lib/ppc64:/usr/java8_64/jre/../lib/ppc64:/usr/java8_64/jre/lib/icc:/usr/lib

其中果然有 /usr/lib，这导致了 git 是去找 /usr/lib/libiconv.a 而不是 /opt/freeware/lib/libiconv.a。

我尝试过很多种办法但最终还是无法在 Jenkins agent 在 git clone 的时候 unset LIBPATH，包括:

1. 重新 link，将 /usr/lib/libiconv.a 链接到 /opt/freeware/lib/libiconv.a

mv /usr/lib/libiconv.a /usr/lib/libiconv.a.bak
ln -s /opt/freeware/lib/libiconv.a /usr/lib/libiconv.a

2. 在 pipeline 中使用 withEnv 设置 LIBPATH 为空

withEnv(['LIBPATH=\'\'']) {
  checkout scm
}

3. 在 Agent 配置页面上尝试通过 Environment variables 来修改 LIBPATH（这个看起来像是 Jenkins 的一个 bug JENKINS-69821)

4. 在配置 Jenkins agent 页面通过添加 export LIBPATH="" && 到 Prefix Start Agent Command 均不起作用。

最后是通过在 AIX 更新 Git 从版本 2.39.3 升级到 2.40.0 解决了这个错误，这有点巧合并没有真正把 Jenkins agent 的覆盖默认环境变量的问题给解决，但好在这个问题已经没有了。

仅此记录一下，防止以后遇到同样的错误不至于从头开始尝试，也希望这个记录也可能帮助到你。

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

DevOps 运动仍然是一个不断发展的领域，受到技术进步、行业趋势和组织需求等多种因素的影响。这使得很难对 DevOps 工程的未来做出具体预测。然而我认为有一些趋势可能会在来年继续影响 DevOps 领域的发展。

云原生技术的持续采用

容器化、微服务和无服务器计算等云原生技术会继续在 DevOps 环境中广泛采用，这些技术为各种项目提供了许多好处，包括：

• 提高可扩展性和可靠性：云原生技术可以让 DevOps 团队更轻松地构建、部署和管理可扩展且有弹性的应用程序。
• 更快的部署和迭代：云原生技术可以使团队更快地部署和迭代应用程序，帮助组织更快地行动并响应不断变化的业务需求。
• 更大的灵活性和敏捷性：云原生技术可以为 DevOps 团队提供更大的灵活性和敏捷性，使他们能够使用各种工具和平台构建和部署应用程序。

总体而言，随着组织寻求提高数字时代的效率和竞争力，采用云原生技术可能会继续成为未来几年 DevOps 的趋势。 Kubernetes 和类似的编排平台仍将是这一过程的重要组成部分，因为它们为构建、部署和管理容器化提供了一致的、基于云的环境、应用程序和基础设施。

更加关注安全性和合规性

随着安全性和合规性的重要性不断增长，组织会更加重视将安全性和合规性最佳实践纳入其流程和工具中。

未来几年，安全性和合规性在一些特定领域尤为重要：

• 云安全：随着越来越多的组织采用基于云的基础设施和服务，DevOps 团队将更加需要关注云安全性和合规性，包括确保云环境配置安全、数据在传输和静态时加密以及对云资源的访问进行控制和监控。
• 应用程序安全性：DevOps 团队需要专注于构建安全的应用程序并确保它们以安全的方式进行测试和部署，包括实施安全编码实践、将安全测试纳入开发过程以及使用安全配置部署应用程序。
• 遵守法规和标准：团队需要确保他们的流程和工具符合相关法规和行业标准，包括实施控制措施来保护敏感数据，确保系统配置为以合规的方式，通过审计和评估证明合规性，以及在适用的情况下将部分责任推给云提供商。

总而言之，随着组织寻求保护其系统、数据和客户免受网络威胁并确保遵守相关法规和标准，DevOps 中对安全性和合规性的关注肯定会增加，它还将使 DevSecOps 专家 在 DevOps 团队中发挥更大的作用。

开发和运营团队之间加强协作

DevOps 运动的理念是将开发和运营团队聚集在一起，以便更紧密、更有效地工作。未来几年，开发和运营团队之间的协作在一些关键领域可能会特别重要：

• 持续集成和交付 (CI/CD)：开发和运营团队需要密切合作，以确保有效地测试、部署和监控代码更改，并快速识别和解决任何问题。
• 事件管理：开发和运营团队需要合作识别和解决生产环境中出现的问题，并制定策略以防止将来发生类似问题。
• 容量规划和资源管理：开发和运营团队需要共同努力，以确保系统拥有必要的资源来满足需求，并规划未来的增长。

DevOps 的成功取决于开发和运营团队之间的强有力合作，这可能仍然是 2023 年的重点。

自动化和人工智能的持续发展

自动化和人工智能 (AI) 可能在 DevOps 的发展中发挥重要作用。自动化工具可以帮助 DevOps 团队对重复性任务进行编程、提高效率并降低人为错误的风险，而人工智能可用于分析数据、识别模式并协助做出更明智的决策。

• 人工智能可能对 DevOps 产生重大影响的一个潜在领域是预测分析领域。通过分析过去部署和性能指标的数据，人工智能算法可以识别模式并预测未来的结果，从而使团队能够更好地优化其流程并提高整体性能。
• 人工智能可能产生影响的另一个领域是事件管理领域。人工智能算法可用于分析日志数据并在潜在问题发生之前识别它们，从而使团队能够在出现重大事件之前主动解决出现的问题。

总体而言，DevOps 中自动化和人工智能的发展可能会带来更高效、更有效的流程，并提高应用程序和系统的性能和可靠性。然而，组织必须仔细考虑这些技术的潜在影响，并确保它们的使用方式符合其业务目标和价值观。
自动化和人工智能的实施应该成为战略的一部分：包括从一开始就需要集成到业务流程中，调整期望和目标，估计成本以及相关的风险和挑战。仅仅为了实现两者而实施并不一定会从中获益，相反，从长远来看，它可能会因维护它们而导致其他问题。

基础设施即代码的多云支持

基础设施即代码 (IaC) 正在成为一种越来越流行的实践，涉及使用与管理代码相同的版本控制和协作工具来管理基础设施。这使得组织能够将其基础设施视为一等公民，并且更容易自动化基础设施的配置和管理。

多云基础设施是指在单个组织内使用多个云计算平台，例如 AWS、Azure 和 Google Cloud。这种方法可以为组织提供更大的灵活性和弹性，因为它们不依赖于单个提供商。

结合这两个概念，对 IaC 的多云支持是指使用 IaC 实践和工具来管理和自动化跨多个云平台的资源调配和配置的能力。这可以包括使用 IaC 定义和部署基础设施资源，例如虚拟机、网络和存储，以及管理这些资源的配置。

使用 IaC 管理多云基础设施可以带来多种好处。它可以帮助组织在其环境中实现更高的一致性和标准化，并降低在多个云平台中管理资源的复杂性。它还可以使组织能够更轻松地在云平台之间迁移工作负载，并利用每个平台的独特功能。

总体而言，对于寻求优化多个云平台的使用并简化多云基础设施管理的组织来说，对 IaC 的多云支持可能仍然是一个重要因素。

更加强调多样性和包容性

随着技术行业继续关注多样性和包容性，DevOps 团队可能会更加重视建立多元化和包容性的团队并创造更具包容性的工作环境 - 包括：

• 为团队提供具有新的非技术技能的人员，以填补深刻的技能差距。根据 《提高 IT 技能 2022》报告，IT 需要七种关键技能：流程和框架技能、人员技能、技术技能、自动化技能、领导技能、数字技能、业务技能和高级认知技能。不幸的是，大多数 IT 经理首先追求的是技术技能，而忽视了“软技能” —— 这可能是阻碍 DevOps 在组织中进一步发展的最大因素。
• 整个团队以及单个 DevOps 成员的技能发展。近年来，每个人都面临着考验（新冠等流行病、不确定的经济形势），并使越来越多的 IT 专业人员不确定自己的技能，并感到需要进一步的培训和发展。与此同时，根据《2022 年 IT 技能提升》报告，接受调查的 IT 组织中只有 52% 制定了正式的技能提升计划。这实际上导致全球 IT 团队面临的最大挑战是缺乏技能。
• 向外部团队开放，保证能力和预期质量的快速提高。无论是外包以及其他形式的合作。这还可以在优化生产成本方面带来切实的好处（这无疑是当今开展业务最重要的因素之一）。

概括

上述 6 个方面是我们认为 2023 年 DevOps 的主要趋势。当然，每个人都可以从自己的角度添加其他要点，例如：无服务器计算、低代码和无代码解决方案、GitOps 等。

过往 DevOps 趋势文章

• 2022 年最值得关注的 DevOps 趋势和问答

参考

• Trends for DevOps engineering in 2023

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

Recently my CI pipeline suddenly does not work on AIX 7.1 with error Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath..

22:13:30  Executing command: /bin/sh -c git log --pretty=format:%s -1
22:13:36  [consumer_0] Deploying artifact: https://artifactory.company.com/artifactory/generic-int-den/myproject/PRs/PR-880/1/myproject_bin_rel_AIX_5797b20.tar.Z
22:13:36  Error occurred for request GET /artifactory/api/system/version HTTP/1.1: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error.
22:13:36  Error occurred for request PUT /artifactory/generic-int-den/myproject/PRs/PR-880/1/cpplinter_bin_rel_AIX_5797b20.tar.Z;build.timestamp=1693273923987;build.name=PR-880;build.number=1 HTTP/1.1: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error.
22:13:36  [consumer_0] An exception occurred during execution:
22:13:36  java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36  	at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecDeploymentConsumer.consumerRun(SpecDeploymentConsumer.java:44)
22:13:36  	at org.jfrog.build.extractor.producerConsumer.ConsumerRunnableBase.run(ConsumerRunnableBase.java:11)
22:13:36  	at java.lang.Thread.run(Thread.java:785)
22:13:36  Caused by: javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36  	at com.ibm.jsse2.j.a(j.java:3)
22:13:36  	at com.ibm.jsse2.as.a(as.java:213)
22:13:36  	at com.ibm.jsse2.C.a(C.java:339)
22:13:36  	at com.ibm.jsse2.C.a(C.java:248)
22:13:36  	at com.ibm.jsse2.D.a(D.java:291)
22:13:36  	at com.ibm.jsse2.D.a(D.java:217)
22:13:36  	at com.ibm.jsse2.C.r(C.java:373)
22:13:36  	at com.ibm.jsse2.C.a(C.java:352)
22:13:36  	at com.ibm.jsse2.as.a(as.java:752)
22:13:36  	at com.ibm.jsse2.as.i(as.java:338)
22:13:36  	at com.ibm.jsse2.as.a(as.java:711)
22:13:36  	at com.ibm.jsse2.as.startHandshake(as.java:454)
22:13:36  	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:436)
22:13:36  	at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:384)
22:13:36  	at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142)
22:13:36  	at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376)
22:13:36  	at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393)
22:13:36  	at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
22:13:36  	at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
22:13:36  	at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
22:13:36  	at org.apache.http.impl.execchain.ServiceUnavailableRetryExec.execute(ServiceUnavailableRetryExec.java:85)
22:13:36  	at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
22:13:36  	at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
22:13:36  	at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
22:13:36  	at org.jfrog.build.client.PreemptiveHttpClient.execute(PreemptiveHttpClient.java:76)
22:13:36  	at org.jfrog.build.client.PreemptiveHttpClient.execute(PreemptiveHttpClient.java:64)
22:13:36  	at org.jfrog.build.client.JFrogHttpClient.sendRequest(JFrogHttpClient.java:133)
22:13:36  	at org.jfrog.build.extractor.clientConfiguration.client.JFrogService.execute(JFrogService.java:112)
22:13:36  	at org.jfrog.build.extractor.clientConfiguration.client.artifactory.services.Upload.execute(Upload.java:77)
22:13:36  	at org.jfrog.build.extractor.clientConfiguration.client.artifactory.ArtifactoryManager.upload(ArtifactoryManager.java:267)
22:13:36  	at org.jfrog.build.extractor.clientConfiguration.client.artifactory.ArtifactoryManager.upload(ArtifactoryManager.java:262)
22:13:36  	at org.jfrog.build.extractor.clientConfiguration.util.spec.SpecDeploymentConsumer.consumerRun(SpecDeploymentConsumer.java:39)
22:13:36  	... 2 more
22:13:36  Caused by: com.ibm.jsse2.util.h: PKIX path building failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36  	at com.ibm.jsse2.util.f.a(f.java:107)
22:13:36  	at com.ibm.jsse2.util.f.b(f.java:143)
22:13:36  	at com.ibm.jsse2.util.e.a(e.java:6)
22:13:36  	at com.ibm.jsse2.aA.a(aA.java:99)
22:13:36  	at com.ibm.jsse2.aA.a(aA.java:112)
22:13:36  	at com.ibm.jsse2.aA.checkServerTrusted(aA.java:28)
22:13:36  	at com.ibm.jsse2.D.a(D.java:588)
22:13:36  	... 29 more
22:13:36  Caused by: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36  	at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:422)
22:13:36  	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
22:13:36  	at com.ibm.jsse2.util.f.a(f.java:120)
22:13:36  	... 35 more
22:13:36  Caused by: java.security.cert.CertPathValidatorException: The certificate issued by CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US is not trusted; internal cause is:
22:13:36  	java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36  	at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.java:111)
22:13:36  	at com.ibm.security.cert.PKIXCertPathValidatorImpl.engineValidate(PKIXCertPathValidatorImpl.java:199)
22:13:36  	at com.ibm.security.cert.PKIXCertPathBuilderImpl.myValidator(PKIXCertPathBuilderImpl.java:749)
22:13:36  	at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:661)
22:13:36  	at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.java:607)
22:13:36  	at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.java:368)
22:13:36  	... 37 more
22:13:36  Caused by: java.security.cert.CertPathValidatorException: Certificate chaining error
22:13:36  	at com.ibm.security.cert.CertPathUtil.findIssuer(CertPathUtil.java:316)
22:13:36  	at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.java:108)
22:13:36  	... 42 more
22:13:36

I have tried to download certificate.pem from my Artifactory and run this command, but the issue still there on my AIX 7.3.

/usr/java8_64/jre/bin/keytool -importcert -alias cacertalias -keystore /usr/java8_64/jre/lib/security/cacerts -file /path/to/your/certificate.pem

It investing it can not reproduce on my Windows, Linux and AIX 7.3 build machines.

What’s the different between them? the only different is Java runtime. On my problematic AIX 7.1 build machine, I used a shared runtime which is a link to path /tools/AIX-7.1/Java8_64-8.0.0.401/usr/java8_64/bin/java

bash-5.0$ /tools/AIX-7.1/Java8_64-8.0.0.401/usr/java8_64/bin/java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pap6480sr4fp1-20170215_01(SR4 FP1))
IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc64-64 Compressed References 20170209_336038 (JIT enabled, AOT enabled)
J9VM - R28_20170209_0201_B336038
JIT  - tr.r14.java.green_20170125_131456
GC   - R28_20170209_0201_B336038_CMPRSS
J9CL - 20170209_336038)
JCL - 20170215_01 based on Oracle jdk8u121-b13

And I have anther Java runtime installed my that machine which is /usr/java8_64/bin/java

bash-5.0$ /usr/java8_64/bin/java -version
java version "1.8.0_241"
Java(TM) SE Runtime Environment (build 8.0.6.5 - pap6480sr6fp5-20200111_02(SR6 FP5))
IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64-Bit Compressed References 20200108_436782 (JIT enabled, AOT enabled)
OpenJ9   - 7d1059c
OMR      - d059105
IBM      - c8aee39)
JCL - 20200110_01 based on Oracle jdk8u241-b07

Actually the versions of these two java versions are different. I just changed configuration of JavaPath from /tools/AIX-7.1/Java8_64-8.0.0.401/usr/java8_64/bin/java to /usr/java8_64/bin/java in the Jenkins node and disconnect then launch agent again, it works.

I don’t why it works, I don’t know much about Java certificate, if you know the reason please leave comments and let me know. Thank you.

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

其实创建包管理平台账户没什么可说的，但最近准备在 https://www.nuget.org 上面发布产品前创建 Organization 的时候确遇到了问题。

事情是这样的

作为一名公司员工在首次打开 NuGet 网站 (www.nuget.org) 的时候，点击【Sign in】，映入眼帘的就是【Sign in with Microsoft】，点击，下一步、下一步，我就顺利的就用公司邮箱注册了我的第一个 NuGet 的账户。

此时我准备创建一个 Organization 的时候，输入自己的公司邮箱提示这个邮箱地址已经被使用了，What ？？？

OK。那我就填写同事的公司邮箱地址吧。

同事在收到邮件通知后也是一步步操作，先是打开 NuGet.org，点击【Sign in with Microsoft】，然后也是需要填写自己的账户名，结果完成这一系列的操作之后，再输入他的邮件地址去注册 Organization 的时候也同样提示这个邮箱已经被使用了？？？什么操作！！！醉了…

如何解决的

就在这千钧一发焦急得等待发布之际，我突然灵机一动，以死马当活马医的心态，将我注册的 NuGet 的个人账户绑定的公司邮箱修改为了自己的 Gmail 邮箱，然后此时再去创建 Organization 的时候输入的是自己的公司邮箱，创建 Organization 成功了！！

好了，谨以此记录一下在注册 NuGet 时候遇到的问题。不知道对你是否有用，如果真的有帮助到你，举手示意一下哦。

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」