gpg-preset-passphrase
I'm looking for some help explaining the behavior of gpg-preset-passphrase. First, the manpage states: Passphrases set with this utility don't expire unless the --forget option is used to explicitly clear them from the cache --- or gpg-agent is either restarted or reloaded (by sending a SIGHUP to it). It is But it looks like gpg-preset-passphrase cached passphrases are still subject to the --max-cache-ttl option in gpg-agent ... this behavior is hardly "Don't expire". Is there a way to change this behavior? Second, the manpage also states: --forget Flush the passphrase for the given cache ID from the cache. The implication (to me) is that if I cache a passphrase with gpg-preset-passphrase, then run gpg-preset-passphrase with the same key fingerprint and the --forget option, that gpg-agent will no longer cache that entry. When this didn't pan out, I thought maybe the forget command simply makes the cached passphrase obey the --default-cache-ttl option, but no dice. So, basically the --preset command is subject to --max-cache-ttl (although the documentation implies otherwise), and the --forget command doesn't appear to change anything at all. Am I doing it wrong? Any help is appreciated, -- Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re[2]: key question
Hi Paul On Saturday 6 March 2010 at 8:54:41 AM, you wrote: > Hello MFPA, > During this whole debate, you have assumed one thing in your argument > that I don't believe anyone has pointed out as being flawed. You have > assumed that the person (I will call him John Doe) would have decided > to create a UID that contained the personal information that he wants > to keep private. The default configurations of PGP and gpg ask for a name, email address, and comment when you create a key. Last time I looked (v8.x), PGP would not even create a key without something that looked like an email address - hence the a...@b.c in my UID. (And yes, I know gpg now allows you to omit the email address without having to use --expert, but you are still asked for it.) Almost any documentation I can find telling a new user how to use GnuPG or PGP tells the user that the key UID is their name plus email address, and that they should upload the key to a server. Many email apps rely on the presence of the email address in the UID for key selection, and documentation mentions this. Basically, almost everything the beginner sees suggests either he cannot create a key without this info, or his key is next-to-useless if he does. > If the person wanted badly to keep his e-mail address, or his e-mail > address and his name, private, why would he put them on his key. > Especially, when he knows that all it takes is one slip up or > deliberate upload to send his public key flying across the Internet > and into a keyserver to remain there forever. I agree, and I touched this in Message-ID: <205633239.20100226162...@my_localhost>, which was a reply to one of your previous messages. > Here are three examples of John Doe wanting to keep the privacy of his > personal information and still use PGP. I am using these examples, > because they are usage cases that you have used in your arguments. > The usage cases are as follows: (a) John Doe doesn't want to disclose > his e-mail address; (b) John Doe doesn't want to disclose his name > or e-mail address; (c) John Doe doesn't want to disclose his name or > e-mail address, because he fears that his government will send him > to a gulag if they catch him. [...] > -- > In each of these cases, John Doe made the mistake of thinking that > he could keep his personal information in his key, and that he could > keep his key off the keyservers. If John were to make the wisest > decision about keeping his personal informaton secret, wouldn't he > choose to not include this information in a key that is probable to > end up in a public venue? You are assuming he realised it was probable. The benefit of hindsight will presumably lead him to proceed differently in future. Initially, John may not have even known he *could* create a useable key without his valid email address. He might have been used to trusting his those in his closed circle. He might not have experienced or considered how easy it was to make mistakes resulting in inadvertent key upload. He may have read about the "keyserver-no-modify" flag and assumed the feature would actually protect his key from accidental or malicious publication. -- Best regards MFPAmailto:expires2...@ymail.com Don't learn safety rules by accident... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Re[2]: key question
On Mar 7, 2010, at 11:46 AM, MFPA wrote: > The default configurations of PGP and gpg ask for a name, email > address, and comment when you create a key. Last time I looked (v8.x), > PGP would not even create a key without something that looked like an > email address - hence the a...@b.c in my UID. (And yes, I know gpg now > allows you to omit the email address without having to use --expert, > but you are still asked for it.) There is no 'now' here. This is not new behavior in GPG, and the expert flag never had anything to do with it (indeed, the behavior predates the existence of the --expert flag). When GPG asks you for an email address, just hit return. GPG doesn't care one way or the other. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re[4]: key question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi David On Sunday 7 March 2010 at 5:53:51 PM, you wrote: > On Mar 7, 2010, at 11:46 AM, MFPA wrote: >> (And yes, I know gpg now >> allows you to omit the email address without having to use --expert, >> but you are still asked for it.) > There is no 'now' here. This is not new behavior in GPG, and the > expert flag never had anything to do with it (indeed, the behavior > predates the existence of the --expert flag). When GPG asks you for > an email address, just hit return. GPG doesn't care one way or the other. Sorry, I was mistaken. When I tested this in an earlier version, I was unable to proceed without entering an email address. Having gone back and re-tested, I am only able to replicate the behaviour if the string I enter for "Real name" contains the "@" character. This also holds true for 1.4.10. The --expert flag was/is not the difference, it's the presence of "@" in the "Real name" field. - -- Best regards MFPAmailto:expires2...@ymail.com Raining cats and dogs is better than hailing taxis. -BEGIN PGP SIGNATURE- iQCVAwUBS5RUBKipC46tDG5pAQoU1QP/ZLjFmEuJDekgAMUakhZdYPOvVEc/fOml JSJT/ABumMQnnrwMA8JM/r3uoqguXP2HNC4fx2cL5OwcPGbb1kC5JPXwFG79JHKC CTPM7aXVzOgavQ8L3fj1FKwM/6fOKXTFT/PLePYHIzbt4+HjxZk854bvTyhv3MY0 0qhoUy5yAaU= =ypXx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re[2]: key question
Hi Mark On Thursday 4 March 2010 at 5:25:09 PM, you wrote: > Were I the individual, I would think long and hard about using a tool > which would require me to defeat its features that create identity > labels (however false or information-poor) and carry them along with > the message. I would be drawn toward tools whose methods carry no > identity data themselves. You can't accidentally misuse a feature > that isn't there. Which is, of course, sound reasoning in the event that the range of options available to that individual (and his contacts) includes such tools. -- Best regards MFPAmailto:expires2...@ymail.com Two wrongs don't make a right. But three lefts do. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
how to suppress warning about gpg-agent?
Hi! Looks like we need an option to suppress warning about gpg-agent. > Long story: I've a lot of projects (each has separate user account) which use gpg for encrypting daily backups (from cron) in this way: gpg --batch --cipher-algo AES256 -c --passphrase-file PASSFILE BACKUP.tar The problem is, after switching to gpg2 I start receiving a lot of emails every day with same warning: "can't connect to `/home/USER/.gnupg/S.gpg-agent': No such file or directory" I don't like to redirect STDERR output of gpg to /dev/null because I wanna receive emails in case of problems with backup process. But I don't wanna receive dozens of useless emails with this warning every day. I don't like to run gpg-agent as a daemon on all these user accounts just to suppress this warning message (and there may be additional issues to make it accessible from cron scripts, too). I can try to run gpg-agent from same cron script just before using gpg, and then kill gpg-agent, but this may lead to race conditions in case gpg-agent already started by that user for other needs. Looks like there only two real solutions: implement pipe filter for gpg's STDERR to strip just this message (ugly), and patch gpg to add an option to suppress this warning. P.S. I use Gentoo Linux and app-crypt/gnupg-2.0.14. -- WBR, Alex. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re[2]: Memory forensics
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi John On Friday 5 March 2010 at 9:42:53 PM, you wrote: > Most 'Hibernators' I know are laptop/notebook/netbook Users who are too > important to wait for boot-up when the unit is Opened. :-D Did you mean "important" rather than "impatient?" - -- Best regards MFPAmailto:expires2...@ymail.com We are all in the gutter, but some of us are looking at the stars -BEGIN PGP SIGNATURE- iQCVAwUBS5RXeKipC46tDG5pAQoYDgQAj3BvmgZythkHXMXotKBT/rAHpLtVCbkJ czGqvSLH8z/SJVG6cxqy98d5oVTY3uym5+5FfsvZdFrw9NEYLRdBiJwbLTDDsJBz mfh0Yif87vjbfllIQzZpl+AjUEHer2BdC6PaxxynGlVEJXwBIhT5R+57ulJBUQRw iCTinN9y/vY= =twZz -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key question
MFPA wrote: > On Saturday 6 March 2010 at 8:55:48 AM, you wrote: > > >> On Sat, 27 Feb 2010 03:52:02 + MFPA wrote: (b) the person owns the information has the right to control how it is disseminated, and > > This was someone's re-interpretation of my point. Spot the extra ">"? Hello MFPA, I never asserted that you said the key's originator owned the information stored in the key. I was quoting the context of what your reply about the originator having "some rights" was about. I would never try to insert words into your mouth. >>> The data subject does have various rights concerning the personal >>> information that is about him. This is the reply you gave to Robert J. Hansen. I have asked about what you believe the limit of the "rights" of the originator is. I didn't ask this because I am trying to twist your words to make it seem as though you believe that the originator has a right by law to prevent the key holder from disseminating it. I used this quote, because I believe that it states, in your own words, what you have been saying, either directly or by implication, during this whole discussion thread. > The concept of *owning* your personal information makes little sense. [snipped the rest of the paragraph] You have began by answering a question that I never asked. I have only asserted that you believe that the originator has "some rights". I never used the word "own". I used the word "rights". > Exactly as far as everything else that would fall under the basic > right to privacy (described in Article 8 of the European Convention of > Human Rights as "the right to respect for private and family life"). > The OECD's "Guidelines on the Protection of Privacy and Transborder > Flows of Personal Data" is a slightly more international view. > http://www.oecd.org/document/20/0,3343,en_2649_34255_15589524_1_1_1_1,00.html > > The use, storage or dissemination of personal information is the > subject of specific laws in many places, as mentioned above and linked > from earlier in the thread. > > I'm referring to the personal information that is often present in key > UIDs. Others may wish to extend similar discussion to cover the key > ID/fingerprint, which I view as problematic. The key ID/fingerprint is > not personal information in and of itself. But if the key is on a > server, the de facto standard for key UIDs leads to, in most cases, > personal information being revealed to anybody in possession of the > key ID. Really, I am not interested in talking about what the law says. The law may be right, or the law may be wrong. I don't want to know what the law thinks, I want to know what you think. >> You say that the key's originator should control the dissemination >> of the key to the keyserver, > > (I would point out that other opinions are available and have been > shared in this thread. Also, the conditional "should" is important > since anybody in possession of the key has the *ability* to upload it > whether they "should" or not.) I know what the others have said--I have read every posting in this thread. As for "should", I intentionally chose that word. > I say that if the key's originator does not disseminate said key to > said keyserver, nobody else is in a legitimate position to make that > decision on their behalf. If the originator actively *wanted* their > key to be on that server (or network of servers), they would probably > have uploaded it there. > > The originator may have been unaware of that server's existence. They > may simply have taken no action regarding keyservers. They may have > considered a particular keyserver (or network) and made a decision > that they did not want their key on it. They may not want their key on > any keyserver. The point is, without referring to the key originator, > a third party cannot know their intentions and should not have the > arrogance to presume. > > The OpenPGP standard and GnuPG can both be seen to concede that the > key originator could have some say in the matter: the > "keyserver-no-modify" flag was defined quite a while ago in RFC 2440 > as meaning "the key holder requests that this key only be modified or > updated by the key holder or an administrator of the key server," and > has long been set by default in GnuPG. Unfortunately, I don't see > evidence that any keyservers honour this flag. For the record, I don't believe that the key holder should upload the key if the key's originator doesn't want the key in some public venue (forget the keyservers, it's about public availability). But I don't believe the originator has a /right/ to prevent the key holder from sharing it. >> but what about from the keyserver? Isn't the keyserver unwittingly >> sharing the key without the originator's permission? > > Difficult to answer. Good. I accomplished my goal of making you think about your position. :-) > Say, for example, I was to print out your photograph, name, address, > phone number, etc. and di
Re: key question
Hello MFPA, I will summarize the "rights" and restrictions that I believe you say that an OpenPGP user has with another's public key. I will call this the rules of "Key Rights Management" or KRM for short. Rights of the Key Originator * Can restrict the uploading of the key to a public venue, especially public keyservers. * Can restrict how and where a key is uploaded, if uploading is permitted. * Can restrict the sharing of the key with someone other than the originator. * Can control the Original Signature Content of the key. [1] Privileges of the Key Holder * Free to use the key when communicating with the originator. * May keep multiple copies of the key so long as the key holder takes steps to protect the key from unauthorized copying and distribution. * None more. You should be glad the originator was lenient enough to allow you to have the first two. [1] Original Signature Content is the signatures that are attached, at the will of the originator, to the key. By default no one may add signatures to this Original Signature Content without the owner's permission. -Paul -- PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key question
MFPA wrote: >> In each of these cases, John Doe made the mistake of thinking that >> he could keep his personal information in his key, and that he could >> keep his key off the keyservers. If John were to make the wisest >> decision about keeping his personal informaton secret, wouldn't he >> choose to not include this information in a key that is probable to >> end up in a public venue? > > > You are assuming he realised it was probable. The benefit of hindsight > will presumably lead him to proceed differently in future. Initially, > John may not have even known he *could* create a useable key without > his valid email address. He might have been used to trusting his those > in his closed circle. He might not have experienced or considered how > easy it was to make mistakes resulting in inadvertent key upload. He > may have read about the "keyserver-no-modify" flag and assumed the > feature would actually protect his key from accidental or malicious > publication. I am assuming that a person inhabited with the desire to protect his personal information would analyze the safety of using a UID with the information that he wants to protect. A person worried about the disclosure of his personal information is unlikely to say, "Huh. I guess I don't have an option concerning my privacy." I am also assuming that the user has intelligence and judgment. If the user is stupid and foolish, nothing can save him. By saying that he must have intelligence and judgment, I mean that he must be able to realize that he needs to be competent in the tool that he is using. How could a person of judgment believe that he could have the minimum knowledge of how to use cryptography and his OpenPGP tool, and believe that he will successfully protect his privacy? The person concerned with the releasing of his personal information might make the mistakes that you have said. But the kind of person that you are talking about has minimal knowledge in OpenPGP and the tools to implement it and has less than adequate reasoning. I have been naive before. But I didn't begin using GnuPGP while I was still naive about it. I studied how cryptography and OpenPGP worked, how to use gpg, and how to use it with e-mail and files. I won't claim that I am better or more knowledgeable than some of the other smart people on this mailing list, but I will say that I am smart enough to teach others how it works. Actually, it was my goal to understand the concepts and the tools well enough to teach others. You don't have to have the most understanding in order to teach others, but you do have to have /enough/ understanding in what you want to teach in order to teach others. Naivety in how to protect your privacy leads to having no privacy. Take for example how it is that many young people share the intimate details of their lives on social networks, chat rooms, et cetera. They are naive and *foolish*. While training these kids on how to protect their privacy could lead to many of them abandoning such unsafe practices, this doesn't mean that someone who already wants privacy would think that those same unsafe practices were safe. That is what I was saying in the previous posting. Someone who desires privacy will do what it takes to get it. That includes dispelling his naivety with knowledge. As for the person not realizing how easy it would be to accidentally upload a public key to a keyserver, I was never that naive. I was aware of it from the beginning. My key wasn't on the keyservers, initially (I chose to upload it later). But I knew that if I was careless it could wind up there. Maybe it is that I am an above average user. Maybe. Maybe it is just that I exercised judgment. Maybe I expect others to do the same. -Paul -- "You are free to rip me off. Just remember to credit me." --self PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
