headers
Patrick Brunschwig | 2 Dec 16:15

Re: GnuPG-Agent on FreeBSD.


Janky Jay, III wrote:
> Hello, everyone.
> 
> 	I've been browsing all day and can't seem to figure out exactly what is
> wrong so maybe someone on this list will be able to help. Sorry if this
> has already been asked/covered/answered.
> 
> 	I'm running Thunderbird 2.0.0.9 (20071123) with Enigmail 0.95.5
> (20071124) on FreeBSD 6.2-RELEASE.
> 
> 	After the most recent updates of Enigmail, I was no longer able to send
> signed/encrypted email due to the new feature of Enigmail requiring the
> gpg-agent be running. This is all fine and good (After I've figured out
> how to start gpg-agent without having Enigmail start it for me and
> such...). However, when I attempt to send signed/encrypted emails now
> that gpg-agent is running, I get the following error(s) in the error dialog:
> 
> 	Send operation aborted.
> 
> 	Error - bad passphrase
> 
> 	gpg command line and output:
> 	/usr/local/bin/gpg --charset utf8 --batch --no-tty --status-fd 2 -t
> --clearsign -u <key-stuffs> --use-agent
> 	Warning: using insecure memory!
> 	gpg: problem with the agent: IPC write error
> 	gpg: Invalid passphrase; please try again ...
> 	gpg: problem with the agent: IPC write error
> 	gpg: skipped "<key-stuffs>": General error
(Continue reading)

Permalink | Reply | 5 comments |
headers
Janky Jay, III | 2 Dec 21:09
Picon

Re: GnuPG-Agent on FreeBSD.

Hello, Patrick.

	Thanks for the reply.

Patrick Brunschwig wrote:
> Janky Jay, III wrote:
>> Hello, everyone.
> 
>> 	I've been browsing all day and can't seem to figure out exactly what is
>> wrong so maybe someone on this list will be able to help. Sorry if this
>> has already been asked/covered/answered.
> 
>> 	I'm running Thunderbird 2.0.0.9 (20071123) with Enigmail 0.95.5
>> (20071124) on FreeBSD 6.2-RELEASE.
> 
>> 	After the most recent updates of Enigmail, I was no longer able to send
>> signed/encrypted email due to the new feature of Enigmail requiring the
>> gpg-agent be running. This is all fine and good (After I've figured out
>> how to start gpg-agent without having Enigmail start it for me and
>> such...). However, when I attempt to send signed/encrypted emails now
>> that gpg-agent is running, I get the following error(s) in the error dialog:
> 
>> 	Send operation aborted.
> 
>> 	Error - bad passphrase
> 
>> 	gpg command line and output:
>> 	/usr/local/bin/gpg --charset utf8 --batch --no-tty --status-fd 2 -t
>> --clearsign -u <key-stuffs> --use-agent
>> 	Warning: using insecure memory!
(Continue reading)

Permalink | Reply | 4 comments |
headers
Patrick Brunschwig | 3 Dec 09:33

Re: GnuPG-Agent on FreeBSD.


Janky Jay, III wrote:
> Hello, Patrick.
> 
> 	Thanks for the reply.
> 
> Patrick Brunschwig wrote:
>> Janky Jay, III wrote:
>>> Hello, everyone.
>>> 	I've been browsing all day and can't seem to figure out exactly what is
>>> wrong so maybe someone on this list will be able to help. Sorry if this
>>> has already been asked/covered/answered.
>>> 	I'm running Thunderbird 2.0.0.9 (20071123) with Enigmail 0.95.5
>>> (20071124) on FreeBSD 6.2-RELEASE.
>>> 	After the most recent updates of Enigmail, I was no longer able to send
>>> signed/encrypted email due to the new feature of Enigmail requiring the
>>> gpg-agent be running. This is all fine and good (After I've figured out
>>> how to start gpg-agent without having Enigmail start it for me and
>>> such...). However, when I attempt to send signed/encrypted emails now
>>> that gpg-agent is running, I get the following error(s) in the error dialog:
>>> 	Send operation aborted.
>>> 	Error - bad passphrase
>>> 	gpg command line and output:
>>> 	/usr/local/bin/gpg --charset utf8 --batch --no-tty --status-fd 2 -t
>>> --clearsign -u <key-stuffs> --use-agent
>>> 	Warning: using insecure memory!
>>> 	gpg: problem with the agent: IPC write error
>>> 	gpg: Invalid passphrase; please try again ...
>>> 	gpg: problem with the agent: IPC write error
>>> 	gpg: skipped "<key-stuffs>": General error
(Continue reading)

Permalink | Reply | 1 comment |
headers
Janky Jay, III | 3 Dec 10:11
Picon

Re: GnuPG-Agent on FreeBSD.

