Re: Defaults

2015-03-21 Thread MFPA 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Thursday 19 March 2015 at 10:19:45 AM, in
, Tobias Mueller wrote:


> I thought short keyids are dangerous and should not be
> used, cf. .  If that's the case
> then it might be a good idea to fade them out as much
> as possible.

You mean make "LONG" (or "0xLONG") the default for --keyid-format?




- --
Best regards

MFPA  

Ballerinas are always on their toes.  We need taller ballerinas!
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVDVq8XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwJeYH/j+jqnC4CNiGsYGlrpgFg051
8dFjli0bBLMPWW124OVSAc0DMherV7BLIInt1ZOdB6Lk1OARCYY0iIwpbHxblJRu
MmogvoJe+dL0X6WmPowWb/aOQxwqKINV5remM0etG37jmw30HPn2HoawuUeiM3QC
k0Nlfs1v0nW4TbwB44Tu4muCyYbrFRH8pofq3gRfipqUm45S7jnUHqSZsclu/AGO
bxtW8IHj6RtiuvmFEnP/T0wDfoYLflnjS6twbGQYFaKoxsXeL4lNHtI+29ymcSHU
QjvwKIwUEVyo8A6R/w+Qs9eslH1JUvn8CHmraXRWTzonI+n/Z4WKmHWv7w87X1WI
vgQBFgoAZgUCVQ1az18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45A8yAQC1XJFsMpUfa66BKCohk+SGDCbC
KK/FVcEAUlp4IlLIqAEAlCK5O8mjqQgud5QeBCaYyNOauUfY6BsEx1pkfpBVago=
=6j/y
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Defaults

2015-03-21 Thread MFPA 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Wednesday 18 March 2015 at 12:34:42 AM, in
, Robert J. Hansen wrote:



> Yes.  My list was comprehensive ("what the new set
> should be"), not differential ("what needs changing").
> :)

Whilst I realise you were specifically concentrating on defaults for
new key generation, perhaps a fully comprehensive discussion of GnuPG
defaults would be useful. This could be partly informed by people
looking through their GnuPG.conf files at the options they have chosen
to to change.



- --
Best regards

MFPA  

Dreams come true on this side of the Rainbow too!
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJVDV68XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwWQAIALFBt81MgvpogSqA25mY5dln
kV1UMM8USHlcuc3wIZ89uv7fP5m5sD8vTfuftSI/eMNsDWx7GPhklfbnGxEcfxzv
n98LfKg7a7/JT2lzYycXpCK0A8skGIpwVThL/utKj6XUsgSBiZm+XQayAhLipgog
VwoOf1wdvxmBkTY4gpQeqBVbmXv7Jt/nstelUcgYSxIkmDgDZSLfTEYAuvjVfHWz
Aopub2CsfaRCkLoNkOg/L53QvAJGjYFtpApCD7Fuor8cvlOWybNFLJEnJGKVHqrf
98B394yzlo86qZAgdOACPMAQMkNX+MSQ7bnwJHS00M7yz6AcuYg6taoJJgt4hW6I
vgQBFgoAZgUCVQ1ew18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45DLMAQDGWbEZ3pn8ECIMtayXq3v/v5D0
X371/kpsnhq9gHVnJgEAFw6w520fZzInyUh/m8Rr7iyBmA/HOKttcguFo+ZG4QA=
=G7jc
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Defaults

2015-03-21 Thread Werner Koch 
On Thu, 19 Mar 2015 11:19, mue...@cryptobitch.de said:

> Is there anything in this listing that would allow me to quickly copy and 
> paste
> (e.g. double click and middle click) in order to further work with the key,
> e.g. edit or encrypt to?

Sorry, I do not understand you.  This is a command line interface and
not a point an click thingie

> The fingerprint would probably be better to identify the key, but, similarly,
> the spaces prevent me from selecting it easily.

Use a GUI tool.

> I thought short keyids are dangerous and should not be used,

They are not more dangerous than long fingerprints.  It depends on what
you want to do.  In my test setting using the short key id is perfectly
okay.  For checking the validity of the key you need to use the
fingerprint and not some keyid or mail address.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: --verify --status-fd separator for multiple signatures?

2015-03-21 Thread Werner Koch 
On Fri, 20 Mar 2015 19:41, patrick-mailingli...@whonix.org said:

> Well, I don't speak C, so I can't make head or tail of "what we do in
> gpgme/src/verify.c".

You should still be able to follow the control flow.  That is not
different from any pseudo code.

> Is there a complete list of all possible start/end keyword combinations?

