Select signing key #77
Comments
|
gjedeer, Thanks for reporting this, it is something I figured would come up eventually... I recognize this is a problem, and this would occur in just about any use case within WebPG. (Out of curiosity, what is your current use case that you are having this issue? textarea signing, GMAIL integration or Thunderbird integration?) There are a couple of ways that I think this could be addressed, but I haven't decided on the best method. Nor have I thought of all of the ways available to go about this. Here is what I've been kicking around, maybe you or someone else has some insight - 1.) Prompt the user for the desired signing key if more than one Private key is enabled within WebPG; problems with this include: General annoyance for users who don't want to be bothered by selecting a key each time. 2.) Attempt to determine the proper (enabled) signing key based on the value of the sending address within GMAIL and Thunderbird, and fail-over to the default signing key if unable to determine; problems with this include: this is really only feasible for GMAIL and Thunderbird, as other mail clients are not supported at this time. It does not address the issue for other webmail interfaces. 3.) Create a method to manage rule-sets within WebPG to define specific keys for certain cases; problems with this include: Complicates usage and management as well as development, and could lead to undesired key selection if rules not maintained. Those are the ways I have thought of that could potentially address the issue, but I don't regard any of them as the best solution. I tend to lean towards solution 1, however, that is absent a better idea. Any ideas? |
|
Hi Kyle, My use case where it's a problem is gmail integration. I also use webpg for other stuff, but this is where I encountered this problem.
Instead, 1) could be extended a little bit: allow choosing identity but instead of prompting, use default identity. Sort of like this: http://f.gdr.name/webpg-sign-1.png The identity selected by default could be later guessed by "from: " address - sort of like 2)
|
* Added translations status to about page * Fixed some issues in Conkeror * Changes to key selection when signing/encrypting; work towards #76 and #77 * Fixed notification icon * Improved GMAIL parsing of PGP messages * Improved Thunderbird parsing of PGP messages * Added option to set the inline parsing display mode * Added more default inline parsing blacklist entries
|
What do you think about this?
|
|
I think it looks great. |
|
When will this feature be available? I've just installed webpg (0.9.3), and it's useless for me; short of deleting my keys, I can't get it to actually use the damn key I want it to; it insists on trying to use a similarly named key, despite me having disabled it. I have only one key 'enabled' and set to default, which it still refuses to use! How is that not a bug? Is it hard to give an option to always use a specific key? Maybe, like, have a setting called 'default' that's honored? And while you're at it, is it possible to to have an option to sign all email? And store the password to do so, hashed, for the session? I've got a key just for email. It's low security. This is needlessly convoluted. And, with the gmail integration 'experimental', just what is the point of the chrome plugin? |
|
I'm half tempted to tell you bugger-off, given what I perceive as a tone of complete dickery. But instead I will address your comments --
This feature is available in WebPG v0.9.4.
Who said it isn't a bug? After this was reported, the opening to my immediate response was "Thanks for reporting this, it is something I figured would come up eventually... I recognize this is a problem, and this would occur in just about any use case within WebPG."
The selection of "default" for a key does not have anything to do with WebPG -- that is a construct of GnuPG. Plain and simple. That feature in WebPG is to manage your GnuPG default key. I understand how that could be confusing, and that has been corrected in v0.9.4
It depends on what you mean. All OUTGOING email? Sure, the option "Automatically Sign outgoing messages in GMAIL" should do that, unless the user overrides the WebPG action.
WebPG does not deal with passphrases. All passphrase requests are handled by the key-agent. Private Key operations are invoked on the GnuPG context by WebPG, and the expectation is that your configured key-agent will collect the passphrase and unlock the secret keyring for the given operation (thus the requirement for a valid key-agent). If you want to cache the passphrase, you will have to alter the settings of your key-agent. Another option would be to remove the passphrase entirely.
If you say so -- I guess providing high grade encryption and decryption to multiple browsers on 3 very different operating systems is a trivial matter.
There is no such thing as a "chrome plugin" -- it is an "extension", I'm not just being pedantic, there is a very big difference between a plugin and an extension/addon, of which WebPG uses both. A plugin is a binary component, usually written in C/C++ that provides functionality not inherent to the browser. An extension (chrome) or addon (mozilla) is a component (typically written in Javascript) that extends the browser through features provided by the browser. In the context of your question it is of less importance, your meaning is obvious, but it wouldn't be fair to not point out how needlessly convoluted the question was. To answer your question - the gmail integration is a feature (an experimental one at that). WebPG has many users who don't even have a gmail account. WebPG is functional for GnuPG Key Management (creation, revocation, modification, export) as well as rendering otherwise useless (within the browser) PGP data on the web into something usable/interactive. The gmail integration was provided as an afterthought in an effort to make it easier for users to do what they were already doing. It is however - as I pointed out - in an experimental state, which implies there will most likely issues with it's operation. Furthermore, WebPG as a whole is BETA -- there are lots of moving parts and some of them don't yet function the way I intend; I won't apologize for that either. I am short on help, time and resources, yet I have an abundance of un-constructive criticism. I work a full-time job, I have a family, and this is not the only project I am involved in. If my completely free software is unusable to you, I promise I will provide you with a full refund of every cent I charged you for it. You can ask just about any user who has ever contacted me, I like to hear from users. I am very diligent in trying to quickly resolve any problems they bring to my attention. Often times it is an issue of ignorance on their part, not understanding basic GnuPG concepts like key signatures, etc. -- regardless of the matter brought to my attention, be it a legitimate issue or their own ignorance, I am very thorough, courteous and respectful. If you can't manage to provide the same courtesy to me, I'd ask that you kindly fuck off. |
|
Wow, that was rude from a person with an empty github history. But the good part is that you implemented it, @kylehuff. Is 0.9.4 available somewhere for a test? |
|
@gjedeer Yes, github user @Emil-V was kind enough to add the instructions for that to the wiki: https://github.com/kylehuff/webpg-chrome/wiki#install-development-build |
You'd be in your right; my tone was of complete dickery ---
My reading of this thread was that this was approached as a feature request.
This is the issue, and the reason for my dickishness. Please understand where I'm coming from, and my frustration. I have four active keys; I set one as the default, and as enabled, with all the others disabled. Not just disabled, but redded out, disabled, in the key manager. And, still, it used the wrong key. Finally, I deleted a key from my key ring (backed up, of course), thinking it might be because of the duplicate email address --- and it uses the next disabled one!
For some reason, this wasn't working; and suddenly is (no changes). When I send now, the dialog does come up.
Thank you for the education on this; I understand.
Point taken; however, and you may mock away here, but as a computer person, if I can't figure out why disabling everything but a single key won't work, what hope does the dabbler who finally gets motivated because of recent events have? To be fair, though, they'd likely only have one key, and everything would work just fine for them...
I appreciate the distinction; thank you for explaining it.
This is a problem with my perception; I misunderstood the entire point of the extension: I was approaching as something solely to use with gmail to enable signing and encrypting, not a general pgp app. So, just projecting what I needed it for. Obviously, wrongly.
This makes a lot more sense to me now. ;-)
Nor need you; it is I who owe you an apology.
Yes, you're right; my frustration doesn't excuse my tone, and I'm sorry for adding to it. Are there any low-skill (ie, tedious, but not requiring deep knowledge of javascript/c/encryption) items that someone like me could help with?
^laugh^ Realize there's time spent on my end as well; I spent over an hour trying to figure out how to make it 'just use my damn key already'. To be clear, the issue is with gpa not honoring my default settings?
And in this case, it's my ignorance not understanding the larger focus of WebPG and the integration.
Thank you for taking the time to give an informative, helpful response. My tone was completely out of line, and I apologize for it. I do appreciate your efforts, and realize that it 'not working as intended' was because I didn't understand how it was supposed to work. Please forgive me for my doucheness. |
Would it have been less rude of me if I had a full github history? |
Yes and no. The issue is a bug, however part of the solution is a new feature (the popout list of enabled keys) - understandable conclusion.
Absolutely it is wrong, and I spent a great deal of time to address the problem. It is of high importance to me, and I understand your frustration.
If you would have gone to the "Contact Us" page, there is an IRC widget [https://webpg.org/?view=webchat] -- I probably could have quickly explained some ways to accomplish this much quicker. Not really relevant, just saying.
Intermittent, unexplained events that result in the eventual desired behavior are the key to my success... It is designed to wait until you are frustrated, and then give you a feeling of accomplishment. This is not a bug, this is a feature! =c ) Seriously, if I had to guess, gmail was already open when you enabled that feature, and I believe in that version the setting was not always picked up until the tab with gmail was refreshed. Wild guess, but could have been the cause.
My Father (also a developer, hopefully much better than I am) used to tell stories about how his software was often used in ways he had not foreseen. I think this is an example of that. And this is also precisely why I love to hear from users -- the more I understand how users want to use the software the better I can drive changes so they can.
Well, you are already serving a very useful function at the moment - attempting to get the items you desire/require planned, developed and tested, and explaining your understanding of the functions that software provides. Other ways to contribute would be to test upcoming releases, responding to issue reports (you may know the answer, or perhaps the reporting party left out some vital information needed for diagnosis) or hanging out in #webpg on the freenode network to answer questions (IRC). It is really up to you. There are a few people who regularly fill some of those roles -- @darkpixel often tracks issues for initial triage or to request more information, and Sentynel hangs out in #webpg to assist users and also helps me test new features, and beppu in #webpg does testing on OSX, also as I mentioned earlier in the thread, @Emil-V has made contributions to the wiki.
I do realize that, and I wish I could avoid such scenarios -- but this issue for example, while severe on your platform, is relatively trivial on Linux and OSX. It depends a lot on the specific implementation of GnuPG installed. Unfortunately, I can't do enough testing to catch all of these scenarios that take users time away.
Honestly, I don't remember what the root cause was. I believe it was a multi-part issue - partly due to the way that LIBGPGME (the interface library to GnuPG) handles key selection, and partly due to the WebPG key selection logic.
No problem, I want users to be involved; if nothing more than just for the knowledge they gain about GnuPG and privacy; the latter being so important, it is in the damn U.S. Constitution! (even if the feds pretend not to know that)
Forgiven. Have you tried v0.9.4 yet? I'd be curious to know if the (alleged) fixes solve the issue with your specific setup. |
Thank you -- though, it doesn't excuse my rudeness. Your response was far more measured than my whining merited. Which is why you're a developer and I'm a guy with an empty github. ;-)
You're gunning for a job at Microsoft, aren't you? ^duck^ :^P
I reloaded it multiple times; it's pretty weird, because it's actually doing what I want, with automatically being engaged for each message. Always the funnest bugs. ;-) On a quick tangent, it also seems that my password is saved (by the key agent) if I have messages very quick to each other... so, I need to see just what gpa (?) has for settings.
This is interesting; the only reason I looked at webpg is because it seemed like the only actual solution for chrome that tied into 'actual software' (gnupg) to do 'real signing and encryption' (vs the other 2 'extensions' that seem to want to reinvent the wheel in javascript; not sure I trust that, as much as I trust just calling a more mature library). So, I thought webpg's sole purpose was webmail integration. I know, now, it's not. I'd really push/pester/cajole/and otherwise prompt you to consider focusing more on the webmail aspect, because from much irritating searching, there really isn't anything out there. There are, of course, plenty of easily usable plugins for 'real' email clients, and specialized clients, but, for all the people using Hotmail, Gmail, Yahoo (they exist; I've met them!), etc, it's really, really hard to find something to make somewhat more secure email, easy. I just posted a few links in the wiki to point at what I mean. The relevance of this is, wegpg seems perfectly set up to be THE thing to use; at least, for gmail. ;-)
And learning how to do so politely... ;^)
Cool suggestions; I'd like to be more useful, than 'jerk'... I'm really ashamed of being such an ass. I'm actually somewhat new to github; I only registered to submit bugs to another project; I didn't even realize until your response that not only is there a wiki, but I could add to it. That's really, really neat. (Of course, it'd be way cooler if I had something worth adding. ;^) )
This seems like the sort of thing that can be eventually documented. And, head still hanging sheepishly, but I didn't even test on any of my 'nix systems... my Windows box tends to get the 'it could break things' playing around, first.
I'm gonna create a feature request topic. ;^)
What I was wanting, and what seems very possible for WebPG to do, is an easy way of having a bit more security with gmail --- at the very least, signing messages. I don't tend to be very paranoid with my 'fluff' email, or, even, organization email. However, there are plenty of reasons to validate messages (imho) and, of course, I'd quite like to stop having some threads in the clear on gmail.
Not yet; I have the wiki instructions up, and it looks very simple; I'm going to reload my keys, install the update, and see. I thought it was in this thread, but I don't see it now; somewhere you said it was a real hassle to get the extension update pushed out; is that some breakage on Chrome/Firefox's end, for the respective plugins, or something that could be worked with, with some research. (Ie, mine. ;-) ) As in, is there a technical reason it's not easy to use Chrome's extension page to pull an update, or is it a 'the documentation's naff, and I haven't wanted to wade through it, when it's so easy to just manually do it, for people testing' issue? :-) |
|
I was going to create a new topic, but this actually seems to belong here!
Those. Those are what I want. I want to be able to set up a 'default' scenario (perhaps, don't sign at all), but on every message I reply to, have a webpg button (this is me completely talking out my butt; I once looked at Chrome extensions, and thought, "That looks like a lot of work' and never looked again; if this isn't possible, then, obviously, whatever is...) that brings up a dialog, that allows me to specify settings particular to that sender, with the option of applying it to the whole domain. It's exceedingly important for me, that I don't ever use certain keys to sign emails to certain people, so, there should be a warning if, for some reason, it appears I have: sending a message to [email protected] signed with my credentials of [email protected]. How much storage does the Chrome extension give? How hard would it be to have:
When a message is being composed, WebPG could first check if we have the key of the person who sent us a message; if so, automatically set up to encrypt that message with their key (Settings option, "GMAIL: Always encrypt message if sender's key exists."), if we don't have a key for the person, when composing the message, next check if their exact address is in our whitelist; if it is, see what default we wanted. If the specific address isn't there, see if their domain is in our domain list; if so, do what default we specified, otherwise, fall through to our global default action (whether we sign every email, and if so, with what key). And if you've already done all this in .9.4, I'm really going to find a tool shed to hang out in, and be with the other tools. ;^p I've definitely like to voice a vote against '1)', because when you're responding to enough email, being prompted at each one will get way, way annoying. Assuming the ability to cache passwords on the backend for the session, everything should work without any dialogs coming up. Of course, this is convenience vs paranoia; a possible future feature request could have a first time wizard when installing the Chrome extension, where someone can decide, "I just want people to know my email hasn't been modified by someone else", or "I don't want my email saved in plaintext on Google's machine" (Warning: Selecting this option means everyone you communicate with must send you their openpgp keys, and you must send them yours!) or "I'm really paranoid; enable signing and encryption for all messages: I've already exchanged keys with everyone I know!" |
Well, no, the issue is, Mozilla picks through the code with a fine-tooth comb. It probably sounds like a diligent practice to keep users safe, and in certain respects, it is, however, the reality of it is that they require me to make ALL html passed to the browser "safe" by way of escaping (removing the possibility of malicious code being ran) -- even the html that is not coming from an external source that does it have the possibility to contain any javascript code. It is an arduous process that is very time consuming, and quite frankly, it makes the code even more hard to follow. Due to this, I'm just not in a rush to push out out new code for them to nit-pick. IMO they need to fix the root issues -- chrome doesn't have that requirement, nor will it. Their extensions are sandboxed and the content security policy does rigorous enforcement in terms of the origin of scripts. It makes me feel that they are passing their security flaws down to the developers which just stifles development. Moreover, it doesn't help users who install add-ons from other, non-mozilla sources who don't have these arcane policies. Aside from that, the process gets bogged down because they insist on me sending them the source code to the compiled binaries every time I make an update -- and every time the link is already in the description. I highly doubt they are actually reviewing the thousands of lines of C/C++ code for those. Overall, I hate false security. Outside of that, the build process is fairly automated. A few commands on the keyboard and I can have a package to send out to the addon galleries. That isn't really an issue. The only issue there is that if I need the extension/addon to contain a newer version of the binary plugin, I need to compile that plugin on very certain machines. I can't compile the linux one on a machine that a version of linux too recent, or it won't work on older version. Granted, the linux example is a bad one because I have chroots with everything I need, but the process continues onto windows, where I need visual studio installed, and on OSX where I need XCode... it is just a less than pleasurable ordeal overall. In regards to your other comments -- I would give 0.9.4 a try. I think a lot of what you want is already address (in a lesser capacity) by the key selection popout. Your default key is what is used, unless you choose something different. I could make the extension store thousands of rules for what email address to use which key for signing. Storing such information is no big deal -- the issue will be the user managing those rules. WebPG is supposed to make things easier, not harder. That is not to say it shouldn't be done, just that, I'm not convinced it is justified. But even if it ends up being justifiable, it probably won't happen until after v1.0 -- there are just too many other things to get resolved before adding that much complexity to the environment. Besides, I think there are better ways to do than rules. One way of doing it would be for the user to just sign the public key of the user with the specific private key you want to use with. This signature could contains some special notation - something predictable. Then, when you attempt to send an email, it would be easy to identify which key should be used for the crypto operation. Another way would be for WebPG to understand that your default key is your default email-address, if you send out an email with a different "FROM" email address, use the key associated with it. |
|
A popout box is a better idea. I don't want my signing key to be tied to my FROM address. I want to pick and choose. |
Well I say let Mozilla suffer slow release cycles while rewarding Chrome with more release cycles! The versions do not have to match. Maybe Mozilla gets all the X.0.0 releases and Chrome gets all the X.X.X releases. |
I only use Firefox when it's that, or IE. Chrome's still my first choice; it sounds like their extension policy is much better, to boot. I think I asked my question wrongly; I was more asking, "How hard is it to make it so Chrome's extension is updated as you update, even if it's not a full on release?" <---. That. ;^) I just installed version .9.4 via the wiki instructions, and it was an absolute breeze. The only problem is --- how do I know when newer stuff is available? It'd be nice if it were easy on your end, so on my end, I could just refresh, and have the cutting edge latest. Is that hard to do?
Really sounds like a mess!
ROT-13 encryption's protected many [redacted] users for years! grin No, I totally hear you.
That really is spiffy. I like the pop out, how you have it...
It likely wouldn't need that many...
I think the failure is on my end for not articulating; I wouldn't suggest making a user manage those rules; rather (assuming it's possible, in gmail, in Chrome (screw Firefox! lol )) for a given email, just give an option on the compose, via the same pop up that already lets you select Encrypt / Sign Only / etc. The user can then do it on an email by email basis. In the settings dialog, there can be settings like GMAIL: Enable WebPG Psychic Engine (You put that there, and I'm so creating the wiki for it!) that can try to guess the right thing to do: if "Sign Messages Automatically" is enabled, and you note the person that's being sent to, and if for three times the user selected "Do not use WebPG for this message", then, the fourth time, disable automatic signing (this is only if the psychic engine's enabled; the user's told you they want you to anticipate their needs with Magic(tm)!) Additionally, and more usefully, with the Engine engaged, it can automatically encrypt if you've got the key of the person you're sending to. If there's a pattern of never encrypting to anyone at @example.com, and you see a new address there, by default, don't encrypt. So on. Is that even possible to do, something like that? Because it'd be very uber.
C'mon, I'm asking for a psychic engine, not an improbability drive! :^)
I'm not sure I understand the special notation part above; what I was saying above about a checkbox, and this, are the same thing, though. :^) Just a way of saying, "For this person, I want THIS!". In this case, if you don't sign the key, or don't have a key, then do nothing(?). And if you do have their key, and haven't signed it, also do nothing(?) You know, I think maybe I'm making it far too complicated, because just doing it this way removes a lot of unnecessary gyrations and also makes the key management simpler: I have my keys A, B, C, and D. I always use A for Joe and Sue, and B for Jack and Bob. If I sign Joe and Sue's keys with A, and Jack and Bob's with B, then I won't have to worry about selecting A or B when I email them... no 'default key' needed, because I get to use what I'd of selected, anyway. (And, my key won't change, for any person.) This handles domain specific stuff; I can keep my official separate from personal, just by signing all people's public keys in the organization with A, and private with B. Of course, it'd still be nice if WebPG could automatically suss that, "Oh, you're sending to someone at othertwits.org! You must want to use your [email protected] key to sign, yes?" <--
Or both? :^) How hard is this, for you, on your end? Meaning --- can you easily see if a key's signed? That is, I'm emailing [email protected] --- how hard is it for you to have it so you can see I signed [email protected]'s public key with my [email protected], and have that selected? Likewise, how hard is it to see that instead of using From: [email protected], I'm sending from [email protected], and automatically select the key? What do you do in the case when I have two keys with the same exact email? (The initial problem I had, in fact... ) Is it possible to do both these things? Have the signing the preferred way, and if there isn't a key for the person, fall back on using my address? Because I think that covers most usage cases. I think you could ignore my convoluted crap, because really, there's no need for a database of stuff, is there? Sign the person's public key, and it'll use the key you signed with to encrypt. Messages are signed with whatever key matches the from address (still need to deal with dupes). Just need some way of saying 'I know I want to automatically sign all messages, but, don't do any to this person, because SHA HASH in an email confuses them and they ask me why their mail is messed up." and "I know I want to automatically sign all messages, but never do it to any emails I send to people @soccermoms.r.us"... would be perfect! And one last thing (^duck^): Is there any way of a visual indicator, in the compose window? It could be as simple as highlighting something a certain color (like the button already is, with the grey lock/red 'don't encrypt') or some other symbol, that visually, instantly, shows what action will be taken. (Something to convey, "We have a key for this person, and you signed it, so this message will automatically encrypted to them.") (What, colors can say a lot! :^P ) Or are these ideas stupid and overkill, and it's probably good enough that it all works well enough now, with the ability for key selection? :^) |
I am working on making the development releases have an update feature. It is possible to point extensions to particular update services, where I can push out the most recent dev version. This, like many other pending items is on my TODO list.
Good, I tried to make it versatile enough to handle most use-cases. I can't take credit for it though; @gjedeer suggested the feature. It is his brainchild.
I was merely illustrating that storage was not an issue.
Signatures can contain special "notation", which could be use to do something pragmatically.
Well, yes and no. The difference is, a signature is an attribute on a key, which denotes another key. This means that the information is not stored within WebPG, and is portable between devices/installations. Lets say that you use WebPG at work, and at home, and you have synchronized your preferences (not implemented yet), you don't have to worry about the "rules" defined in one vs. the other, because it simply consults your keyring.
This is fairly simple. When WebPG builds the keylist object from your keyring, it collects all the available information about signatures -- trust signatures, local signatures (non-exportable), revocations, etc. and even keeps track of validity and trust. Nothing we've talked about so far is too terribly complicated.
Well, this is hard to overcome. Having two keys with the same UID is problematic. WebPG treats UIDs as unique, which follows the operation of GnuPG - (attempting to select a key that has a UID that is not unique results in an ambiguity error). If UIDs are for selecting the key they are associated with, what sense does it make to have one UID represent multiple keys?
Yes, it is possible, and in time this may get implemented.
Well, I say no. I am trying to avoid that scenario. I don't want to introduce any unnecessary convolution.
Well, there is... In the bottom right-hand corner of the compose windows text-entry area there is an icon affixed to the background which should indicate the selected action (see screenshot below). I don't see why that couldn't be integrated into any new features.
Not at all. This whole project started out as a stupid idea. You are right, it does work "well enough", but I want it to work great. And in time, it will. |
Cool. ;^)
Ah, okay.
That would be handy...
That's a plus, then. ;^)
Am I doing things wrong, then? I have a key I use 'for real' --- with a password hard enough to brute that the universe's heat death should happen once or twice before it's been done. But, I created a lesser key, just for email, to be able to sign with, and have the general unimportant stuff encrypted (for people to just use my email key...). Obviously, the latter, I use a much weaker password, which is also much easier to type. Of course, both keys have my same email address. Perhaps the solution, if there's no easy way to distinguish them, with gmail, at least, is to create an email only one with their dot notation. ^musing out loud^
Heh.
Just to be clear, I was using database generically to mean, 'some place to store a list of addresses that get treated specially/differently', but, yeah... less complexity, better. :^)
Right! That's already perfect; it just needs an icon that means, "We're not doing anything with this email, because we don't know what to do' (No public key, and addressed to an email with no signing key attached) and "We're not doing anything with this email, because you don't want to do anything when you send email to this address". That icon is exactly the sort of thing I'm talking about.
I have no doubt. ;^) |
I'm using two different identities (private keys) for two email accounts. There doesn't seem to be a way for me to choose which one I want to use when signing an email, other than changing default identity system-wide every time.
I tried disabling the default key so I can use the non-default one but it still signed with the default one.
The text was updated successfully, but these errors were encountered: