hanko_xml 0.1.0

data/dependencies.yml

@@ -0,0 +1,87 @@
+# Pinned upstream C libraries.
+#
+# These are the versions statically vendored into the precompiled platform gems
+# (see RELEASING.md). The source gem does not use them: it builds against the
+# system libraries unless HANKO_XML_VENDOR=1 is set, which only CI does.
+#
+# The gem version does NOT track these. hanko_xml's version is SemVer over its
+# Ruby API; what is vendored is data, reported at runtime by
+# HankoXml::NativeVersion.build_versions. Bumping a version here is at minimum a
+# patch release, and an upstream *security* fix is a patch release with the CVE
+# named in CHANGELOG.md -- vendoring makes us the distributor, so that response
+# is our obligation.
+#
+# The checksums are not decoration. We redistribute cryptographic code, so the
+# build verifies SHA256 before extracting and fails hard on a mismatch.
+#
+# Tarballs are cached in tmp/vendor-cache/ (gitignored); override with
+# HANKO_XML_VENDOR_CACHE to build offline or from a mirror. The cache is
+# verified against these checksums on every build; the compiled output in
+# tmp/vendor-build/ is not, and is a trusted input (VENDORING.md, "Trusted
+# build inputs").
+#
+# To bump: change version + sha256 together, run
+# `HANKO_XML_VENDOR=1 bundle exec rake compile spec`, and confirm
+# `spec/symbols_spec.rb` (part of the suite) still finds no leaked
+# xml*/xmlSec* exports.
+
+libxml2:
+  version: "2.15.4"
+  url: "https://download.gnome.org/sources/libxml2/2.15/libxml2-2.15.4.tar.xz"
+  sha256: "98087fd181d9070724f3fbc65c7377db03038eb92bd882374daff44940138821"
+  license: "MIT"
+
+xmlsec1:
+  version: "1.3.12"
+  # The project's own site (www.aleksey.com, the `mirror` below) sits behind
+  # Cloudflare and answers 403 to GitHub Actions runners, so the primary source
+  # is the identical tarball from the upstream GitHub release -- verified
+  # byte-for-byte against aleksey.com, same SHA256. Which host serves it does
+  # not affect trust: the checksum below is what is actually trusted.
+  url: "https://github.com/lsh123/xmlsec/releases/download/1.3.12/xmlsec1-1.3.12.tar.gz"
+  mirror: "https://www.aleksey.com/xmlsec/download/xmlsec1-1.3.12.tar.gz"
+  sha256: "24045199af12d93fe5fdbbbf7e386e823e4842071e9432e2b90ac108b889a923"
+  license: "MIT"
+
+openssl:
+  # 3.5 is the LTS series (supported into 2030); a vendored dependency wants
+  # long support and few forced bumps. Checksum cross-checked against both the
+  # GitHub release and openssl.org's published .sha256 -- one source is not
+  # enough for the crypto we ship.
+  version: "3.5.9"
+  url: "https://github.com/openssl/openssl/releases/download/openssl-3.5.9/openssl-3.5.9.tar.gz"
+  mirror: "https://www.openssl.org/source/openssl-3.5.9.tar.gz"
+  sha256: "603f5602e2eef00d77fbd429d34dcd5822bb301757a1bc9cdb24c670f1eb859a"
+  license: "Apache-2.0"
+
+# Why OpenSSL is vendored after all.
+#
+# The original plan linked the system libcrypto, on the reasoning that libxml2
+# must be vendored (xmlDoc/xmlNode/xmlAttr are *public* structs we dereference
+# by field offset -- that is its ABI -- and the same xmlDocPtr is shared with
+# xmlsec) while OpenSSL is the opposite: 3.x structs are opaque behind
+# accessors, and its pointers never enter our code at all, since the only
+# contact is the xmlSecOpenSSLApp* wrappers, which take PEM bytes.
+#
+# That reasoning is still correct about *safety*. It was wrong about
+# *feasibility* for precompiled gems, and CI proved it three times:
+#
+#   * macOS ships no usable system libcrypto, so a vendored build baked in an
+#     absolute Homebrew path.
+#   * Cross-compiling to aarch64 found no target OpenSSL in the build
+#     container at all.
+#   * x86_64 built fine and then would not load: the build container's OpenSSL
+#     is 1.1, so the gem recorded a NEEDED entry for libcrypto.so.1.1 while
+#     every current distro ships libcrypto.so.3. Different soname, so it failed
+#     at load on a bare ruby:3.3-slim.
+#
+# The soname a precompiled gem records is decided by whatever OpenSSL the build
+# container has, which is never the user's. Vendoring is the only way to make
+# the two agree. Safety is preserved the same way it is for libxml2: the FFI
+# boundary is PEM strings, never EVP_PKEY*, and -fvisibility=hidden plus
+# --exclude-libs keeps our copy private from Ruby's own openssl stdlib.
+#
+# The cost is real and accepted: OpenSSL advisories are now our release
+# obligation. Note also that a bundled libcrypto bypasses system crypto policy
+# (FIPS and similar), which matters to regulated users of a signing library --
+# they should build the source gem, which still links the system OpenSSL.

data/ext/hanko_xml/Cargo.toml

@@ -0,0 +1,20 @@
+[package]
+name = "hanko_xml"
+version = "0.1.0"
+edition = "2021"
+authors = ["Danimar Ribeiro <danimaribeiro@gmail.com>"]
+license = "MIT"
+publish = false
+
+[lib]
+crate-type = ["cdylib"]
+
+[dependencies]
+magnus = { version = "0.8.2" }
+
+[build-dependencies]
+bindgen = "0.73"
+pkg-config = "0.3"
+# Verifies the pinned upstream tarballs in dependencies.yml before they are
+# extracted. Build-time only, and only exercised on the vendored path.
+sha2 = "0.11"