Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NotImplementedError: Saving of JCEKS keystores is not implemented #33

Open
jcdevil opened this issue May 31, 2017 · 9 comments
Open

NotImplementedError: Saving of JCEKS keystores is not implemented #33

jcdevil opened this issue May 31, 2017 · 9 comments

Comments

@jcdevil
Copy link

jcdevil commented May 31, 2017

Hello,
At the moment, when saving a keystore of type "JCEKS"m I get the following error :

NotImplementedError: Saving of JCEKS keystores is not implemented 

Is the implementation on the way / planned ?
For sure.... this is not to set pressure on it ^^ but as I find this library promising, I just wanted to be informed about it ;)
Thx for your answers !

@mahmoud
Copy link
Collaborator

mahmoud commented May 31, 2017

Unless @magnuswatn or @voetsjoeba will be surprising us again, I think the current set of formats is all that's planned for the moment. If you'd like to take a swing, by all means!

@kurtbrose
Copy link
Owner

kurtbrose commented Jun 1, 2017 via email

@voetsjoeba
Copy link
Contributor

voetsjoeba commented Jun 9, 2017

I've had a local branch that implements writing all keystore types for a while, but I've been hesitant to push it out for the same reasons as originally discussed in PR #29 when JKS write support came up, i.e. I'm not so sure the choice of cryptographic parameters for JCEKS and BKS keystores is as straightforward as it may seem ...

@mahmoud
Copy link
Collaborator

mahmoud commented Jun 9, 2017

@voetsjoeba yeah I think now that there's a concrete case, I think creating a warning type and emitting a warning is a reasonable course. Alternatively, we could require the extra step of setting an attribute, like allow_obsolete_crypto on the JKS object, which must be manually set to True, otherwise we raise an exception. I kind of like the explicitness of the second approach.

@mahmoud
Copy link
Collaborator

mahmoud commented Jun 9, 2017

(Alternatively, could have it as a kwarg to those methods, too.)

@voetsjoeba
Copy link
Contributor

That sounds like a good approach. We could start off with the same choices/ranges as the original JCEKS and BC implementations, then do some testing to see if any increases are generally well accepted by major keystore readers and go from there to decide whether we want to use those as the defaults. I'll try to find some time to work on that.

@FrugalGuy
Copy link
Contributor

I’d like to bump this up. I would like to be able to store client IDs and API keys in a jceks but having to go write up a Java program to do it makes this library less useful.
Any chance we could get a jceks that can store password strings soon?

@FrugalGuy
Copy link
Contributor

FWIW, for PBE parms, I’d be thrilled with PBKDF2WithSha256, AES128 and 10,000 iterations.

1 similar comment
@FrugalGuy
Copy link
Contributor

FWIW, for PBE parms, I’d be thrilled with PBKDF2WithSha256, AES128 and 10,000 iterations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants