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

Keys on my keychain don't appear in Key Manager #92

Open
Stubbs opened this issue Sep 2, 2013 · 13 comments
Open

Keys on my keychain don't appear in Key Manager #92

Stubbs opened this issue Sep 2, 2013 · 13 comments

Comments

@Stubbs
Copy link

Stubbs commented Sep 2, 2013

According to the options page "Your system appears to be configured correctly for WebPG" but when I try and view keys, either public or private the list is empty.

If I try & use the binary I entered into the settings (/usr/local/bin/gpg -k) I get a list of the keys as expected.

I'm using the current dev version, 0.9.4

@kylehuff
Copy link
Owner

kylehuff commented Sep 2, 2013

@Stubbs it appears that WebPG is unable to locate your keyring(s). Normally, WebPG is able to automatically detect the location, but you may need to specify the path to your GNUPGHOME directory within the advanced options of WebPG.

Which installation of GnuPG is this and on what operating system?

@Stubbs
Copy link
Author

Stubbs commented Sep 2, 2013

I'm using GPG installed from the GPGTools website (for OSX), the latest version which I upgraded today. I'm using the Firefox version of the plugin too, with the latest version of Firefox.

I've got the GNUPGHOME advanced option set to my .gnupg directory in my home directory, it was set to the directory where gpgtools was installed, and now I just get the box that says "Please wait while we build your keylist" which never dissapears.

Extension Information
Extension version: 0.9.4
Platform: MacIntel
Product: Firefox
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0
Language: en-US

Plugin Information
Plugin version: 0.6.5
Plugin path: /Users/stuart/Library/Application Support/Firefox/Profiles/k7pkm1h7.default/extensions/[email protected]/plugins/npwebpg-ext-v0.6.5-Darwin_x86_64-gcc.plugin/Contents/MacOS/webpgPlugin

GnuPG Information
GnuPG version: 2.0.20
GnuPG binary: /usr/local/bin/gpg
GnuPG home directory: /Users/stuart/.gnupg
GPGCONF version: 2.0.20
Assuan version: not detected

@kylehuff
Copy link
Owner

kylehuff commented Sep 2, 2013

that is curious... Is this the light version of GPGTools?

Also, when you try to display the WebPG key manager, if you open the javascript console are there any errors?

@Stubbs
Copy link
Author

Stubbs commented Sep 2, 2013

It's not the lite version, and there are no errors on the js console either.

-S
"It is vital that our younger generations, the guardians of our future,
develop strong awareness concerning the futility of war." - Dalai Lama

Follow me on Twitter: http://twitter.com/stubbs
Blog: http://stubblog.tumblr.com

On 2 September 2013 16:06, Kyle L. Huff [email protected] wrote:

that is curious... Is this the light version of GPGTools?

Also, when you try to display the WebPG key manager, if you open the
javascript console are there any errors?


Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-23665291
.

@kylehuff
Copy link
Owner

kylehuff commented Sep 2, 2013

Assuan version: not detected

This is why I was asking about the "light" version -- Assusan may very well be present, but undetected. That is not the cause of the issue at hand, but may be a symptom of the same root issue.

Do you have a lot of keys public keys by chance? (greater than 100 or so)

@Stubbs
Copy link
Author

Stubbs commented Sep 2, 2013

Yes, I have a couple of hundred peoples public keys imported into my
keyring.

I've never heard of Assuan before, I don't suppose you know where it's
usually kept on an OSX filesystem?

-S
"It is vital that our younger generations, the guardians of our future,
develop strong awareness concerning the futility of war." - Dalai Lama

Follow me on Twitter: http://twitter.com/stubbs
Blog: http://stubblog.tumblr.com

On 2 September 2013 16:16, Kyle L. Huff [email protected] wrote:

Assuan version: not detected

This is why I was asking about the "light" version -- Assusan may very
well be present, but undetected. That is not the cause of the issue at
hand, but may be a symptom of the same root issue.

Do you have a lot of keys public keys by chance? (greater than 100 or so)


Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-23665764
.

@kylehuff
Copy link
Owner

kylehuff commented Sep 2, 2013

I've never heard of Assuan before, I don't suppose you know where it's usually kept on an OSX filesystem?

You shouldn't need it -- it is a utility for exchanging data with non-persistent servers. GnuPG uses it for context operations on the secret keyring. I merely noticed it was not present, and was curious if it was an indicator that some other (required) elements of the GnuPG installation were not present; namely, the key-agent.

Yes, I have a couple of hundred peoples public keys imported into my keyring.

At present, the WebPG Key Manager attempts to retrieve ALL keys within your keyring, parse them and display them. More than likely this is taking an extraordinarily long time. This is an issue on all platforms, but seems to be exacerbated on OSX (on Linux, the same operation takes roughly 1/3rd of the time).

