lots of problems, missing Crypto.Cipher?
Eric
I'm having a lot of trouble getting the keyring library to do anything
useful. I'm attempting to use it with mercurial_keyring, and it seems
to be able to save something to keyring_pass.cfg, but it won't use it
on subsequent commands:
[Mercurial]
hawicz@@https = //hgserver:8443/hg/repo1 = ...snip...=
hawicz@@https://hgserver:8443/hg/repo1 = ...snip...=
I then noticed that this might not actually be using the encrypted
keyring format so I tried to override it, but I couldn't figure out
what to put in keyringrc.cfg. I described some of this in a bug
(http://bitbucket.org/kang/python-keyring-lib/issue/23/), but I'm
hoping someone here can help me out. Until I tried fiddling with the
actual python code the best I could do was get an error of:
TypeError: The keyring must be a subclass of KeyringBackend
After I commented out that check, I started getting:
abort: could not import module Crypto.Cipher!
I tried looking for where to get this from, but the closest I found
was something called cryptopy, but that had all sorts of issues
(encoding problems, everything is lower case, apparently a different
api)
Am I supposed to be using a different version of python? (i've got a
plain vanilla 2.6.2 installed)
Marcin Kasperski
> hawicz@@https = //hgserver:8443/hg/repo1 = ...snip...=
> hawicz@@https://hgserver:8443/hg/repo1 = ...snip...=
The problem is that keyring does not document requirements for keys,
but attempts to save them without any escaping as ini-file keys. This
problem could be worked around in mercurial_keyring (by using some
escaping scheme there) but I don't even have a chance to ask keyring
whether it requires escaping, or not...
The natural solution would be to patch keyring text backend so it escapes keys.
> I then noticed that this might not actually be using the encrypted
> keyring format so I tried to override it, but I couldn't figure out
> what to put in keyringrc.cfg.
I haven't diagnosed those issues in detail, but practically I had
better luck using Steve Borho fork
(https://bitbucket.org/sborho/python-keyring-lib) which tended to
properly guess correct backend in my cases. There are also a few other
forks on bitbucket.
Tarek Ziadé
<Marcin.K...@mekk.waw.pl> wrote:
>> [Mercurial]
>> hawicz@@https = //hgserver:8443/hg/repo1 = ...snip...=
>> hawicz@@https://hgserver:8443/hg/repo1 = ...snip...=
>
> The problem is that keyring does not document requirements for keys,
> but attempts to save them without any escaping as ini-file keys. This
> problem could be worked around in mercurial_keyring (by using some
> escaping scheme there) but I don't even have a chance to ask keyring
> whether it requires escaping, or not...
>
> The natural solution would be to patch keyring text backend so it escapes keys.
I don't have the bandwidth to work on keyring right now, but I can
reveiw/commit patches
>
>> I then noticed that this might not actually be using the encrypted
>> keyring format so I tried to override it, but I couldn't figure out
>> what to put in keyringrc.cfg.
>
> I haven't diagnosed those issues in detail, but practically I had
> better luck using Steve Borho fork
> (https://bitbucket.org/sborho/python-keyring-lib) which tended to
> properly guess correct backend in my cases. There are also a few other
> forks on bitbucket.
We would be happy to merge them
Cheers
Tarek
--
Tarek Ziadé | http://ziade.org
Tarek Ziadé
> I haven't diagnosed those issues in detail, but practically I had
> better luck using Steve Borho fork
> (https://bitbucket.org/sborho/python-keyring-lib) which tended to
> properly guess correct backend in my cases. There are also a few other
> forks on bitbucket.
I have merged this fork and I'll release a 0.3 soon.
Marcin Kasperski
> reveiw/commit patches
OK, I will think about them. But don't hold 0.3 waiting for it (I hope
0.4 can happen sooner if there are worthwhile changes...)