OutWit.Shared.Secrets.Provider.Linux
1.0.0
dotnet add package OutWit.Shared.Secrets.Provider.Linux --version 1.0.0
NuGet\Install-Package OutWit.Shared.Secrets.Provider.Linux -Version 1.0.0
<PackageReference Include="OutWit.Shared.Secrets.Provider.Linux" Version="1.0.0" />
<PackageVersion Include="OutWit.Shared.Secrets.Provider.Linux" Version="1.0.0" />
<PackageReference Include="OutWit.Shared.Secrets.Provider.Linux" />
paket add OutWit.Shared.Secrets.Provider.Linux --version 1.0.0
#r "nuget: OutWit.Shared.Secrets.Provider.Linux, 1.0.0"
#:package OutWit.Shared.Secrets.Provider.Linux@1.0.0
#addin nuget:?package=OutWit.Shared.Secrets.Provider.Linux&version=1.0.0
#tool nuget:?package=OutWit.Shared.Secrets.Provider.Linux&version=1.0.0
OutWit.Shared.Secrets.Provider.Linux
Linux Secret Service (libsecret) provider for
OutWit.Shared.Secrets.Providers,
for interactive desktop sessions with an unlocked keyring.
The limitation, stated prominently
The Secret Service is a session service. A systemd unit with no session, a
container, an SSH login without a desktop — these have no session bus and no
unlocked keyring, and every operation honestly answers
SecretStatus.Unavailable, never a silent fallback to a file. For those
deployments OutWit.Shared.Secrets.Provider.File
is the intended answer, chosen deliberately in configuration.
Where the secret lives
The session keyring, schema com.outwit.secrets, one item per key with the
attribute key='{your key}'. Attribute matching is exact and case-sensitive,
so the key maps identically — no suffix. The libsecret password API is
string-based, so the payload is stored base64-encoded; a support engineer
inspects it with:
secret-tool lookup key 'MyProduct/ApiKey'
One stated trade-off: the base64 string transits managed memory on the way in and cannot be erased — the same trade-off the string extensions document.
Use
services.AddSingleton<ISecretStore>(new SecretStoreLibsecret());
// or, for a cross-platform desktop app: OutWit.Shared.Secrets.Desktop
Requires libsecret-1.so.0 (package libsecret-1-0 on Debian/Ubuntu,
libsecret on Fedora/Arch). Without it every operation answers Unavailable
with a message saying exactly that.
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net8.0 is compatible. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. net9.0 is compatible. net9.0-android was computed. net9.0-browser was computed. net9.0-ios was computed. net9.0-maccatalyst was computed. net9.0-macos was computed. net9.0-tvos was computed. net9.0-windows was computed. net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- OutWit.Shared.Secrets.Providers (>= 1.0.0)
-
net8.0
- OutWit.Shared.Secrets.Providers (>= 1.0.0)
-
net9.0
- OutWit.Shared.Secrets.Providers (>= 1.0.0)
NuGet packages (1)
Showing the top 1 NuGet packages that depend on OutWit.Shared.Secrets.Provider.Linux:
| Package | Downloads |
|---|---|
|
OutWit.Shared.Secrets.Desktop
The composite desktop package for OutWit.Shared.Secrets: references the Windows, macOS and Linux providers and exposes SecretStoreDesktop.ForCurrentPlatform(), so a cross-platform desktop application takes one reference and writes one line. Selecting among the operating-system providers by runtime platform is not silent degradation — on each desktop platform exactly one OS store is right, and all three protect the same way. Falling back to the File provider stays a deliberate, configured choice. |
GitHub repositories
This package is not used by any popular GitHub repositories.
| Version | Downloads | Last Updated |
|---|---|---|
| 1.0.0 | 129 | 8/31/2026 |