1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
//! Credential helper bridge for Git LFS (git credential fill/approve/reject).
//!
//! LFS endpoints are usually HTTPS, and HTTPS auth needs a username
//! and password. Rather than maintaining a separate credential store,
//! this crate defers to git's existing one: whatever the user has
//! already configured for their git remote (osxkeychain, libsecret,
//! manager, store, plain `cache`, …) is what LFS uses too.
//!
//! The [`Helper`] trait represents one credential source. A
//! [`HelperChain`] tries multiple sources in order, broadcasting
//! [`Helper::approve`] / [`Helper::reject`] to every helper so caches
//! stay in sync. The bundled implementations are:
//!
//! - [`CachingHelper`]: in-process cache keyed on the [`Query`]
//! tuple (protocol, host, path).
//! - [`GitCredentialHelper`]: shells out to `git credential
//! fill/approve/reject`, picking up whatever helper the user has
//! configured.
//! - [`AskpassHelper`]: spawns the `GIT_ASKPASS` / `core.askpass` /
//! `SSH_ASKPASS` program for interactive prompts.
//! - [`NetrcCredentialHelper`]: parses `~/.netrc` (or `_netrc` on
//! Windows) for host-keyed login/password pairs.
//!
//! SSH remotes follow a different flow. [`SshAuthClient`] runs
//! `git-lfs-authenticate <path> <operation>` over SSH and parses an
//! [`SshAuth`] response containing a replacement HTTPS endpoint plus
//! short-lived authorization headers; no username/password is asked
//! of the user. Results are cached per request key with the
//! server-supplied expiry honored.
pub use AskpassHelper;
pub use HelperChain;
pub use GitCredentialHelper;
pub use ;
pub use CachingHelper;
pub use NetrcCredentialHelper;
pub use Query;
pub use ;