sasl2-sys

Low-level Rust FFI bindings to the Cyrus SASL authentication library.

Library
Cargo
v0.1.22+2.1.28
5stars
Apache License 2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
18/100Needs Attention
Development Activity0
Maintenance0
Community12
Maturity60
Momentum0

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
66/100Good
Architecture72
Code Quality68
Innovation60
Learning Curve45

sasl2-sys exposes raw, unsafe Rust bindings to Cyrus SASL, the widely deployed C implementation of the Simple Authentication and Security Layer. It lets Rust programs negotiate SASL authentication mechanisms such as PLAIN, SCRAM, and GSSAPI against services that speak the protocol, including mail servers, LDAP directories, and message brokers.

Maintained by Materialize, the crate can link against a system-provided libsasl2 via pkg-config or vendor and build the C library from source, with optional Cargo features for bundling OpenSSL and Kerberos support. It is the FFI foundation on top of which higher-level, safe SASL wrappers are built.

What You Get

  • Raw Rust FFI declarations for the Cyrus SASL 2.1.x client and server APIs
  • A build script that either links system libsasl2 via pkg-config or vendors and compiles the C sources
  • Optional Cargo features for SCRAM, PLAIN, GSSAPI (Kerberos via krb5-src), and vendored OpenSSL
  • Bindings for the SASL property, callback, and plugin interfaces used to drive authentication exchanges

Common Use Cases

  • Adding SASL authentication to a Rust client for Kafka, LDAP, SMTP, or other SASL-aware services
  • Building a higher-level, safe Rust wrapper crate over Cyrus SASL
  • Supporting GSSAPI/Kerberos or SCRAM authentication in a Rust systems application
  • Reusing an existing, battle-tested C SASL implementation instead of reimplementing mechanisms in Rust

Under The Hood

Architecture - The crate is a thin -sys binding: sasl2-sys/src/lib.rs re-exports modules (sasl, saslplug, saslutil, prop, md5, hmac_md5) that declare extern "C" signatures and repr(C) structs mirroring the Cyrus SASL headers. A build.rs decides at compile time whether to link a system libsasl2 via pkg-config or invoke cc/duct to compile the vendored C sources under sasl2-sys/sasl2, emitting the links = "sasl2" cargo directive so downstream crates share one native library.

Tech Stack - Written for Rust 2018 with libc for C type compatibility, cc, duct, and pkg-config as build dependencies, and optional openssl-sys and krb5-src for SCRAM and GSSAPI mechanisms. The vendored payload is the upstream Cyrus SASL C project (2.1.28), so the majority of the repository is C, Shell, Makefile, and M4 autotools tooling.

Code Quality - As a generated-style FFI surface the Rust code is intentionally minimal and unsafe by nature; correctness rests on matching the C ABI. A systest crate plus a feature-gated plugins integration test validate that the bindings agree with the real library layout, and version-sync keeps documented versions aligned. There is little idiomatic Rust logic to test beyond ABI conformance.

API Design - The public API is deliberately raw: callers work with pointers, C strings, and manual callback registration exactly as in libsasl2, so ergonomics are low and unsafe blocks are unavoidable. This is by design — it is meant as the foundation for a safe wrapper rather than a friendly end-user API, and installation via a single Cargo dependency with optional feature flags is the main convenience it offers.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search