Send button on GMail no longer works.
Closed this issue · 13 comments
I'm sorry if this observation seems redundant. I currently have WebPG 0.9.4 installed under Chrome, and WebPG 0.9.2 installed under Firefox, because those were the versions offered via the official sites for the respective extensions. But even though it should have been a breeze to get this up and working, GMail Integration works in neither browser. I have Gpg4win installed, because currently I'm sitting in front of a Windows computer, and Kleopatra and Enigmail (with Thunderbird) work fine, and manage my keys effortlessly.
The main problem I seem to run in to under Chrome, is that directly to the right of he WebPG button, the GMail Send button doesn't work, unless I select via the WebPG button, 'not to use WebPG for this message'. I choose my WebPG options, the extension seems to display the appropriate messages within the Compose Window, but then if I click on Send, the Send button just seems to remain depressed - with no reaction of any sort - until I next right-click within the Compose Window, which then releases the Send Button, but without having done or sent anything. Pressing Ctrl+Enter or whatever, which is supposed to be the keyboard shortcut for Send, causes the message simply to be sent without encryption or signature. And I never get asked for my pass-phrases, which the extension should be asking me for, for some of the keys I'd be using.
Selecting the "Clearsign" command with the right-click menu from within the Compose Window, also has no effect in v0.9.4 under Chrome, where the context menu commands are also missing their icons. And with v0.9.2 under FF, at least the menu entries display their icons, the extension asks me for my pass-phrase as it should, and it clearsigns the message in-place. But then I have no option to Send that message again.
Dirk
I just wanted to add a tentative observation.
It seems that my earlier suspicion was wrong, according to which WebPG could not force a pinentry dialog under Windows. If I whittled down the set of keys that could be used to sign with - i.e. sender, private keys - then v0.9.2 with Firefox does again display the pinentry dialog - for that one key - when I choose to Clearsign from the context menu. Remember, this was the WebPG version which could not select between different keys from the little 'WebPG' button. But then as I wrote above, I'm given no ability actually to send this email.
Further, (after clearing my browser cache,) when I right-click to Encrypt, v0.9.2 at least shows me the dialog, from which I'm to select which recipients It's to encrypt to. Now, if I do so and click on the Encrypt button within that dialog, a half-second time-delay seems to pass, before the Encrypt button goes back to its sensitive state. But I don't see any encrypted text within the GMail Compose Window. What I'm inferring, is that in order to send the encrypted emails, I'd next need to click on Send, the function of which has been overridden with WebPG's function.
But precisely that Send button no longer seems to work, either under the FF version (0.9.2), nor under the Chrome version (0.9.4).
And you see one concept which I find very plausible, is that the GMail team could view any attempt to override what that Send button does, as a potential security threat to its clients (from other extensions than WebPG, of course), for which reason they may have changed the design of their Compose Window. Also, by now they may see any substitution of what gets displayed within their message Viewing Window, let's say even by decrypted text, or by a visual that tells the user the signature is valid, as a potential hack against their 'normal-use' clients...
Dirk
Could you verify if this occurs in the current build of v0.9.4? There are downloads for v0.9.4 for chrome and firefox respectively, located here - https://webpg.org/download/
I have followed your advice.
For Firefox: Downloaded version 0.9.4 does in fact fix the issue I was describing, which was therefore a duplicate of issue #82. However, during another experiment of mine, I found that even version 0.9.4 for Firefox suffered from /the other/ critical problem, which was that it wraps the lines of encrypted data when sending, thereby making the program useless, as such emails cannot be decrypted again.
For Chrome: I had already written, that the version available on the Chrome Web-store was version 0.9.4 . For some reason, even after I side-loaded the extension from your suggested site, Chrome immediately deactivated it, with the notice to me saying that I will not be allowed to reactivate it. It's against Google policy to allow users to side-load extensions. And even if we drag the extension-file into the extensions page, my browser just forces its deactivation.
Version 0.9.4 for Chrome, still suffers from this issue #82 . Version 0.9.4 for Firefox, suffers from the additional problem, that it displays two, not one, Send buttons, and only the second one works.
Finally, one really stupid behavior GMail has for my account, is to log me out of GMail, every time the WebPG extension decrypts something, and displays its substituted content for the email Viewing Window. This also prohibits me from looking at the original message source in my browser, let's say because the lines got wrapped, because it would take me longer than 2 seconds to click in the right place.
Dirk
... during another experiment of mine, I found that even version 0.9.4 for Firefox suffered from /the other/ critical problem, which was that it wraps the lines of encrypted data when sending, thereby making the program useless, as such emails cannot be decrypted again.
Was the encryption done using the right-click context menu, or via the "Send" button?
I had already written, that the version available on the Chrome Web-store was version 0.9.4.
Yes, the version in the webstore is v0.9.4, however, the version in the download is v0.9.4 build 142 (or thereabout) - the builds are difficult to differentiate due to the version string requirements. Once the changes in version of 0.9.4 that is hosted on webpg.org have been signed off on, I will push it to the chrome webstore.
For some reason, even after I side-loaded the extension from your suggested site, Chrome immediately deactivated it, with the notice to me saying that I will not be allowed to reactivate it. It's against Google policy to allow users to side-load extensions.
Yes, I forgot that Chrome enacted that policy on windows to compensate for the fact that windows is a security-hole ridden, bloated and predominately unsafe operating system. The fixes for chrome on windows will have to wait until I can update the webstore package.
Version 0.9.4 for Firefox, suffers from the additional problem, that it displays two, not one, Send buttons, and only the second one works.
I have not seen this issue before... Are you using the gmail interface with a google-apps setup? (i.e. a non-google email account hosted through gmail)
Finally, one really stupid behavior GMail has for my account, is to log me out of GMail, every time the WebPG extension decrypts something, and displays its substituted content for the email Viewing Window. This also prohibits me from looking at the original message source in my browser, let's say because the lines got wrapped, because it would take me longer than 2 seconds to click in the right place.
Is this in Firefox, or Chrome? I expect it with Chrome, given that there is a bug in WebPG, but I do not expect that in Firefox. That issue should have been fixed in v0.9.4 hosted on webpg.org...
Was the encryption done using the right-click context menu, or via the "Send" button?
Using the right-click context menu, which resulted in a correctly-formed block of lines in the Compose Window. Only after I sent the email to my other address, and opened it with Icedove, were the lines wrapped. And from there, I was able to (Shift+Forward) it to myself, with some of the lines corrected manually, to find my original, 3-line message decrypted correctly...
Version 0.9.4 for Firefox, suffers from the additional problem, that it displays two, not one, Send >>buttons, and only the second one works.
I have not seen this issue before... Are you using the gmail interface with a google-apps setup? (i.e. >a non-google email account hosted through gmail)
No. This was a GMail account, predating my use of an Android device. By now, I have 2 Android devices though, that use this GMail. And, while I got this behavior from my Windows box, my Linux box displayed the first button correctly as the WebPG button, while displaying the second correctly as the Send button, but again logged in to the same GMail account...
Finally, one really stupid behavior GMail has for my account, is to log me out of GMail, every time >>the WebPG extension decrypts something, and displays its substituted content for the email >>Viewing Window. This also prohibits me from looking at the original message source in my >>browser, let's say because the lines got wrapped, because it would take me longer than 2 seconds >>to click in the right place.
Is this in Firefox, or Chrome? I expect it with Chrome, given that there is a bug in WebPG, but I do >not expect that in Firefox. That issue should have been fixed in v0.9.4 hosted on webpg.org...
[Edit] Actually, since you asked me so precisely, I double-checked, and this behavior only seems to happen from the Chrome version (which is disabled by now). The Firefox version will allow me to view the substituted (Inline) visuals from your extension, as many times as I want, and regardless of whether the message comes through as valid or invalid.
Therefore, no IT Security team seems to be making an exaggerated attempt to protect me from 'encryption-monsters' after all. {:-D}
One point that I would like to comment on though would be: In order to enable potential PGP/MIME validation, you've enacted a system by which we can link GMail identities to your app. I had this enabled with Chrome, and now do have it enabled with Firefox. This simple extra permission, could also look suspicious to IT Security people, because depending on how you implemented it, this could look like an external log-in, and most importantly ~ a log-in which the user is aware of in this case, but which other users might not be aware of ~ , and which some users might not have authorized consciously, the way I did .
Just as a last observation: While there is a standard attachment-name, meant to be used for PGP/MIME , such as maybe ' default.asc ' , your linked Gmail identity should really be scanning for any one attachment named ' .asc ' , because if a different email client from yours *sends such an attachment, the other one could name it ' nobody.asc ' or anything else you'd find strange. As I see it now, your extension may well validate PGP/MIME sent by itself, but takes no opinion on emails sent - and signed - using the legitimate client Sylpheed, maybe just because the latter names that attachment differently... Food for thought.
Dirk
Sorry to bump.
But I found, that I was at least able to get WebPG to generate encrypted outgoing mail, which Enigmail (belonging to Thunderbird) was able to decrypt easily, by switching the Compose Window in GMail's Web-mail, to 'Rich Text' instead of 'Plain Text'.
I know this goes against best practices in cryptography, but just plain works.
However, WebPG is still unable to decrypt the resulting messages from my GMail Sent Folder, Inline.
So what I might try in the future, is to compose my message with the Compose Windows set to Plain Text, and then to Encrypt, since I'm using right-click to encrypt. Then, I could try switching the Compose Window to Rich Text, before I Send the message out... It's just that I don't feel like doing more tests right now.
Dirk
One point that I would like to comment on though would be: In order to enable potential PGP/MIME validation, you've enacted a system by which we can link GMail identities to your app. I had this enabled with Chrome, and now do have it enabled with Firefox. This simple extra permission, could also look suspicious to IT Security people, because depending on how you implemented it, this could look like an external log-in, and most importantly ~ a log-in which the user is aware of in this case, but which other users might not be aware of ~ , and which some users might not have authorized consciously, the way I did .
The permission request is not a construct of WebPG - that is an XOAUTH2 authorization request, as provided by google. It is an external authentication mechanism, and that is the manner in which it was designed. XOAUTH2 is used by many things, such as android devices, etc. The reason you were getting booted out of GMAIL was due a known issue in WebPG that has nothing to do with authorization or hacking -- it is because a request for an invalid URL in GMAIL kicks the user out. The bug in WebPG was requesting an invalid URL.
Furthermore, the linked account is only used for sending a PGP/MIME formatted message. It is not used for reading email or sending normal emails.
Moving on - The right-click context menu for WebPG is NOT intended to be used in GMAIL. Ever. The fact that it is even present in GMAIL is a bug. WebPG must carefully format messages and things in the background of GMAIL, and that can only happen with the SEND button when an appropriate WebPG action has been selected. So until I can fix the WebPG integration with the compose window on Windows, I do not expect any valid PGP messages to be sent.
Just as a last observation: While there is a standard attachment-name, meant to be used for PGP/MIME , such as maybe ' default.asc ' , your linked Gmail identity should really be scanning for any one attachment named ' .asc ' , because if a different email client from yours *sends such an attachment, the other one could name it ' nobody.asc ' or anything else you'd find strange. As I see it now, your extension may well validate PGP/MIME sent by itself, but takes no opinion on emails sent - and signed - using the legitimate client Sylpheed, maybe just because the latter names that attachment differently... Food for thought.
WebPG does not pay any attention to attachment file-names or suffixes. WebPG gathers the message and parses as a MIME message, then inspects the contents for PGP data. If you have valid PGP/MIME messages that are not being parsed correctly, I would need a sample or test email from that client to identify if I am missing a valid case, or if the client is sending malformed PGP/MIME messages in violation of the RFC.
Hello again.
WebPG does not pay any attention to attachment file-names or suffixes. WebPG gathers the >message and parses as a MIME message, then inspects the contents for PGP data. If you have >valid PGP/MIME messages that are not being parsed correctly, I would need a sample or test email >from that client to identify if I am missing a valid case, or if the client is sending malformed >PGP/MIME messages in violation of the RFC.
With that choice of words, 'that are not being parsed correctly (by WebPG)', you are asserting that WebPG makes some attempt to use its Linked GMail Identity, to parse inbound PGP/MIME data, and not just to generate it.
Well one thing which I did recently, was to use another established email client - namely Sylpheed - to sign a simple message, which it then sent from my main email account, to my GMail account, where WebPG was supposed to validate the signature. And Yes, Sylpheed will generally use PGP/MIME, and not Clear-Signing, aka PGP/Inline.
Until I downloaded version 0.9.4 for Firefox, v0.9.4 (release) for Chrome would get me kicked out of GMail every time I tried to complete this exercise at the receiving end.
Now that I'm narrowing my use of WebPG to v0.9.4 for Firefox, what I find instead is that the extension makes no attempt to detect or validate - and therefore to parse the PGP/MIME part of the message at all. And what I'm inferring, is that this is also the true reason fw I'm no longer getting logged out of GMail. Yet, where there are PGP/Inline signatures, WebPG seems to indicate their validity fine now - again without logging me out. And so here is a sample of what I see when WebPG has Decrypted a PGP/Inline message, sent with Thunderbird and Enigmail:
I trust I wouldn't need to prove its validity, given that WebPG has in fact decrypted it. It was just ASCII-armored code, even as received within GMail.
But now here is a sample email sent by Sylpheed, again to my GMail account, this time signed using PGP/MIME:
Date: Tue, 17 Jun 2014 23:59:46 -0400
From: Dirk Mittler <EDITED OUT>
To: Dirk Alt Addr <dirkmittler@gmail.com>
Subject: Test.
Message-Id: <20140617235946.f1768d4b643bcfa99b94ef70@sympatico.ca>
Organization: (none)
X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.10; i486-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
micalg="PGP-SHA1";
boundary="Signature=_Tue__17_Jun_2014_23_59_46_-0400_JHfkbTjzDCNnn.ps"
--Signature=_Tue__17_Jun_2014_23_59_46_-0400_JHfkbTjzDCNnn.ps
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
I just want to make sure, that I didn't break Sylpheed-compatibility, when =
I updated my GnuPG configuration.
--=20
by Dirk Mittler <EDITED OUT>
on an undisclosed computer
using Debian / Wheezy (a version of Linux)
with the LXDE Desktop Manager
--Signature=_Tue__17_Jun_2014_23_59_46_-0400_JHfkbTjzDCNnn.ps
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJToQ6zAAoJEPjfsAciaLEpI0MH/0PhA3dHcCOwHjwocf4WP6tN
qTxoChYvmbG5MWXIQbqSrkjuybAw69i4p82LBkcIaCOijJWpHZ83QL5QkKCta3LU
csS+Pl8M+VHFMNxiL3CYQAp+oonMsxJppy3K1NC0NKxxjLTePVfwCmgfRvcMSEWd
khbCjnkU4uFX9ciCrC4F4m7o9RGT6sKFlIFeaad+wCaGyiSmM7gOzpA4T28eKDio
QASOKnrhttagEWDwl2OrN1RnxkSTW+PVKiYTY/knEJgWW5atQIrUMkLrwnax9qnJ
aNbPYgYCB287ubs4RGpapg2kTR3ieGvKmbeD8BcXUvWJpV/xDJw5ufoD+GUPFIU=
=WFAw
-----END PGP SIGNATURE-----
--Signature=_Tue__17_Jun_2014_23_59_46_-0400_JHfkbTjzDCNnn.ps--
When I next open this email in Thunderbird, as I should, this is what I see:
But then within my GMail account, this is all I see, even though PGP/MIME is enabled within WebPG:
While I still had the release version installed on Chrome, it would try to display some kind of visual in red (meaning failure), and then I'd just get logged out. Now, do you see any obvious problem with how Sylpheed encodes email?
Now I suppose that there is one slight problem with the email in question: On my other (Linux) box, it used my GMail certificate when sending, even though the message was being sent from my other, main address. This was actually the type of problem, which this test email was supposed to reveal. But would that simple fact be enough, to trouble WebPG ?
Dirk
With that choice of words, 'that are not being parsed correctly (by WebPG)', you are asserting that WebPG makes some attempt to use its Linked GMail Identity, to parse inbound PGP/MIME data, and not just to generate it.
No. The GMAIL identity is not needed in order to parse an open email in GMAIL. The email is open in the browser, and the content loaded into the browser is available to extensions. The WebPG extension (or add-on in Firefox), simply detects that a message is open, and then requests the raw version of the email (the email without any GMAIL UI, and no parsing or formatting), checks if it is a multipart email or flat, then extracts the requisite PGP information (if any). The linked GMAIL identity is only used for sending PGP/MIME email using WebPG.
Now that I'm narrowing my use of WebPG to v0.9.4 for Firefox, what I find instead is that the extension makes no attempt to detect or validate - and therefore to parse the PGP/MIME part of the message at all. And what I'm inferring, is that this is also the true reason fw I'm no longer getting logged out of GMail. Yet, where there are PGP/Inline signatures, WebPG seems to indicate their validity fine now - again without logging me out. And so here is a sample of what I see when WebPG has Decrypted a PGP/Inline message, sent with Thunderbird and Enigmail
The email source you have included in your last comment parses fine for me with WebPG. There is something else going on, and I would guess it is related to the fact that you have two send buttons. (To troubleshoot that issue, I am going to need the output in the browser console of firefox, preferably sent to me via email)
As for not getting logged out with the current build of WebPG v0.9.4 --- the issue that was causing the logging out should be fixed. It had to do with malformed request URLs.
While I still had the release version installed on Chrome, it would try to display some kind of visual in red (meaning failure), and then I'd just get logged out. Now, do you see any obvious problem with how Sylpheed encodes email?
The version of WebPG in the chrome webstore is broken.
Now I suppose that there is one slight problem with the email in question: On my other (Linux) box, it used my GMail certificate when sending, even though the message was being sent from my other, main address. This was actually the type of problem, which this test email was supposed to reveal. But would that simple fact be enough, to trouble WebPG ?
I am sorry, perhaps I am just that tired, but I have no idea what you are trying to say in the above quote... Could you try to reword it?
Rewording:
On my alternate Linux box, I had set my GnuPG2 infrastructure to make my GMail PGP key-pair its default, because that is what WebPG uses ~ most often ~ . But what I really wanted, was for Sylpheed to use my other, main PGP key-pair to sign, because the email was in fact being sent from this other, main address of mine. Yet, I had forgotten to set the key-selection within Sylpheed to anything other than default. I can set the non-default key. But you're not really responsible for how I configure Sylpheed. If anything, WebPG should detect that the email address associated with the key ownership, does not match the From: field of the email, and WebPG might alert me to it in red if you like. This will be corrected soon.
But what I found more troubling, is that WebPG simply did not detect any PGP signature at all. Now, depending on the frame of reference, it might be possible to suspect that GMail has stripped the PGP information from the email in the meantime, which Sylpheed had sent it with.
But, because merely opening this email no longer logs me out, I am now able to click on the Show Original button within GMail. And what the screenshot below would seem to suggest, is that GMail has not made any attempt to delete this detail (even though it's not complete here):
On my alternate Linux box, I had set my GnuPG2 infrastructure to make my GMail PGP key-pair its default, because that is what WebPG uses ~ most often ~ . But what I really wanted, was for Sylpheed to use my other, main PGP key-pair to sign, because the email was in fact being sent from this other, main address of mine. Yet, I had forgotten to set the key-selection within Sylpheed to anything other than default. I can set the non-default key. But you're not really responsible for how I configure Sylpheed.
Okay, yes, now I understand.
If anything, WebPG should detect that the email address associated with the key ownership, does not match the From: field of the email, and WebPG might alert me to it in red if you like. This will be corrected soon.
How does the "From" address of a signed email factor into signature verification or trust? WebPG does not calculate signatures or verify trust. WebPG simply passes PGP data to GnuPG to be appropriately handled (i.e. signature verification, decryption, both), and displays the result. If a signature is indicated as "good" (green) in WebPG, that is because GnuPG has verified the signature against a key that is present, not expired and not revoked.
It would not even be feasible to create this kind of relationship of email addresses to matching UIDs, given that UIDs are not unique (anyone can use anyone else's email address as thier UID), and furthermore, an email address is not required when creating a UID (there are many UIDs that do not have an associated email address).
All forms of trust associate are delegated to the GnuPG backend, which could be configured in a number of ways (trust model used, trust assignment, etc).
WebPG does however indicate (with red), when it encounters signed data and it does not have the corresponding Public Key for verification.
Would you be able to send me the contents of the browser console log (CTRL+SHIFT+J) while in GMAIL (preferably, just after loading GMAIL, and then again after opening a compose window) via email?
I am happy to oblige, assuming that this is your correct email address... See the first two attached files...
This email address is the github email address that adds our dialog to the issue. I have edited the issue comment version of your last message to exclude the attachments, as it makes the dialog difficult to follow.
For items that I need sent to me via email, please use webpg-support@webpg.org
I'm sad to say, that I've given up on version 0.9.4 for the time being. What I've found is that even though version 0.9.4 would have been more powerful, the virtually complete lack of usability forced me to abandon it, in favor of version 0.9.3 . This means that while basic encryption and signing work now, I won't be able to benefit from PGP/MIME after all.
Dirk