Patrick Brunschwig wrote:
> Janky Jay, III wrote:
>> Hello, Patrick.
> 
>> 	Thanks for the reply.
> 
>> Patrick Brunschwig wrote:
>>> Janky Jay, III wrote:
>>>> Hello, everyone.
>>>> 	I've been browsing all day and can't seem to figure out exactly what is
>>>> wrong so maybe someone on this list will be able to help. Sorry if this
>>>> has already been asked/covered/answered.
>>>> 	I'm running Thunderbird 2.0.0.9 (20071123) with Enigmail 0.95.5
>>>> (20071124) on FreeBSD 6.2-RELEASE.
>>>> 	After the most recent updates of Enigmail, I was no longer able to send
>>>> signed/encrypted email due to the new feature of Enigmail requiring the
>>>> gpg-agent be running. This is all fine and good (After I've figured out
>>>> how to start gpg-agent without having Enigmail start it for me and
>>>> such...). However, when I attempt to send signed/encrypted emails now
>>>> that gpg-agent is running, I get the following error(s) in the error dialog:
>>>> 	Send operation aborted.
>>>> 	Error - bad passphrase
>>>> 	gpg command line and output:
>>>> 	/usr/local/bin/gpg --charset utf8 --batch --no-tty --status-fd 2 -t
>>>> --clearsign -u <key-stuffs> --use-agent
>>>> 	Warning: using insecure memory!
>>>> 	gpg: problem with the agent: IPC write error
>>>> 	gpg: Invalid passphrase; please try again ...
>>>> 	gpg: problem with the agent: IPC write error
>>>> 	gpg: skipped "<key-stuffs>": General error
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Clizbe | 3 Dec 10:41
X-Face

Re: GnuPG-Agent on FreeBSD.

Janky Jay, III wrote:
> 	Thanks for the link. Unfortunately, I have already read that and tried
> both of the solutions recommended. I am using GnuPG v2 at the moment due
> to the FreeBSD port using GnuPG v2 as a dependency. I can, however,
> install GnuGP v1 and re-install Enigmail to use v1 instead, I was just
> hoping to stick with 2 as I'm sure it will become (if it already hasn't)
> the standard.
> 

Your needs will continue to be fully met by GnuPG 1.4.x.

Don't invest too much hope in gpg2 becoming a new "standard." GnuPG 2 is nothing
more than a re-implementation of GnuPG 1.4. Some would say that it shows signs
of the "Second System Effect."

Both GnuPG 1.4 and GnuPG 2 are to stay fully compliant with the OpenPGP
standard, RFC 4880. In fact, the newly proposed Camellia cipher extension has
been in 1.4.8 SVN for quite some time. I don't recall seeing it in libgcrypt yet.

The cryptographic features found in GnuPG2 but not in 1.4 are likely never to be
in 1.4 as they are from X.509 and not part of RFC 4880, nor is it likely they
will ever be. Some of the added functionality such as gpg-agent in Windows
doesn't apply to *BSD.

Don't be fooled by the change in version number. GnuPG 1.4 isn't going anywhere.

I think it would've been clearer had GnuPG 2 just been given a different name.

--

-- 
John P. Clizbe                      Inet:   John (a) Mozilla-Enigmail.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Janky Jay, III | 3 Dec 10:51
Picon

Re: GnuPG-Agent on FreeBSD.


John Clizbe wrote:
> Janky Jay, III wrote:
>> 	Thanks for the link. Unfortunately, I have already read that and tried
>> both of the solutions recommended. I am using GnuPG v2 at the moment due
>> to the FreeBSD port using GnuPG v2 as a dependency. I can, however,
>> install GnuGP v1 and re-install Enigmail to use v1 instead, I was just
>> hoping to stick with 2 as I'm sure it will become (if it already hasn't)
>> the standard.
>>
> 
> Your needs will continue to be fully met by GnuPG 1.4.x.
> 
> Don't invest too much hope in gpg2 becoming a new "standard." GnuPG 2 is nothing
> more than a re-implementation of GnuPG 1.4. Some would say that it shows signs
> of the "Second System Effect."
> 
> Both GnuPG 1.4 and GnuPG 2 are to stay fully compliant with the OpenPGP
> standard, RFC 4880. In fact, the newly proposed Camellia cipher extension has
> been in 1.4.8 SVN for quite some time. I don't recall seeing it in libgcrypt yet.
> 
> The cryptographic features found in GnuPG2 but not in 1.4 are likely never to be
> in 1.4 as they are from X.509 and not part of RFC 4880, nor is it likely they
> will ever be. Some of the added functionality such as gpg-agent in Windows
> doesn't apply to *BSD.
> 
> Don't be fooled by the change in version number. GnuPG 1.4 isn't going anywhere.
> 
> I think it would've been clearer had GnuPG 2 just been given a different name.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert J. Hansen | 11 Dec 12:20
Favicon
Gravatar