As, I said, checkout gpgme: 

  switch (code)
{
case GPGME_STATUS_NEWSIG:
  if (sig)
calc_sig_summary (sig);

NEWSIG has been seen: Finalize the output for the current signature if any.

  err = prepare_new_sig (opd);

  opd->only_newsig_seen = 1;

Get ready for a new signature.  That is the helpful feature of NEWSIG.
Note that there is no guarantee that a signature will follow: I maybe
garbled or remove and gpg won't get to the actual verification.

case GPGME_STATUS_GOODSIG:
case GPGME_STATUS_EXPSIG:
case GPGME_STATUS_EXPKEYSIG:
case GPGME_STATUS_BADSIG:
case GPGME_STATUS_ERRSIG:
case GPGME_STATUS_REVKEYSIG:
  if (sig && !opd->did_prepare_new_sig)
calc_sig_summary (sig);

If we have a signature and we are not yet preparing for a new signature
(i.e. have not called prepare_new-sig): Finalize the output for the
current signature

  opd->only_newsig_seen = 0;

Clear flag for NEWSIG seen.

  return parse_new_sig (opd, code, args, ctx->protocol);

Do something with the signature.  This fucntion calls prepare_new_sig if
not yet done.

case GPGME_STATUS_VALIDSIG:
  opd->only_newsig_seen = 0;
  return sig ? parse_valid_sig (sig, args, ctx->protocol)
: trace_gpg_error (GPG_ERR_INV_ENGINE);

VALIDSIG is the modern version of GOODSIG.  Take care of it.


case GPGME_STATUS_NODATA:
  opd->only_newsig_seen = 0;

Forget about NEWSIG.  The code in GPGME requires this here and for
several other status messages.

case GPGME_STATUS_EOF:
  if (sig && !opd->did_prepare_new_sig)
calc_sig_summary (sig);
  if (opd->only_newsig_seen && sig)
{
  gpgme_signature_t sig2;
  /* The last signature has no valid information - remove it
 from the list. */

On EOF finalize the last signature.  If a NEWSIG has neen seen remove
the prepared information.

Proper verification is a bit complicate if you need to do this in the
most general way.  You can get away much easier in many cases.  For
example VALIDSIG gives you all the information about correctly verified
signatures.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

RE: Email-only UIDs and verification (was: Making the case for smart cards for the average user)

2015-03-21 Thread Daniel Kahn Gillmor 
On Fri 2015-03-20 13:43:27 -0400, Bob (Robert) Cavanaugh wrote:
> One thought to add to the mix: Phishng attacks by having
> unknowledgable users "click on this link" are pretty
> successful. Doesn't this proposal open a new threat vector?

There are a lot of proposals in this thread, and you didn't trim the
quoted text to isolate just one of them; can you be specific about which
one you're talking about?

I think you're talking about the proposal to have a verification service
send regular e-mails asking users to follow up on them.

If the followup is just "click this link" then i agree it's probably
encouraging bad habits.  What if the suggested followup was an e-mail
reply?  What if we require the verifier to sign its outbound messages,
and tell users "don't do this unless the message is signed by the
verifier"?

I'm still not sure how useful this is in the big picture -- is such a
verifier only for first-contact, or is it supposed to be useful
longer-term as well?

--dkg

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Email-only UIDs and verification

2015-03-21 Thread Ville Määttä 
On 20.03.15 20:47, Daniel Kahn Gillmor wrote:
> On Fri 2015-03-20 13:43:27 -0400, Bob (Robert) Cavanaugh wrote:
>> > One thought to add to the mix: Phishng attacks by having
>> > unknowledgable users "click on this link" are pretty
>> > successful. Doesn't this proposal open a new threat vector?

Yeah… I don't really see much of a problem as proposed by Bob. Any
verification emails for any purpose should always be related to an
action the user did very recently. I.e. they visited a site or used an
application, whatever the route and method but they should already /be
expecting an email verification/.

> If the followup is just "click this link" then i agree it's probably
> encouraging bad habits.

Any verification should certainly be worded better, yes :).

> What if the suggested followup was an e-mail
> reply?  What if we require the verifier to sign its outbound messages,
> and tell users "don't do this unless the message is signed by the
> verifier"?

Good ideas.

-- 
Ville



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Email-only UIDs and verification (was: Making the case for smart cards for the average user)

2015-03-21 Thread Jose Castillo 
On Mar 20, 2015, at 2:47 PM, Daniel Kahn Gillmor  wrote:
> If the followup is just "click this link" then i agree it's probably
> encouraging bad habits.  What if the suggested followup was an e-mail
> reply?  What if we require the verifier to sign its outbound messages,
> and tell users "don't do this unless the message is signed by the
> verifier”?

I think MFPA had a good idea earlier in the thread: the first message, the 
request for a signature on the UID, is signed; whether the from address is 
spoofed or not, the automated service can’t be sure. What if the automated 
service went ahead and made the certification anyway, but encrypted it before 
sending it? At that point only the recipient in the UID field will receive the 
email, and they’ll only have access to the certification if they’re also in 
control of the key to decrypt it. There’s no followup required. 

> I'm still not sure how useful this is in the big picture -- is such a
> verifier only for first-contact, or is it supposed to be useful
> longer-term as well?

The thought process here is that when someone generates their identity, it’s 
not trusted by anyone, and they don’t trust anyone by default. It’s up to them 
to build the trust landscape themselves, which isn’t a great user experience 
for the layperson. This proposal is about establishing a minimal viable trust 
scheme based around persona-level certification of verified email addresses. 
The user can augment that with their own web of trust as needed. 

Ideally, I’d like to be able to present UI that shows a signature from an 
untrusted key as an error condition, in much the same way your browser warns 
you about an untrusted SSL certificate. That’s difficult if you have to 
establish yourself in a web of trust first. 

-- 

Joey Castillo
www.joeycastillo.com


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Error Installing gnupg-2.0.27 on Debian Squeeze

2015-03-21 Thread Angel Parrales 
Following instructions included in documentation, is not possible to
complete installation,
Last lines pasted below:

make[3]: Entering directory
`/home/adolfo/Downloads/gnupg-2.0.27/tests/openpgp'
echo '#!/bin/sh' >./gpg_dearmor
echo "../../g10/gpg2 --homedir . --no-options --no-greeting \
 --no-secmem-warning --batch --dearmor" >>./gpg_dearmor
chmod 755 ./gpg_dearmor
./gpg_dearmor > ./pubring.gpg < ./pubring.asc
../../g10/gpg2: error while loading shared libraries: libgcrypt.so.20:
cannot open shared object file: No such file or directory
make[3]: *** [pubring.gpg] Error 127
make[3]: Leaving directory
`/home/adolfo/Downloads/gnupg-2.0.27/tests/openpgp'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/adolfo/Downloads/gnupg-2.0.27/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/adolfo/Downloads/gnupg-2.0.27'
make: *** [all] Error 2

Your help is highly appreciated.

Thanks and Regards,
-- Angel Parrales

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users