#krb5 #kerberos #bindings #unmaintained #libkrb5

deprecated sys libkrb5-sys

[UNMAINTAINED] FFI bindings for MIT Kerberos 5 (libkrb5)

3 releases

0.0.3 Feb 14, 2022
0.0.2 Apr 7, 2020
0.0.1 Sep 10, 2019

#6 in #unmaintained


Used in libkrb5

MIT/Apache

8KB

[UNMAINTAINED] libkrb5 bindings for Rust

This crate is no longer actively maintained. API coverage is very limited, and I no longer have a use case that requires me to develop it further. While it should be relatively straightforward to add wrappers for more FFI calls by following the patterns already established in this crate, I have no plans to do so.

If you need libkrb5 bindings in Rust, I recommend to look at the other crates which provide this functionality, or investigate whether using something like GSSAPI bindings directly would actually be a better fit for your needs.

Nevertheless, if somebody really wants to take over maintenance of the libkrb5 and libkrb5-sys crates, feel free to reach out.


This repository contains both work-in-progress safe, idiomatic Rust bindings for libkrb5, the client library of MIT Kerberos 5, and the underlying "unsafe" bindings generated by bindgen in libkrb5-sys.

Thread-safety

According to the libkrb5 documentation, MIT Kerberos 5 is thread-safe as of version 1.4, with the exception of context initialization and de-initialization functions, which are expected to not run concurrently on different threads. For this reason, calls to the krb5_init_context and krb5_init_secure_context functions as well as krb5_free_contex are synchronized by a global Mutex.

NOTE: Running this crate's test suite with LLVM's sanitizers shows errors in some cases. AddressSanitizer and LeakSanitizer show no issues, but MemorySanitizer makes the build fail during the build of log (so that's unrelated to this crate), and ThreadSanitizer fails - apparently due to false positives in the lazy_static code (according to a closed issue).

To my best knowledge, this library follows the documentation regarding thread-safe usage of libkrb5 (context initialization and teardown protected by a global Mutex), and all other functions in libkrb5 should be thread-safe.

Contributions welcome

If you see a bug or want to expand API coverage, it should be fairly easy to look at the existing wrapper functions and adapt that code for other libkrb5 APIs.

Dependencies

~0–2MB
~36K SLoC