NotImplementedError: Saving of JCEKS keystores is not implemented

[jcdevil]

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]

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]

Yes, please by all means we love PRs!

Your energy and enthusiasm is appreciated.

On Wed, May 31, 2017 at 4:28 PM, Mahmoud Hashemi notifications@github.com wrote:

Unless @magnuswatn https://github.com/magnuswatn or @voetsjoeba https://github.com/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!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kurtbrose/pyjks/issues/33#issuecomment-305346824, or mute the thread https://github.com/notifications/unsubscribe-auth/AAhMvj4DkDP1bnYt85TzXXE65MSxv_zDks5r_fevgaJpZM4NsP3C .

[voetsjoeba]

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]

@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]

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

[voetsjoeba]

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]

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]

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

[FrugalGuy]

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