kylehuff / webpg-chrome Goto Github PK

Requires upstream method to invoke the passphrase change against the agent.

In order to display information about the key, WebPG has the ability to import the key and discard it after retrieving the required information. This happens automatically but really should be at the user preference.

The Key ID of subkeys displays the Key ID of the primary subkey for all keys.

Needs to be changed to use the proper Key ID

The default size for the "Change Expiration" button is not large enough if the calendar/datepicker is visible.

The Enable button should be removed; either the extension is enabled in the browser or it isn't. there is no need for this option.

The associated localStorage key also needs to be unset/cleared to not waste space.

The current verbiage states: "this key is already in your keyring", which is confusing after executing an import. It should state "this key is in your keyring" or something like that.

The private-key list has "Enable" and "Default" key options, but there is nothing that indicates to the user what this actually does. This needs to be explained somehow.

Expired keys do not list the date they were set to expire, they only display "Expired" - the user may want/need to see actual date.

The key generation dialog requires that the UID field be at least 5 chars long, however the logic is backwards and complains if the UID field is more than 5 chars long.

Signed messages are currently passed directly to the decrypt method, which works great, except if the message is not a signature and instead a block of encrypted text, we have no choice but to attempt to decrypt it.

If we first run blocks that begin with "---- BEGIN PGP MESSAGE ----" through a signature verify method, we can determine if it is a signed message that should be sent to the decrypt method, or instead marked as something the user can decrypt at a later time.

This requires an upstream change to webpg-npapi, as there is currently no verify method.

An example of why to limit to 10 would be cases like this page that has 60 keys!

(do not click on that link if you have webpg with less than version v0.4.0 installed with inline parsing. You will never get your browser back unless you have unlimited amounts of memory.)

http://www.apache.org/dist/httpd/KEYS

This will simplify the "App" version of webpg-chrome, as well as make the UI a little better/cleaner

General GPG preferences need to be added to the options page.

This requires an upstream change to add a public method for managing preferences.

Because the pre/post text is derived from .textContent, none of the original HTML is included.

Maybe consider using an HTML Range object to detach the PGP signature and leave the pre/post text in place?

Signatures that originated from a user key should have an option to revoke the signature.

This will depend on upstream changes to the webpg-npapi

The iter referenced in some callbacks has already advanced - need to assign the value of the array[iter] to a local variable before calling the method that executes the callback referencing the array.

WebPG doesn't display anchor tags in the verified text window. Well, it displays the text part, but doesn't display it as a clickable link. I'm guessing this was a conscious decision because people may think that the verification happened to the actual link, rather than just the text of the anchor?

Would it be possible to make it so that if the link text is the same as the href attribute, then an anchor is created in the verifiied text display?

If you take a look at https://grepular.com/webpg/ you will see that I have numerous links like this. I used the actual link in the anchor text so that people can verify that the URL it's self was signed. But if you have WebPG with inline detection turned on, all of those links just become text.

The absence of a 64bit binary causes issues for systems with 64bit compiled libgpgme, so we need to include a 64bit compiled binary.

This needs to, if at all possible, make it into the chrome webstore by 2011/10/04, as this affects run ability for some users.

The "display original" and "import" links are not working on inline-parsed public keys due to a change in the ordering of the jQuery selector(s).

WebPG has handles the "Default Key" assignment and tracking outside of the GnuPG - they really should be tied together as there is no functional distinction between the two.

This requires an upstream change to webpg-npapi, as there is no set_preference method available publicly.

There is an alert that warns the user that the Add UID function does not exist, when in fact it does.

FireGPG uses random letters, that are present both in the verified inline content and in an area outside the page content (tool- or statusbar). This would make it sure, that the message verification was indeed done by WebPG and is not just some HTML magic.

This is presumably the reason why some builds of Chrome v15 (unstable) have trouble with the XHR request.

Signatures on UIDs are nearly useless, they only display the key id and the UID of the signer. No other information is parsed.

Some items needing to be added -

• signature date
• revocation status
• expiration

The front page of my website is PGP signed:

https://grepular.com/

Copy and paste that content into the following command and it will automatically fetch my public key and verify it:

gpg --verify-options pka-lookups --keyserver-options auto-key-retrieve --verify

WebPG doesn't automatically detect the inline PGP because of the structure of my page. So I decided to modify the page to work with WebPG. I've successfully managed it. It's currently sat here:

https://grepular.com/webpg/

However. The way WebPG displays that content is horrendously ugly. The content is shifted right, and goes off the right hand side of the viewport. it also doesn't retain the text formatting. Specifically the use of a monospace font, and pre tags to line up spacing.

Even FireGPG does much better at rendering this content... FireGPG displays the content in the correct position, and even retains the spacing. Like WebPG it doesn't use a monospace font in appropriate places though.

webpg_results.html references a missing CSS file.

Elements in webpg_results.html only reference inline CSS styles and IDs anyway, this inclusion can be deleted

This needs to be resolved somehow. Maybe pagination?

The "Make Primary" button on UIDs should be unavailable or hidden entirely for UIDs that are revoked or invalid.

The height for the "Add UID" dialog on windows is rendered too short and causes scroll bars.

The parsing of Public Keys references a variable that is modified outside of the scope of the original request. This should be changed to reference a local, non-changing variable so we can display more than one public key on the same page.

Need to create the ability to sign/clear-sign text contained in textarea elements.

There should be the ability to have a secured object (iframe) for typing plaintext into that will be encrypted and then the contents placed into into the original element after the encryption.

Blocks of decrypted text are already injected into an iframe object that is inaccessible to the webpage.

The regex(s) for detecting PGP data on web-pages is not great. Needs serious rework.

Add some icons, transition effects, etc.

On MS Windows the SELECT elements are styled in a manner that makes the current selection un-readable.

WebPG parses PGP DATA blocks contained on web pages; there should exist a user preference to enable/disable this functionality.

We need to change the signing functions to allow the user to specify what type of signature they want to create. Currently only non-exportable trust signatures are possible because it is hard-coded (a throwback from gpgauth-chrome)

The button to revoke public keys needs to be removed, it should only exist for private keys.

The ability to export public keys needs to be written.

This depends on an upstream change in webpg-npapi

The graphics/images used for the chrome webstore should be added to the repository.

I don't know what you use GA for, but I would strongly recommend you to remove it.