Mailvelope default keyring identifier

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Mailvelope default keyring identifier

Kyle Francis
I noticed in app.js the default mailvelope keyring identifier is set to
this.user_id, which is a long unique identifier.  This produced an
unexpected behavior for me.  My use case was as such:

I initially installed Mailvelope, exported my GPG keys from
roundcube/enigma and loaded them into Mailvelope (no issues).  Then I
attempted to encrypt an outgoing email using the Mailvelope api plugin
(vice the enigma plugin) and was told that Mailvelope was unable to find
the requisite public keys for the intended recipient.  Wait, what?  I
just imported those in the last step... In debugging app.js through the
browser I saw that the keyring was in fact empty, yet the only keyring I
saw through the plugin interface in Firefox was the default keyring that
I had previously imported keys into.  It wasn't until I used the
mailvelope API to manually open the settings page for the new keyring
that I was able to in face see the alternate keyring (and subsequently
add keys to it).

As it turns out, the default keyring identifier used by the Mailvelope
plugin is in fact 'mailvelope'.  Would it make more sense to default to
that keyring instead of initializing a new one off of the user_id in
Roundcube?  Are there any conflicts that I'm not thinking of?  I suggest
this change since I wasn't even able to find the new roundcube keyring
from the user interface in the first place.

To me this seems "more intuitive", but then again my HCI course isn't
until the fall semester ;)

If this would be useful I would be more than happy to submit a PR.

Kyle
_______________________________________________
Roundcube Development discussion mailing list
[hidden email]
http://lists.roundcube.net/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Mailvelope default keyring identifier

Thomas Bruederli-2
Hi Kyle

The default keyring of Mailvelope is only used (and accessible) when
Mailvelope hooks itself into a web application. When using Mailvelope
via the API, each site/host only has access to dedicated keyrings
which are bound to the scope of that site. According to the answer
from the Mailvelope developer, the default keyring is only accessible
from host 'localhost'.

That information however, is already over 6 months old and I didn't
test with more recent versions of Mailvelope. If you find a way to use
the default keyring, you're welcome to submit the necessary changes.
Otherwise, feel free to open an issue for that in
https://github.com/mailvelope/mailvelope/issues

Best,
Thomas


On Sat, Jul 9, 2016 at 12:41 AM, Kyle Francis <[hidden email]> wrote:

> I noticed in app.js the default mailvelope keyring identifier is set to
> this.user_id, which is a long unique identifier.  This produced an
> unexpected behavior for me.  My use case was as such:
>
> I initially installed Mailvelope, exported my GPG keys from roundcube/enigma
> and loaded them into Mailvelope (no issues).  Then I attempted to encrypt an
> outgoing email using the Mailvelope api plugin (vice the enigma plugin) and
> was told that Mailvelope was unable to find the requisite public keys for
> the intended recipient.  Wait, what?  I just imported those in the last
> step... In debugging app.js through the browser I saw that the keyring was
> in fact empty, yet the only keyring I saw through the plugin interface in
> Firefox was the default keyring that I had previously imported keys into.
> It wasn't until I used the mailvelope API to manually open the settings page
> for the new keyring that I was able to in face see the alternate keyring
> (and subsequently add keys to it).
>
> As it turns out, the default keyring identifier used by the Mailvelope
> plugin is in fact 'mailvelope'.  Would it make more sense to default to that
> keyring instead of initializing a new one off of the user_id in Roundcube?
> Are there any conflicts that I'm not thinking of?  I suggest this change
> since I wasn't even able to find the new roundcube keyring from the user
> interface in the first place.
>
> To me this seems "more intuitive", but then again my HCI course isn't until
> the fall semester ;)
>
> If this would be useful I would be more than happy to submit a PR.
>
> Kyle
> _______________________________________________
> Roundcube Development discussion mailing list
> [hidden email]
> http://lists.roundcube.net/mailman/listinfo/dev
_______________________________________________
Roundcube Development discussion mailing list
[hidden email]
http://lists.roundcube.net/mailman/listinfo/dev