I am working on having the return of Public Keys support pagination - whereby it only retrieves a subset of the total keys available, and also working to have these blocking operations occur within a separate thread like the key generation does (so it doesn't lock up the browser).

More than likely, it is working, just having a lot of difficulty processing your large keyring.

So unfortunately this time, I do not have a solution for your issue, I plan to have the required changes into the back-end library no later than version 0.9.6. However, the other functionality (outside of the key manager) should continue to function [i.e. sign, encrypt, verify].

Outside of that (waiting for future releases), I could only suggest that you point WebPG to a paired down keyring. I understand that this affects trust calculations and violates one or more primary concepts of GnuPG -- merely attempting to provide some sort of workaround that may address your issue and fit the needs of your intended usage of WebPG.

@Stubbs
Copy link
Author

Stubbs commented Sep 3, 2013

Thanks Kyle.

Most of the people on my keychain I have never mailed, or received a mail
from, they're there because I once did an import and asked it to recurse
across all the keys that had signed keys I had in my keyring.

I'll prune my keyfile and see what effect that has.

-S
"It is vital that our younger generations, the guardians of our future,
develop strong awareness concerning the futility of war." - Dalai Lama

Follow me on Twitter: http://twitter.com/stubbs
Blog: http://stubblog.tumblr.com

On 2 September 2013 16:43, Kyle L. Huff [email protected] wrote:

I've never heard of Assuan before, I don't suppose you know where it's
usually kept on an OSX filesystem?

You shouldn't need it -- it is a utility for exchanging data with
non-persistent servers. GnuPG uses it for context operations on the secret
keyring. I merely noticed it was not present, and was curious if it was an
indicator that some other (required) elements of the GnuPG installation
were not present; namely, the key-agent.

Yes, I have a couple of hundred peoples public keys imported into my
keyring.

At present, the WebPG Key Manager attempts to retrieve ALL keys within
your keyring, parse them and display them. More than likely this is taking
an extraordinarily long time. This is an issue on all platforms, but seems
to be exacerbated on OSX (on Linux, the same operation takes roughly 1/3rd
of the time).

I am working on having the return of Public Keys support pagination -
whereby it only retrieves a subset of the total keys available, and also
working to have these blocking operations occur within a separate thread
like the key generation does (so it doesn't lock up the browser).

More than likely, it is working, just having a lot of difficulty
processing your large keyring.

So unfortunately this time, I do not have a solution for your issue, I
plan to have the required changes into the back-end library no later than
version 0.9.6. However, the other functionality (outside of the key
manager) should continue to function [i.e. sign, encrypt, verify].

Outside of that (waiting for future releases), I could only suggest that
you point WebPG to a paired down keyring. I understand that this affects
trust calculations and violates one or more primary concepts of GnuPG --
merely attempting to provide some sort of workaround that may address your
issue and fit the needs of your intended usage of WebPG.


Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-23667209
.

@kylehuff
Copy link
Owner

kylehuff commented Feb 8, 2014

The current development cycle now has threaded and paginated key listing. This should resolve this issue.

Would you be willing to verify so I can close this issue? Thanks.

@RainerKlute
Copy link

I just discovered WebPG and experienced what seems to be same problem. I installed WebPG 0.9.2 in Firefox 33.1 on Linux (64 bit). The key manager says "building key list" since 90 (!) minutes now. I have ca. 800 keys in my keyring.

I also tried to install WebPG in Chromium 37.0.2062.94 (290621) (64-bit) on the same machine, but failed because NPAPI plugins are not supported.

@kylehuff
Copy link
Owner

@RainerKlute

I installed WebPG 0.9.2 in Firefox 33.1 on Linux (64 bit). The key manager says "building key list" since 90 (!) minutes now. I have ca. 800 keys in my keyring.

Yes, that is the single-threaded, synchronous version. Could you try v0.9.4 located here: https://webpg.org/download/webpg-firefox/

I also tried to install WebPG in Chromium 37.0.2062.94 (290621) (64-bit) on the same machine, but failed because NPAPI plugins are not supported.

A solution that does not use NPAPI is being tested now, so chrome support will be restored shortly.

@RainerKlute
Copy link

Yeah, 0.9.4 looks very good, thank you!

(Now if the decrypted e-mail would also recognize the Content-Transfer-Encoding: quoted-printable header and format it accordingly …)

@kylehuff
Copy link
Owner

Yeah, 0.9.4 looks very good, thank you!

Awesome.

(Now if the decrypted e-mail would also recognize the Content-Transfer-Encoding: quoted-printable header and format it accordingly …)

Yes, the QP (de/en)coder has some issues; that is a work in progress.

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

3 participants