1.0 plans

[hwchen]

Next plans for this lib:

• figure out cross-compilation details (making sure unneeded dependencies are not compiled?) (v0.3.0)
• windows backend (v0.3.0)
• design: should osx keychain be unlocked from cli (only required from ssh)?
• traits-based design?
• tests and CI.
• docs
• osx backend with https://crates.io/crates/security-framework (which I think should work)

Edit (9/27/2018):

I think this library has been used enough that I'm going to go ahead and plan for 1.0 without major changes to this library. I only need to clean up the secret-service library a bit, move that to 1.0, and then I'll be able to release 1.0 here.

See new issue: #21

[steveatinfincia]

I would be happy to help convert the OS X support to use security-framework :)

At the moment I think the only thing blocking that is support for storing/retrieving generic passwords in the keychain in security-framework, but there is a pull request open for that. I may take a look at that as well to see if there is anything I can do to help get that one merged.

[hwchen]

That would be awesome! Keep me posted.

[steveatinfincia]

I'm about 95% done with the OS X keychain support, just doing some testing :)

[hwchen]

Awesome, looking forward to it!

…

On Mar 13, 2017, 1:17 PM -0400, Stephen Oliver ***@***.***>, wrote: I'm about 95% done with the OS X keychain support, just doing some testing :) — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub (#5 (comment)), or mute the thread (https://github.com/notifications/unsubscribe-auth/ADm0i1Tqt-0gt0VNdwJgbwfn_G-Ce5tRks5rlXoMgaJpZM4Lw3qf).

[dario23]

will there be support for setting a different application name on linux in the forseeable future? :-)

[hwchen]

@dario23 Could be :) I'll be doing some updates to dependencies soon (including winapi 0.3 and a pull request for rpassword), so I'll try to also do work for support for different application names.

[dario23]

i could write a pull request as well; but the question (i guess) isn't about who writes the (presumably) short patch, but rather how you'd want it to fit into the existing API

• the types for linux, windows and osx are currently different types with the same signature; how willing are you to have the implementations diverge?
• alternatively it could be a possibility to have a "set the application name" part in the API for all variants, that doesn't do anything for osx/windows; or (if possible, not sure) a separate method that is later called and sets the application name to something else?

[hwchen]

@dario23 sorry for delay. I've finally had some time to look over my code and think about your suggestions.

Something that would help me decide on the API is how you're using application differently than service.

I prefer that implementations do not diverge; it's better that I have responsibility for keeping all the cross-platform stuff in order, otherwise the code that users write will not be easily cross-platform.

I do think that your second option is maybe possible, I just want to check on your use case and see if there's another solution possible.