ai-contract-platform/yuqei-contract-platform/services/kms-gateway/vendor/alibaba-kms-modern/README.md

Controlled Alibaba KMS SDK forks

The gateway retains Alibaba KMS Instance SDK behavior because its deployed configuration uses AAP ClientKey authentication: an encrypted PKCS#12 client key, password, private endpoint, and explicit CA. Alibaba's maintained alibabacloud_kms20160120 client supports the required business operations, but its generated Python client marks them as auth_type = "AK". Replacing the client would therefore change authentication material and the deployment contract instead of being a dependency-only security fix.

build_forks.py creates two narrow, reviewable forks from upstream PyPI source archives whose SHA-256 digests and sensitive source-file hashes are pinned:

• alibabacloud-kms-python-sdk 1.1.3+yuqei.1 replaces only the DKMS and protobuf dependency constraints.
• alibabacloud-dkms-gcs 1.0.2+yuqei.2 replaces the removed pyOpenSSL PKCS#12 API with cryptography, removes the obsolete pyOpenSSL dependency, raises protobuf to the audited 6.33 line, and reconstructs the generated message classes from the exact upstream serialized descriptor using the current protobuf generated-code descriptor-pool/builder pattern.

No provider endpoint, request/response model, transfer-handler, or gateway source is patched. The compatibility tests exercise both real SDK imports, an exact protobuf serialize/parse round trip, synthetic ClientKey JSON parsing, real KmsSdkClient initialization, AAP protobuf transfer serialization, CA/TLS runtime settings, response parsing, and public-key verification of the emitted authorization signature. The build fails closed if an upstream archive, reviewed source file, patched output, protobuf descriptor, or final wheel differs from the recorded bytes. Wheels carry local version suffixes so they cannot be confused with upstream releases.

Builds set a fixed SOURCE_DATE_EPOCH and PYTHONHASHSEED; the pinned Python 3.12 builder requires the recorded wheel SHA-256 digests. Two clean Windows x86_64 CPython 3.12.14 builds were byte-identical. Linux x86_64 was not executed in that local verification environment, so the Linux CI/container build remains a required fail-closed gate rather than a claimed local result. The emitted JSON manifest records every patched file digest plus the resulting wheel digests.

The upstream packages are Apache-2.0 licensed. Both reviewed repository trees contain the same LICENSE and no NOTICE file. Their READMEs contain the same Alibaba Cloud copyright line; setuptools retains that line in each wheel's METADATA, and the builder verifies it. The license is hash-verified before each build and copied into both wheels. Modified source files receive an explicit modification notice. UPSTREAM.json records source, per-file patch, copyright, and license provenance.

This is a compatibility fork, not evidence of a live Alibaba Cloud KMS call. The compatibility test uses a synthetic encrypted PKCS#12 key and verifies a local RSA signature only.