Merge pull request #122 from brotskydotcom/fix-secret-service-docs

Fix misleading typo in secret-service docs.

The same typo was in the Mac, iOS, and xplat docs, but it wasn't serious there because it didn't affect attribute names.

Fixes #121.

Author: brotskydotcom

Cargo.toml

@@ -6,7 +6,7 @@ keywords = ["password", "credential", "keychain", "keyring", "cross-platform"]
 license = "MIT OR Apache-2.0"
 name = "keyring"
 repository = "https://github.com/hwchen/keyring-rs.git"
-version = "2.0.1"
+version = "2.0.2"
 edition = "2021"
 exclude = [".github/"]
 readme = "README.md"

build-xplat-binaries.sh

@@ -0,0 +1,11 @@
+#!/bin/bash
+rustup update
+cargo update
+cargo clippy --target x86_64-unknown-linux-musl
+cargo clippy --target x86_64-pc-windows-gnu
+cargo clippy --target aarch64-apple-darwin
+cargo clippy --target aarch64-apple-ios
+cargo build --target x86_64-unknown-linux-musl
+cargo build --target x86_64-pc-windows-gnu
+cargo build --target aarch64-apple-darwin
+cargo build --target aarch64-apple-ios

src/ios.rs

@@ -6,9 +6,9 @@ iOS credential stores are called Keychains.  On iOS there is only one of these.
 Generic credentials on iOS can be identified by a large number of _key/value_ attributes;
 this module (currently) uses only the _account_ and _name_ attributes.
 
-For a given service/username pair,
+For a given service/user pair,
 this module targets a generic credential in the User (login) keychain
-whose _account_ is the username and and whose _name_ is the service.
+whose _account_ is the user and and whose _name_ is the service.
 Because of a quirk in the iOS keychain services API, neither the _account_
 nor the _name_ may be the empty string. (Empty strings are treated as
 wildcards when looking up credentials by attribute value.)

src/lib.rs

@@ -192,14 +192,14 @@ pub struct Entry {
 }
 
 impl Entry {
-    /// Create an entry for the given service and username.
+    /// Create an entry for the given service and user.
     ///
     /// The default credential builder is used.
     pub fn new(service: &str, user: &str) -> Result<Entry> {
         build_default_credential(None, service, user)
     }
 
-    /// Create an entry for the given target, service, and username.
+    /// Create an entry for the given target, service, and user.
     ///
     /// The default credential builder is used.
     pub fn new_with_target(target: &str, service: &str, user: &str) -> Result<Entry> {

src/macos.rs

@@ -7,9 +7,9 @@ The OS automatically creates three of them (or four if removable media is being
 Generic credentials on macOS can be identified by a large number of _key/value_ attributes;
 this module (currently) uses only the _account_ and _name_ attributes.
 
-For a given service/username pair,
+For a given service/user pair,
 this module targets a generic credential in the User (login) keychain
-whose _account_ is the username and and whose _name_ is the service.
+whose _account_ is the user and and whose _name_ is the service.
 Because of a quirk in the Mac keychain services API, neither the _account_
 nor the _name_ may be the empty string. (Empty strings are treated as
 wildcards when looking up credentials by attribute value.)

src/secret_service.rs

@@ -8,7 +8,7 @@ implementation uses the following attributes:
 
 - `target` (optional & taken from entry creation call, defaults to `default`)
 - `service` (required & taken from entry creation call)
-- `user` (required & taken from entry creation call)
+- `username` (required & taken from entry creation call)
 - `application` (optional & always set to `rust-keyring`)
 
 Existing items are always searched for at the service level, which