本篇介绍的是大名鼎鼎的开源软件基金会 Apache 所使用的服务(Services)和工具(Tools)，这或许能帮助你打开视野，在选择工具的时候提供参考。如果你是一名 DevOps、SRE 或是 Infra 工程师，通过本篇文章内容结果帮助你更好的展示团队所提供的服务有哪些，以及窥探到 Apache Infra 是怎样组织和管理他们的。
# Configuration for Release Drafter: https://github.com/toolmantim/release-drafter name-template:$NEXT_MINOR_VERSION tag-template:$NEXT_MINOR_VERSION # Uses a more common 2-digit versioning in Jenkins plugins. Can be replaced by semver: $MAJOR.$MINOR.$PATCH version-template:$MAJOR.$MINOR
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)
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
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:
[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
