Sometimes you don’t want Jenkins pipeline failed for a specific error occurs. so you can use catchError to catch error and update stage or build result to SUCCESSFUL or UNSTABLE or FAILURE (if you want)
Here is the Jenkinsfile of pipeline
pipeline { |
Here is the output of pipeline
17:14:07 [Pipeline] Start of Pipeline |
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」
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.
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
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 |
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 |
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」
由于近些年针对软件的供应链的攻击越来越频繁，因此 Google 在 2021 提出的解决方案是软件工件供应链级别（Supply chain Levels for Software Artifacts，”SLSA”）
本篇将介绍在非 GitHub 生态系统中，我们如何生成和验证软件工件的来源，从而提高你的项目的 SLSA Level。
Witness 是一个可插拔的软件供应链风险管理框架，它能自动、规范和验证软件工件出处。它是 in-toto 是 CNCF 下的项目之一。它的最初作者是 Testifysec，后来捐赠给了 in-toto。
Witness 是一个可插拔的供应链安全框架，可创建整个软件开发生命周期（SDLC）的证据（Provenance）跟踪，确保软件从源代码到目标的完整性。它支持大多数主要的 CI 和基础架构提供商，是确保软件供应链安全的多功能、灵活的解决方案。
安全 PKI (Public Key Infrastructure - 公钥基础设施)分发系统的使用和验证 Witness 元数据的能力进一步增强了流程的安全性，并有助于减少许多软件供应链攻击向量。
Witness 的工作原理是封装在持续集成流程中执行的命令，为软件开发生命周期（SDLC）中的每个操作提供证据跟踪，这样就可以详细、可验证地记录软件是如何构建的、由谁构建以及使用了哪些工具。
这些证据可用于评估政策合规性，检测任何潜在的篡改或恶意活动，并确保只有授权用户或机器才能完成流程中的某一步骤。
总结 - Witness 可以做什么
主要分三步：
witness run - 运行提供的命令并记录有关执行的证词。witness sign - 使用提供的密钥签署提供的文件。witness verify - 验证 witness 策略。这是我创建的 Witness Demo 仓库用于演示 witness 的工作流程，具体可以根据如下步骤进行。
由于近些年针对软件的供应链的攻击越来越频繁，据 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。
下面是从维护人员到用户的端到端工作流程：从构建 Wheel package -> 生成出处 -> 验证出处 -> 发布到 PyPI -> 以及用户验证出处 -> 安装 wheel。接下来让我们一起来完成这其中的每一步。
如果你想了解 Python 打包的流程或是术语可以参见Python 打包用户指南。
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.
First you need to change all the related cc to ibm-clang in the the global Makefile. for example:
- CC=cc |
And check following link of Mapping of options to map new Clang options if any.
- GEN_DEPENDENTS_OPTIONS=-qmakedep=gcc -E -MF $@.1 > /dev/null |
- return -1; |
- return; |
- LIB_101_FLAGS := -G |
- LIB_10_FLAGS := -bexport:$(SRC)/makefiles/xxxx.def |
- drv_connect.c.CC_OPTIONS=$(CFLAGS) -qlongdouble -brtl |
- extern int u9_close(int fd) ; |
- CXXLIBES = -lpthread -lC -lstdc++ |
- d_char *argv[]; |
- int main(char *argc, char *argv[]) |
- LIB_3_LIBS := -lverse -llog_nosig |
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」
最近遇到了通过 Jenkins agent 无法上传 artifacts 到 Artifactory 的情况，具体错误如下：
[2023-09-11T08:21:53.385Z] Executing command: /bin/sh -c git log --pretty=format:%s -1 |
这个问题产生的原因是通过 HTTPS 来上传文件的时候没有通过 Java 的安全认证。解决这个问题的办法就是重新生成认证文件，然后导入即可，具体的步骤如下。
步骤如下：
比如我生成的安全认证文件的名字叫：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 |
这时候会提示你输入密码，默认密码为 changeit，输入即可。然后重启你的 JVM 或是 VM。等再次通过该 Agent 上传 artifacts，一切恢复正常。
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「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: |
上次遇到在 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 |
但 Jenkins agent 在执行的时候有默认的 LIBPATH，查看这个变量可以通过 Jenkins Agent 上的 Script Console 执行如下命令打印出来
println System.getenv("LIBPATH") |
# 返回的结果 |
其中果然有 /usr/lib，这导致了 git 是去找 /usr/lib/libiconv.a 而不是 /opt/freeware/lib/libiconv.a。
我尝试过很多种办法但最终还是无法在 Jenkins agent 在 git clone 的时候 unset LIBPATH，包括:
/usr/lib/libiconv.a 链接到 /opt/freeware/lib/libiconv.amv /usr/lib/libiconv.a /usr/lib/libiconv.a.bak |
withEnv 设置 LIBPATH 为空withEnv(['LIBPATH=\'\'']) { |
在 Agent 配置页面上尝试通过 Environment variables 来修改 LIBPATH（这个看起来像是 Jenkins 的一个 bug JENKINS-69821)
在配置 Jenkins agent 页面通过添加 export LIBPATH="" && 到 Prefix Start Agent Command 均不起作用。
最后是通过在 AIX 更新 Git 从版本 2.39.3 升级到 2.40.0 解决了这个错误，这有点巧合并没有真正把 Jenkins agent 的覆盖默认环境变量的问题给解决，但好在这个问题已经没有了。
仅此记录一下，防止以后遇到同样的错误不至于从头开始尝试，也希望这个记录也可能帮助到你。
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「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 |
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 |
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 |
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攻城狮」