Usability issues


The ideas here will probably be at least somewhat controversial.  Please
think them over long and hard before you say "... but that's stupid!"  I
agree that many of these ideas will appear stupid at first blush, but I
think that some of them may actually be stupid-smart as opposed to
stupid-stupid.

I am recommending these ideas to the developers, but any changes like
these should only be made with a lot of community input.  So--give your
input.  :)

0.  KEYS AREN'T.

The idea of a 'key' is pretty poorly defined.  In the original days of
PGP 2.6 we used a single keypair for all operations.  This hasn't been
the case for many years, though.  Instead, we use collections of
keypairs to do all our operations.  This means that instead of 'key' we
should probably be talking about 'certificate'.  GnuPG is beginning to
make this terminological shift.  For the rest of this, I'm going to use
'certificate' to refer to key collections that are associated with one
person.

1.  BAD SIGNATURES AREN'T.

For a signature to have any meaning, it must be:

	* A good signature
	* From a validated certificate

In no other case does a signature have any meaning.  Let's say that I
(Continue reading)

Permalink | Reply | 14 comments |
headers
James Kosin | 11 Dec 15:36

Re: Usability issues


<<SNIP>>
> 1.  BAD SIGNATURES AREN'T.
>
> For a signature to have any meaning, it must be:
>
> * A good signature * From a validated certificate
>
> In no other case does a signature have any meaning.  Let's say that
> I receive a bad signature from John Clizbe.  I trust John and have
> given his certificate a nonexportable validation.  That bad
> signature means the message was changed /syntactically/.  It has
> nothing to say about whether the message was changed
> /semantically/.  Compare these two messages:
>
> a.  Now is the time for all good men to come to the aid of the
> party. b.  Now  is the time for all good men to come to the aid of
> the party.
>
<<SNIP>>

A BAD SIGNATURE only means the email was changed/modified in the two
sentences above the extra space modified the original text.  Plain and
simple.
You could also rearrange the sentence entirely and still convey the
same thought; but, that would still mean the text was modified.

c.  All good men, now is the time to come to the aid of the party.

Still conveys the same thought however I would still want this to fail
(Continue reading)

Permalink | Reply | 1 comment |
headers
LeRoy Cressy | 11 Dec 16:04

Re: Usability issues


Robert J. Hansen wrote:
> The ideas here will probably be at least somewhat controversial.  Please
> think them over long and hard before you say "... but that's stupid!"  I
> agree that many of these ideas will appear stupid at first blush, but I
> think that some of them may actually be stupid-smart as opposed to
> stupid-stupid.
> 
> I am recommending these ideas to the developers, but any changes like
> these should only be made with a lot of community input.  So--give your
> input.  :)
> 
> 
> 
> 
> 0.  KEYS AREN'T.
> 
> The idea of a 'key' is pretty poorly defined.  In the original days of
> PGP 2.6 we used a single keypair for all operations.  This hasn't been
> the case for many years, though.  Instead, we use collections of
> keypairs to do all our operations.  This means that instead of 'key' we
> should probably be talking about 'certificate'.  GnuPG is beginning to
> make this terminological shift.  For the rest of this, I'm going to use
> 'certificate' to refer to key collections that are associated with one
> person.
> 
> 
> 
> 1.  BAD SIGNATURES AREN'T.
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Patrick Brunschwig | 11 Dec 17:09

Re: Usability issues


LeRoy Cressy wrote:
[...]
> 
>> Consequences: what I consider to be the worst attack against
>> OpenPGP--the credibility attack--becomes less of a problem.  Let's say
>> that someone wants to ruin Patrick's credibility.  They create a few
>> bogus certificates, associate them with reprehensible groups, and use
>> them to sign Patrick's key.
> 
>> Now consider what happens if we have a policy of "by default, only show
>> meaningful keys".  Since I would presumably not have certified this
>> (fake, slanderous) neo-Nazi key, the user would never see it.  Only
>> those people whom I trust who have signed Patrick's key would show up.
> 
> 
> Only the owner of a key pair should send a key to a key server.
> you could set up a cron job with a line like
>   gpg --send-key 0x12345678
> to make sure that only your version of your public key is on a key server.
> 
> Also, you should not accept a signature for your key unless you have
> verified the signature like from a key signing party

I agree with both of what you write, but that doesn't solve the problem,
since you can't forbid people allowed to upload a key. I have got almost
all signatures from people I met personally -- but still you won't have
most of the certificates that signed my key ...

I think Robert's proposal (at least this one about hiding unknown
(Continue reading)

Permalink | Reply | 0 comments |

Gmane