Skip to content
This repository was archived by the owner on Feb 11, 2025. It is now read-only.

Conversation

@VishnuJin
Copy link
Contributor

@VishnuJin VishnuJin commented Apr 6, 2022

fixes #299

this PR adds optional ability to sign-invoice with a key that matches the given label

For example

--label-matching (partial match)

❯ bindle sign-invoice -o signed-invoice.toml invoice.toml --label-matching "Vishnu Jin"
Signed invoice.toml with role creator, label as 'Vishnu Jin <vishnujin@outlook.com>' and wrote to signed-invoice.toml

--label (exact match)

❯ bindle sign-invoice -o signed-invoice.toml invoice.toml --label "Vishnu Jin <vishnujin@outlook.com>"
Signed invoice.toml with role creator, label as 'Vishnu Jin <vishnujin@outlook.com>' and wrote to signed-invoice.toml

@VishnuJin VishnuJin force-pushed the feat-label-search-for-sign-invoice branch from fdadf76 to 2efe16c Compare April 6, 2022 14:01
Copy link
Contributor

@thomastaylor312 thomastaylor312 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 minor changes here.

Also, it would be great if we could have a --label that does an exact match, but that is optional

@VishnuJin
Copy link
Contributor Author

Also, it would be great if we could have a --label that does an exact match, but that is optional

yeah that was my original intention as well.I will implement it

@VishnuJin
Copy link
Contributor Author

@thomastaylor312 can we use the -l as short for --label and -m as short for --label-match ?

@thomastaylor312
Copy link
Contributor

Those sound like great shorthands

@VishnuJin VishnuJin force-pushed the feat-label-search-for-sign-invoice branch from 2efe16c to c1f102a Compare April 7, 2022 19:45
thomastaylor312
thomastaylor312 previously approved these changes Apr 7, 2022
Copy link
Contributor

@thomastaylor312 thomastaylor312 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! Thanks for going back to make things match. I'll leave this open for a bit in case you want to handle the nit and will merge tomorrow!

/// In general, if multiple keys match, the implementation chooses the "best fit"
/// and returns that key.
fn get_first_matching(&self, role: &SignatureRole) -> Option<&SecretKeyEntry>;
fn get_first_matching(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thomastaylor312 Just thought it would be better to just have one method in the trait rather than having 2 methods that mostly does the same

@VishnuJin
Copy link
Contributor Author

@thomastaylor312 I have just modified the approach here, if you like this approach I will remove the earlier commits !! let me know your thoughts

Copy link
Contributor

@thomastaylor312 thomastaylor312 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually really like this way of doing it! Just a few comments for discussion

ClientError::Other(format!("Error loading file {}: {}", keyfile.display(), e))
})?;

let match_type = if sign_opts.label.is_some() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like the enum way of doing this!

One nit here: Probably better to do an if let Some(label) = sign_opts.label.as_ref() instead

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used Match now, as we are matching based on 2 expressions, using if let I felt is a bit strange !!
https://github.com/VishnuJin/bindle/blob/e9e0100b3cca0f5301649f6e5d213fd9aab54f56/bin/client/main.rs#L253-L260

fn get_first_matching(
&self,
role: &SignatureRole,
label_match: LabelMatch,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better if we did Option<LabelMatch> and drop the LabelMatch::None? That might be a bit cleaner and makes it so people don't have to import LabelMatch if they aren't using it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I thought its good to have a Default implementation that can be used in test files etc rather than just using None
but let me know if I can change this to Option<LabelMatch > !!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to Option and removed LabelMatch::None

@thomastaylor312 thomastaylor312 dismissed their stale review April 8, 2022 17:28

Discussing new implementation

@VishnuJin VishnuJin force-pushed the feat-label-search-for-sign-invoice branch from b88180a to e9e0100 Compare April 9, 2022 05:32
@VishnuJin VishnuJin force-pushed the feat-label-search-for-sign-invoice branch from e9e0100 to ab0b9b2 Compare April 9, 2022 07:11
@VishnuJin
Copy link
Contributor Author

@thomastaylor312 this is ready for review now

}
}
/// This enumerates the select criteria of the key based on the given Label
pub enum LabelMatch {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for another comment here. This is entirely optional, but just wanted your opinion as this API will be used relatively often and I was wondering if this could be cleaner:

pub enum LabelMatch<'a> {
    /// Key will be selected with an exact match of the given label.
    /// Matches are case sensitive
    FullMatch(&'a str),
    /// Key will be selected with a partial match of the given label,
    /// Matches are case insensitive.
    ///
    /// For example: "pika" will match "Pikachu" and "puff" will match "Jigglypuff"
    PartialMatch(&'a str),
}

This would make the enum cheap to construct and no need to copy the String. It also would avoid having an Option<&LabelMatch> in a function signature.

We can also just merge and come back to this later, but if you do have an opinion, I'd love to hear it!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I had this with lifetime at first but when having it inside first_matching_key function in main.rs I had trouble with the life time reference as expected. Since these string are small I thought its okay to not use reference.
But can I give it another try to have &'a str like before

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nah, no problem. We'll keep this as is and revisit down the line if we want to try again!

@thomastaylor312 thomastaylor312 merged commit a6d246b into deislabs:main Apr 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add label search to sign-invoice

2 participants