From qazxswedc at openmailbox.org  Sat Aug  1 19:42:21 2015
From: qazxswedc at openmailbox.org (Qaz)
Date: Sat, 01 Aug 2015 20:42:21 +0300
Subject: Can't access some GnuPG link via Tor Browser nor i2p
Message-ID: <55BD04FD.1060005@openmailbox.org>

Hi!

I can't access this link -
http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html - and this
is what I get, http://a.uguu.se/voydji.png

How do I go about this?

Thanks!



From 2014-667rhzu3dc-lists-groups at riseup.net  Sun Aug  2 13:32:10 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sun, 2 Aug 2015 12:32:10 +0100
Subject: Can't access some GnuPG link via Tor Browser nor i2p
In-Reply-To: <55BD04FD.1060005@openmailbox.org>
References: <55BD04FD.1060005@openmailbox.org>
Message-ID: <12010272127.20150802123210@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Saturday 1 August 2015 at 6:42:21 PM, in
<mid:55BD04FD.1060005 at openmailbox.org>, Qaz wrote:


> Hi!

> I can't access this link -
> http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html
> - and this is what I get, http://a.uguu.se/voydji.png

> How do I go about this?

It's not a Tor or I2P problem. I tried directly without using either,
and the page is down for me as well.

The document you are seeking is dated August 2004, so probably
contains at least some material that is obsolete.

It was last archived on the Wayback Machine on 25th May this year.
<https://web.archive.org/web/*/http://www.dewinter.com/gnupg_howto/english/GPGMiniHowto.html>


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Censor: a man who knows more than he thinks you ought to.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJVvf/HXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw6EcIAIf2IJYc0Yw+X30O+go8PiQh
A4wo3zHPvVNnq49eGjc09/669gd6DVrzQvpOBIufUv5iKbJxBQbueeWkeZRwwC3Z
DqIVna+DZZbKRdeChLCvGxadlF7PQiFh9mzT1PhKx5EIdxTtfyXvKgdejtqOSs1B
NUWiujJFPQLDGyyQeNmkjBPo1BLIrky1Y5eU58CbGw5wzLcBKc9W4K1UEzW1QxLI
/aQlzd5ZHCqGpl2nQ0Nx3UvWHY3dzXg88U6KV8AzCiknJ9M5WP9t4VsEjtu0j6S+
/jenrMGCWqJWnxrixeeV4Q7lkCRQnvFncKXDUTwlruIKdSR3Qygple6sEbfrY9eI
vgQBFgoAZgUCVb3/zF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45EHnAQCND7u8bv/3tTdyVM+eFtUo6d8R
0nXBR2LeTzSI+DelswEAqaVG1Nobw61MoV8MAlnBLlzRlut3d3empC80thrC3w8=
=RM6b
-----END PGP SIGNATURE-----



From brian at minton.name  Mon Aug  3 00:19:20 2015
From: brian at minton.name (Brian Minton)
Date: Sun, 2 Aug 2015 18:19:20 -0400
Subject: Problems with key available in v1.4.19 but not v2.1.5
In-Reply-To: <55A95BFA.4090102@gmail.com>
References: <55A95BFA.4090102@gmail.com>
Message-ID: <CANyOob38kdWE6LCfFEt-_LQ1DU-r0Fc1KtYj63eP3CANH=KcnQ@mail.gmail.com>

The 2.1 branch deprecates all pgp v2 keys. My guess is that your old key
was one of those.  See https://gnupg.org/faq/whats-new-in-2.1.html#nopgp2
for details.

On Fri, Jul 17, 2015, 4:53 PM Philip Neukom <pneukom at gmail.com> wrote:

> Hello all.
>
> I'm having some problems with my key that was created a long time ago
> (1994) but updated with new emails over the years.
>
> I am stuck after searching for an answer so thought I'd ask for some
> guidance from the list.  I have reviewed the Docs, Mini Guide and HowTos.
>
> I apologize in advance for the rather lengthy email but I figured I
> had to put as much info so you may see what I've tried.
>
> I moved my keys pubring.gpg, secring.pgp and trustdb.gpg to a new Mac
> over the past week.
>
> I downloaded and installed MacGPG for the GUI. I only installed the GPG
> Keychain, GPG Services and MacGPG.
>
> When I opened the GPG Keychain, all the keys were on the screen for a
> brief moment and then the list shrunk and many keys disappeared in
> addition to my personal public and secret keys. ???
>
> So panic set in and I restored my pubring and secring from backup and
> deleted the install of MacGPG.  I thought maybe there was a problem
> with MacGPG so best to go back to command line Gnupg.
>
> I installed 2.1.5 from source and found none of my keys in the
> pubring and secring. What???
>
> So I downloaded and installed 1.4.19, restored the pubring and secring
> from backup again and found my public and secret keys are now listed.
> This time I generated a revoke just in case and to test the install.
> 1.4.19 works fine.
>
> Now I re-ran 2.1.5 and tried to find my keys.  Again they've gone
> missing. [# gpg2 --list-keys]  None of my keys (pub and sec) are
> available in 2.1.5.
>
> Re-running [gpg --list-keys] with 1.4.19 and my keys are still there.
>
> Why would v1.4.19 show my pub and sec keys but v2.1.5 wouldn't?  I
> presume this is something very basic but I'm stumped.  I thought v1.x
> and v2.x keys were interoperable??
>
> Thanks in advance for any guidance,
> Philip.
>
> PS I'm on digest mode so would appreciate if you could cc me directly on
> any reply.  Thanks.
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150802/b6292e03/attachment.html>

From trendelkamp at zedat.fu-berlin.de  Mon Aug  3 20:51:27 2015
From: trendelkamp at zedat.fu-berlin.de (Benjamin Trendelkamp-Schroer)
Date: Mon, 03 Aug 2015 20:51:27 +0200
Subject: make check fails for gnupg-2.0.28
Message-ID: <55BFB82F.7080305@zedat.fu-berlin.de>

Hi,

I was trying to build gnupg-2.0.28 using the sources from

https://www.gnupg.org/download/index.html

I was able to make, but some tests fail when upon make check.

System details are Ubuntu 14.04

uname -r
3.13.0-57-generic

Should I be worried? I hope I am posting this at the right spot, please 
let me know if not.

Thanks in advance,

Benjamin

Please find the full output of make check below,

Making check in m4
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/m4'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/m4'
Making check in gl
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/gl'
make  check-am
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/gl'
make[2]: Nothing to be done for `check-am'.
make[2]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/gl'
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/gl'
Making check in include
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/include'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/include'
Making check in jnlib
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/jnlib'
make  check-TESTS
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/jnlib'
PASS: t-stringhelp
=============
1 test passed
=============
make[2]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/jnlib'
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/jnlib'
Making check in common
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/common'
make  check-am
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/common'
make  check-TESTS
make[3]: Entering directory `/home/leonardo/src/gnupg-2.0.28/common'
PASS: t-convert
PASS: t-percent
PASS: t-gettime
PASS: t-sysutils
PASS: t-sexputil
max. file descriptors: 4096
open file descriptors: 3
PASS: t-exechelp
Known envvars: GPG_TTY(ttyname) TERM(ttytype) DISPLAY(display) 
XAUTHORITY(xauthority) XMODIFIERS GTK_IM_MODULE QT_IM_MODULE 
PINENTRY_USER_DATA(pinentry-user-data)
PASS: t-session-env
PASS: t-ssh-utils
==================
All 8 tests passed
==================
make[3]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/common'
make[2]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/common'
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/common'
Making check in kbx
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/kbx'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/kbx'
Making check in g10
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/g10'
make  check-TESTS
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/g10'
PASS: t-rmd160
=============
1 test passed
=============
make[2]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/g10'
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/g10'
Making check in keyserver
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/keyserver'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/keyserver'
Making check in sm
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/sm'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/sm'
Making check in agent
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/agent'
make  check-TESTS
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/agent'
PASS: t-protect
=============
1 test passed
=============
make[2]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/agent'
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/agent'
Making check in scd
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/scd'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/scd'
Making check in tools
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/tools'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/tools'
Making check in po
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/po'
make[1]: Nothing to be done for `check'.
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/po'
Making check in doc
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/doc'
make  check-am
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/doc'
make[2]: Nothing to be done for `check-am'.
make[2]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/doc'
make[1]: Leaving directory `/home/leonardo/src/gnupg-2.0.28/doc'
Making check in tests
make[1]: Entering directory `/home/leonardo/src/gnupg-2.0.28/tests'
Making check in openpgp
make[2]: Entering directory `/home/leonardo/src/gnupg-2.0.28/tests/openpgp'
make  check-TESTS
make[3]: Entering directory `/home/leonardo/src/gnupg-2.0.28/tests/openpgp'
gpg (GnuPG) 2.0.28
libgcrypt 1.6.3
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/leonardo/src/gnupg-2.0.28/tests/openpgp
Supported algorithms:
Pubkey: RSA, RSA, RSA, ELG, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
         CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB
PASS: version.test
PASS: mds.test
FAIL: decrypt.test
PASS: decrypt-dsa.test
FAIL: sigs.test
PASS: sigs-dsa.test
FAIL: encrypt.test
     > IDEA 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 
CAMELLIA192 CAMELLIA256 <
PASS: encrypt-dsa.test
FAIL: seat.test
FAIL: clearsig.test
FAIL: encryptp.test
FAIL: detach.test
FAIL: armsigs.test
FAIL: armencrypt.test
FAIL: armencryptp.test
FAIL: signencrypt.test
PASS: signencrypt-dsa.test
FAIL: armsignencrypt.test
FAIL: armdetach.test
FAIL: armdetachm.test
FAIL: detachm.test
PASS: genkey1024.test
     > IDEA 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 
CAMELLIA192 CAMELLIA256 <
PASS: conventional.test
     > IDEA 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH CAMELLIA128 
CAMELLIA192 CAMELLIA256 <
PASS: conventional-mdc.test
PASS: multisig.test
PASS: verify.test
PASS: armor.test
PASS: import.test
======================================
15 of 28 tests failed
Please report to http://bugs.gnupg.org
======================================

|

|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150803/ea3aa5c7/attachment-0001.html>

From wk at gnupg.org  Mon Aug  3 23:07:15 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 03 Aug 2015 23:07:15 +0200
Subject: make check fails for gnupg-2.0.28
In-Reply-To: <55BFB82F.7080305@zedat.fu-berlin.de> (Benjamin
 Trendelkamp-Schroer's message of "Mon, 03 Aug 2015 20:51:27 +0200")
References: <55BFB82F.7080305@zedat.fu-berlin.de>
Message-ID: <87614wulmk.fsf@vigenere.g10code.de>

On Mon,  3 Aug 2015 20:51, trendelkamp at zedat.fu-berlin.de said:

> Should I be worried? I hope I am posting this at the right spot,

Sure.  Your build is not working.

> FAIL: decrypt.test

There is a file tests/openpgp/decrypt.test.log with details of the test
run.  Please show us the content of that file.


Shalom-Salam,

   Werner

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



From dkg at fifthhorseman.net  Wed Aug  5 01:05:12 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 04 Aug 2015 19:05:12 -0400
Subject: Proposal of OpenPGP Email Validation
In-Reply-To: <55B5C7B7.4090907@enigmail.net>
References: <55B5C7B7.4090907@enigmail.net>
Message-ID: <871tfi4puf.fsf@alice.fifthhorseman.net>

Hi all---

On Mon 2015-07-27 01:55:03 -0400, nico at enigmail.net wrote:
> In the past months I tried to come up with a concrete proposal.
> I discussed it already with some people and
> this is what I/we propose so far.

Sorry to take a while to respond to this thread.  I think a proposal for
an e-mail-validating keyserver/mail-loop can be evaluated in several
different ways.  unfortunately, none of them look to me like they'll
solve the concerns of the c't editor automatically without introducing
other problems.

Some ways of looking at the problem:

 0) is it OK to run an autonomous validating OpenPGP certification
    agent?

I think the answer here is clearly "yes".  OpenPGP keys make
certifications based on their own policies, and if you set up something
like this, you can set the policy to whatever you like.  Some people
might even use it, like people used their PGP Global Directory as a
public attestation service.

 1) What (if any) technical structure should there be for an autonomous
    validating OpenPGP certification agent?

This thread discussed several options, including e-mail pingbacks,
requirements of PoW, notation data, etc.  I don't have a strong opinion
on this, and i tend to think that a bit of experimentation with actually
running such an agent would be more fruitful than abstract discussion.

 2) Should existing OpenPGP clients be willing to rely on certifications
    made by such an autonomous validating OpenPGP certification agent?
    if so, which one(s) ?

This is now asking the same question as "should browsers/OSes come with
a built-in list of X.509 trust anchors?"  From the perspective of the
global network, where many people use the same tools but have different
and non-aligned goals and interests, the answer is clearly "no" to me.
But of course the practical answer to most deployed software
installations is "yes", because even extremely technically-sophisticated
people don't understand how to (or have a way to) configure their trust
anchors to align with their own interests.

Should OpenPGP implementations follow this model?  I'm not convinced it
should: it creates high-value targets (the widely-relied-upon
certification agents), and provides little to no mechanisms for
oversight/auditing of those targets.

That said, the possibility of assigning marginal ownertrust to such an
agent, coupled with the existence and common usage of the keyserver
network makes it possible provide a bit more oversight on the use of
these high-valued keys than we have in the (current CT-less) X.509
ecosystem.


------

In summary, i would not want the responsibility of running one of these
agents myself.  If one existed, i would be fine submitting my own
OpenPGP certificate to it for its certification, assuming its
certifications don't bloat my cert too much, and i'd be happy to give
feedback about its workflow/security posture to whoever is operating it.

I don't think that any special notations are necessary for such a use.
Just treat it as a special certification-only OpenPGP cert, and document
its certification policy clearly.

I'd be disappointed if GnuPG or other OpenPGP tools were to decide that
they "trusted" such an agent on behalf of all users.

So, does this solve the problem that the c't folks had?  Not without a
lot of other tooling and incentives that don't exist yet.  Could such an
agent be a useful contribution to a larger certification ecosystem?
Possibly, but we won't know that until someone is willing to step up to
be responsible for such an agent, and to try it out.

          --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20150804/da1ddd07/attachment.sig>

From dkg at fifthhorseman.net  Wed Aug  5 06:33:51 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 05 Aug 2015 00:33:51 -0400
Subject: no valid user IDs after changing key expiration time
In-Reply-To: <55AFCD40.3070006@riseup.net>
References: <55AFAA66.9080508@riseup.net> <55AFAD84.4070306@hammernoch.net>
 <55AFCD40.3070006@riseup.net>
Message-ID: <8737zy2w28.fsf@alice.fifthhorseman.net>

On Wed 2015-07-22 13:05:04 -0400, flapflap wrote:
> Ludwig H?gelsch?fer:
>> On 22.07.15 16:36, flapflap wrote:
>> 
>>> Should I be worried by the warning or is this normal behaviour?
>> 
>> You should set ultimate ownertrust on your own key after
>> (re-)importing. Then it will become valid again.
>
> My key still looked/looks valid, even without changing the ownertrust
> (in that case its ownertrust is just shown as unknown).  All UIDs are
> present.
>
> What seems strange to me is that I do not see the warning message when I
> import the previous version of my key (exported about a year ago).
> The warning only appears when I change the expiration time of that key,
> export it, delete it, and then re-import it (including secret key).

can you share the fingerprint of the key in question?  have you tried
this with a more recent version of GnuPG than 2.0.25 ?

     --dkg


From lburgess at harrisconnect.com  Tue Aug  4 15:57:25 2015
From: lburgess at harrisconnect.com (Burgess, Laurie)
Date: Tue, 4 Aug 2015 13:57:25 +0000
Subject: Upgrading gpupg
Message-ID: <469C16D2247BBF49BBE9FB2B320B9BBAE05CF00C@chmail1.bcharrispub.com>

Hello,

     I am running HP-UX vers 11.11.  I have gpg installed on my system, but when I try to find out the version by doing gpg -version, it core dumps.  I am guessing it's an old version.  Do I need to remove that version before installing the 2.0.22 version?

We are also using PGP currently, and I don't want the install/upgrade/deinstall of GPG to interfere with our current PGP keys and processes.

Please advise.  Thank you very much for your time.

Laurie Burgess
lburgess at harrisconnect.com<mailto:lburgess at harrisconnect.com>


This message and any attached files might contain confidential information protected by federal and state law. The information is intended only for the use of the individual(s) or entities originally named as addressees. If this message reached you in error, please contact the sender and destroy this message. Disclosing, copying, forwarding, or distributing the information by unauthorized individuals or entities is strictly prohibited by law, and may be subject to civil or criminal penalties.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150804/c91104a6/attachment.html>

From dieamme at googlemail.com  Wed Aug  5 15:02:02 2015
From: dieamme at googlemail.com (thomas)
Date: Wed, 5 Aug 2015 15:02:02 +0200
Subject: {gnupg 2.1.6} Howto change s2k cipher from AES -> AES256?
In-Reply-To: <87380ilubm.fsf@vigenere.g10code.de>
References: <20150712204632.4e715e85@TTM-i5.homenet>
 <87380ilubm.fsf@vigenere.g10code.de>
Message-ID: <20150805150202.1f0afe2e@TTM-i5.homenet>

Hello,
thx for your feedback.

>---0----+----1----+----2----+----3----+----4----+----5----+----6----+
>2015-07-20 - Werner Koch schrieb:
>
>With GnuPG 2.1 the s2k options are only used for --symmetric encryption.

Ok, but the secret Keys in "private-keys-v1.d" are
encrypted with (symmetric) AES128.

[...]
> Right now that is not possible because it would
> break too many old installations.

Ok, but can the hash algo changed to sha2?


If i understand it right, with gnupg < 2.1.x, the private keys in
the sec Keyring are stored with the usage of a stronger hash algo.

My question is, why securing the private key's with sha1?


-- 
Best regards,
Thomas



From peter at digitalbrains.com  Wed Aug  5 15:45:52 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 05 Aug 2015 15:45:52 +0200
Subject: {gnupg 2.1.6} Howto change s2k cipher from AES -> AES256?
In-Reply-To: <20150805150202.1f0afe2e@TTM-i5.homenet>
References: <20150712204632.4e715e85@TTM-i5.homenet>
 <87380ilubm.fsf@vigenere.g10code.de> <20150805150202.1f0afe2e@TTM-i5.homenet>
Message-ID: <55C21390.6060709@digitalbrains.com>

On 05/08/15 15:02, thomas wrote:
> My question is, why securing the private key's with sha1?

Your question begs an interesting, though pretty academical question: what would
be even more difficult to crack: SHA-512 with an s2k-count equalling 1 second on
a modern Intel PC, or SHA-1 with an s2k-count equalling 1 second on that same PC?

Because you can clearly do many more SHA-1 rounds in one second, improving its
robustness against cracking.

It depends on so many factors. For instance: What is the speedup of a massive
FPGA-based implementation relative to that PC for both cases?

I wouldn't dare to say whether SHA-1 or SHA-512 would be the "better" option. I
do dare to say that it probably doesn't actually matter, since completely
utterly unbreakable is just as unbreakable as regular unbreakable. More
importantly, the key stretching does not appear to be the weakest component of
private key encryption either (that would usually be the passphrase itself).

Why do you think a configuration option for the key stretching hash algorithm
would be useful?

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From wk at gnupg.org  Wed Aug  5 20:34:23 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 05 Aug 2015 20:34:23 +0200
Subject: {gnupg 2.1.6} Howto change s2k cipher from AES -> AES256?
In-Reply-To: <20150805150202.1f0afe2e@TTM-i5.homenet> (thomas's message of
 "Wed, 5 Aug 2015 15:02:02 +0200")
References: <20150712204632.4e715e85@TTM-i5.homenet>
 <87380ilubm.fsf@vigenere.g10code.de>
 <20150805150202.1f0afe2e@TTM-i5.homenet>
Message-ID: <874mkdshxs.fsf@vigenere.g10code.de>

On Wed,  5 Aug 2015 15:02, dieamme at googlemail.com said:

> Ok, but the secret Keys in "private-keys-v1.d" are
> encrypted with (symmetric) AES128.
[...]
> My question is, why securing the private key's with sha1?

I am not sure whether I understand your question.  If you mean the SHA-1
as mentioned in the algo string of the private key files:

  openpgp-s2k3-sha1-aes-cbc

  This describes an algorithm using using AES in CBC mode for
  encryption, SHA-1 for integrity protection and the String to Key
  algorithm 3 from OpenPGP (rfc2440).

Thus SHA-1 is not used for protection but to detect tampering of the
encrypted private key.  This is the same method as defined by RFC-4880
but using an S-expression encoding.

The decryption part also knows about openpgp-s2k3-sha1-aes256-cbc so to
be prepared for the time we want to change to AES-256.  However, it is
questionable whether this will ever be done.  Although the entire
construct is safe on practice, it will eventually be replaced by a
modern AEAD method.



Shalom-Salam,

   Werner


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



From pedereri at gmail.com  Wed Aug  5 16:20:15 2015
From: pedereri at gmail.com (Eric P)
Date: Wed, 5 Aug 2015 16:20:15 +0200
Subject: install problems
Message-ID: <CACOvYh4R3SG1BMR9P_dKPmZgh78=rT1JV7ZmE2zmAS7K5ss8qQ@mail.gmail.com>

Hi I am trying to install 2.0.28 on linux mint 17 but I get this message
even though I have located all of the libraries on my system.... Can I get
some assistance? thanks
***
*** You need libgpg-error to build this program.
** This library is for example available at
*** ftp://ftp.gnupg.org/gcrypt/libgpg-error
*** (at least version 1.11 is required.)
***
configure:
***
*** You need libgcrypt to build this program.
** This library is for example available at
*** ftp://ftp.gnupg.org/gcrypt/libgcrypt/
*** (at least version 1.5.0 using API 1 is required.)
***
configure:
***
*** You need libassuan to build this program.
*** This library is for example available at
*** ftp://ftp.gnupg.org/gcrypt/libassuan/
*** (at least version 2.0.0 (API 2) is required).
***
configure:
***
*** You need libksba to build this program.
*** This library is for example available at
*** ftp://ftp.gnupg.org/gcrypt/libksba/
*** (at least version 1.0.7 using API 1 is required).
***
configure: error:
***
*** Required libraries not found. Please consult the above messages
*** and install them before running configure again.
***

-- 
Cheers,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150805/4f877fe7/attachment-0001.html>

From manan.navin.mehta at accenture.com  Fri Aug  7 06:41:03 2015
From: manan.navin.mehta at accenture.com (manan.navin.mehta at accenture.com)
Date: Fri, 7 Aug 2015 04:41:03 +0000
Subject: Facing issue while installing GnuPG 2.0.27 on AIX 7.1
References: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net>
 <87eglqftc3.fsf@vigenere.g10code.de>   
Message-ID: <57804ba97310469cbf56c50228c4d128@CO2PR42MB076.048d.mgd.msft.net>

Hi Werner,

We are still awaiting for your inputs..!!!

Kindly go through the trail mail for the details.

Request you to look into it and kindly suggest the path forward so that we can go ahead and install it in other systems.

[cid:image001.png at 01D0D03E.C08F2220]

From: Navin Mehta, Manan
Sent: Wednesday, July 01, 2015 12:47 PM
To: 'Werner Koch'; 'gnupg-users at gnupg.org'; 'gnupg-devel at gnupg.org'
Cc: DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv; Kothari, Jayesh
Subject: RE: Facing issue while installing GnuPG 2.0.27 on AIX 7.1

Additional details on the trail mail....kindly look into the same.

It errors out even when creating a key :
Note - anything that calls gpg-agent gets dumped  ( you may want to mention this in your email to support)


sdlux09:#> ./GnuPG/gnupg-2.0.27/g10/gpg2 --gen-key
gpg (GnuPG) 2.0.27; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 1024
Requested keysize is 1024 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 1
Key expires at Thu Jul  2 06:43:39 UCT 2015
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Jayesh
Email address: jayesh.kothari at accenture.com<mailto:jayesh.kothari at accenture.com>
Comment: Test
You selected this USER-ID:
    "Jayesh (Test) <jayesh.kothari at accenture.com<mailto:jayesh.kothari at accenture.com>>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.   ( didn't let met enter anything)


gpg: signal 11 caught ... exiting
Segmentation fault


[cid:image001.png at 01D0D03E.C08F2220]

From: Navin Mehta, Manan
Sent: Wednesday, July 01, 2015 11:31 AM
To: 'Werner Koch'; 'gnupg-users at gnupg.org'; 'gnupg-devel at gnupg.org'
Cc: DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv; Kothari, Jayesh
Subject: RE: Facing issue while installing GnuPG 2.0.27 on AIX 7.1

Hi Werner/GnuPG Team,

Greetings..!!

Need your expert advice/suggestions..!!

After upgrading the Compiler and having all the required Lib files, it seems that GnuPG has been installed, PFB excerpt from the log which we got after triggering below command:
Also, PFA "config.log" which automatically gets generated and "GnuPG_log" which has logs copied from screen after running below command.

Request you to look into it and check whether GnuPG has been installed correctly or not and kindly also let us know if any post steps are required..

Command used: ./configure; make; make install

        GnuPG v2.0.27 has been configured as follows:

        Revision:  8d47e6e  (36167)
        Platform:  AIX (powerpc-ibm-aix7.1.2.0)

        OpenPGP:   yes
        S/MIME:    yes
        Agent:     yes
        Smartcard: yes (without internal CCID driver)
        Gpgtar:    no

        Protect tool:      (default)
        Default agent:     (default)
       Default pinentry:  (default)
        Default scdaemon:  (default)
        Default dirmngr:   (default)

        Warning: Mismatches between the target platform and the
                 to be used libraries have been detected for:
                   libgpg-error libgcrypt
                 Please check above for more warning messages.

        make  all-recursive
Making all in m4
Target "all" is up to date.

Thanks a lot in advance :)

[cid:image001.png at 01D0D03E.C08F2220]

From: Navin Mehta, Manan
Sent: Friday, June 05, 2015 3:16 PM
To: 'Werner Koch'
Cc: gnupg-users at gnupg.org<mailto:gnupg-users at gnupg.org>; gnupg-devel at gnupg.org<mailto:gnupg-devel at gnupg.org>; DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv; Kothari, Jayesh
Subject: RE: Facing issue while installing GnuPG 2.0.27 on AIX 7.1


Hi Werner,



Thanks for your reply.



Sure, we will check with our Unix team for the availability of the C compiler and get it installed.



Request you to address one more query:

? As you have mentioned in the trail mail that "You need to have a compiler and all related tools (the toolchain) to build software" , can you please give more details on "toolchain" ?

What all other tools will be required (other than installing C compiler) for successful installation of GnuPG software.



Thanks again :)



Thanks,

Manan N Mehta

Accenture | SAP BASIS Admin

Email: manan.navin.mehta at accenture.com<mailto:manan.navin.mehta at accenture.com>



-----Original Message-----
From: Werner Koch [mailto:wk at gnupg.org]
Sent: Friday, June 05, 2015 2:03 PM
To: Navin Mehta, Manan
Cc: gnupg-users at gnupg.org<mailto:gnupg-users at gnupg.org>; gnupg-devel at gnupg.org<mailto:gnupg-devel at gnupg.org>; DiEnno, Michael F.; Dawane, Shailendra S.; Sharma, Pramod; Zingade, Swati; Karmakar, Sanjiv
Subject: Re: Facing issue while installing GnuPG 2.0.27 on AIX 7.1



On Thu,  4 Jun 2015 09:04, manan.navin.mehta at accenture.com<mailto:manan.navin.mehta at accenture.com> said:



> Below are the OS level details:

>

> [cid:image006.png at 01D09EBE.3BD6EBA0]



Sorry, I can't view the images as they are only available in the HTML rendered version.  Please always transcript con5tents from screenshots so that it is possible to search for the content.  Anyway, the attached config.log has all the details of your system.



> But still we are facing Error as C compiler cannot create executables



The configure run and the config.log show



> configure:3875: checking whether the C compiler works

> configure:3897: c99 -g   conftest.c -lposix >&5

> ./configure[3899]: c99:  not found



Thus you don't have a compiler installed.  You need to have a compiler and all related tools (the toolchain) to build software.



> If you have 24X7 support help line number then kindly share the

> details.



This is a public mailing list.  If you need commercial support please see http://gnupg.org/service.html .





Shalom-Salam,



   Werner



--

Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



________________________________

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150807/0b5973fb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2970 bytes
Desc: image001.png
URL: </pipermail/attachments/20150807/0b5973fb/attachment-0001.png>

From peter at digitalbrains.com  Fri Aug  7 18:35:03 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 07 Aug 2015 18:35:03 +0200
Subject: Facing issue while installing GnuPG 2.0.27 on AIX 7.1
In-Reply-To: <57804ba97310469cbf56c50228c4d128@CO2PR42MB076.048d.mgd.msft.net>
References: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net>
 <87eglqftc3.fsf@vigenere.g10code.de>
 <57804ba97310469cbf56c50228c4d128@CO2PR42MB076.048d.mgd.msft.net>
Message-ID: <55C4DE37.9090102@digitalbrains.com>

On 07/08/15 06:41, manan.navin.mehta at accenture.com wrote:
> We are still awaiting for your inputs..!!!

If you require timely responses, you can purchase support from g10 Code. This is
a mailing list where volunteers help each other. You can't expect more than that
from it. I see Werner already referred you to http://gnupg.org/service.html for
commercial support, by the way.

Personally, I dislike multiple exclamation marks. It makes you sound petulant;
I'm sure you didn't mean it that way.

> Kindly go through the trail mail for the details.

Please quote correctly when replying in a thread on this mailing list. Trim your
quotes so only that which you are immediately responding to is left, and put
your response below that quote. If somebody needs more context, they can open
one of the previous messages of the thread.

I can't help you with the problem you're having.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From alexanderino at gmail.com  Fri Aug  7 17:59:00 2015
From: alexanderino at gmail.com (alexanderino at gmail.com)
Date: Fri, 7 Aug 2015 21:29:00 +0530
Subject: Facing issue while installing GnuPG 2.0.27 on AIX 7.1
In-Reply-To: <57804ba97310469cbf56c50228c4d128@CO2PR42MB076.048d.mgd.msft.net>
References: <0b421b1066e8482491ea4a06308d61b2@CO2PR42MB076.048d.mgd.msft.net>
 <87eglqftc3.fsf@vigenere.g10code.de>
 <57804ba97310469cbf56c50228c4d128@CO2PR42MB076.048d.mgd.msft.net>
Message-ID: <CAGKvgRkwBGjNi7WwXfj1e1mmLBpmAjU4Vuxn-AerLGOfhGRguw@mail.gmail.com>

On 7 August 2015 at 10:11, <manan.navin.mehta at accenture.com> wrote:

> Hi Werner,
>
>
>
> We are still awaiting for your inputs..!!!
>
>
>
> Kindly go through the trail mail for the details.
>
>
>
> Request you to look into it and kindly suggest the path forward so that we
> can go ahead and install it in other systems.
>

Dear Manan,

have you considered signing up for commercial support as Werner indicated
earlier? Here is the link again for your convenience:
https://gnupg.org/service.html

Regards,

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150807/95290f82/attachment.html>

From thomas.jarosch at intra2net.com  Fri Aug  7 23:38:40 2015
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Fri, 7 Aug 2015 23:38:40 +0200
Subject: Card reader success report (openpgp card v2.1)
Message-ID: <55C52560.2070408@intra2net.com>

Hello,

as my first post to the list I wanted to write a little success report
about using the openpgp card v2.1 with various smart card readers.

Three readers were tested:
- Cherry ST-2000
- SCM SPR332
- Reiner SCT cyberjack go plus

gnupg2 versions used: 2.1.6 and git HEAD (5b7a80b)

All three of them support pin entry via the keypad. I've first
tested signing a file using a 2048 bit RSA key. All good.

After that I generated a new 4096 bit RSA key via the Cherry ST-2000
as that was the most fragile one from the internal protocol point of view.
(increased buffer sizes and other tweaks in the CCID code)

All three card readers handle 4096 bit RSA keys without trouble.
I've tested signing a file and ssh authentication.

My thanks go to NIIBE Yutaka for fixing the Cherry ST-2000.

Best regards,
Thomas


From gniibe at fsij.org  Tue Aug 11 05:10:28 2015
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 11 Aug 2015 12:10:28 +0900
Subject: Card reader success report (openpgp card v2.1)
In-Reply-To: <55C52560.2070408@intra2net.com>
References: <55C52560.2070408@intra2net.com>
Message-ID: <55C967A4.2080709@fsij.org>

On 08/08/2015 06:38 AM, Thomas Jarosch wrote:
> as my first post to the list I wanted to write a little success report
> about using the openpgp card v2.1 with various smart card readers.

Thank you for your post.

> Three readers were tested:
> - Cherry ST-2000
> - SCM SPR332
> - Reiner SCT cyberjack go plus

I think that USB vendor ID and product ID are:

	Cherry ST-2000  046a:003e

Please confirm that and please let me know IDs for those new products
of SCM SPR332 and Reiner SCT cyberjack go plus.

That's because I maintain pages:

    http://wiki.gnupg.org/CardReader/PinpadInput
    https://wiki.debian.org/GnuPG/CCID_Driver

... along with the scdaemon implementation.


Besides, if you can include information of your operating system and
its version, it helps other users.
-- 


From wk at gnupg.org  Tue Aug 11 17:32:42 2015
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Aug 2015 17:32:42 +0200
Subject: [Announce] GnuPG 2.1.7 released
Message-ID: <87egj9g7s5.fsf@vigenere.g10code.de>

Hello!

The GnuPG Project is pleased to announce the availability of a new
release of GnuPG modern: Version 2.1.7.

The GNU Privacy Guard (GnuPG) is a complete and free implementation
of the OpenPGP standard which is commonly abbreviated as PGP.

GnuPG allows to encrypt and sign data and communication, features a
versatile key management system as well as access modules for public key
directories.  GnuPG itself is a command line tool with features for easy
integration with other applications.  A wealth of frontend applications
and libraries making use of GnuPG are available.  Since version 2 GnuPG
provides support for S/MIME and Secure Shell in addition to OpenPGP.

GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.

Three different branches of GnuPG are actively maintained:

- GnuPG "modern" (2.1) is the latest development with a lot of new
  features.  This announcement is about this branch.

- GnuPG "stable" (2.0) is the current stable version for general use.
  This is what most users are currently using.

- GnuPG "classic" (1.4) is the old standalone version which is most
  suitable for older or embedded platforms.

You may not install "modern" (2.1) and "stable" (2.0) at the same
time.  However, it is possible to install "classic" (1.4) along with
any of the other versions.


Noteworthy changes in version 2.1.7
===================================

 * gpg: Support encryption with Curve25519 if Libgcrypt 1.7 is used.

 * gpg: In the --edit-key menu: Removed the need for "toggle", changed
   how secret keys are indicated, new commands "fpr *" and "grip".

 * gpg: More fixes related to legacy keys in a keyring.

 * gpgv: Does now also work with a "trustedkeys.kbx" file.

 * scd: Support some feature from the OpenPGP card 3.0 specs.

 * scd: Improved ECC support

 * agent: New option --force for the DELETE_KEY command.

 * w32: Look for the Pinentry at more places.

 * Dropped deprecated gpgsm-gencert.sh

 * Various other bug fixes.

A detailed description of the changes found in the 2.1 branch can be
found at <https://gnupg.org/faq/whats-new-in-2.1.html>.

Please be aware that there are still known bugs which we are working on.
Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing
list archives for known problems and workarounds.


Getting the Software
====================

Please follow the instructions found at https://gnupg.org/download/ or
read on:

GnuPG 2.1.7 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found
at <https://gnupg.org/mirrors.html>.  Note that GnuPG is not available
at ftp.gnu.org.

On ftp.gnupg.org you find these files:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.7.tar.bz2  (4803k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.7.tar.bz2.sig

This is the GnuPG source code compressed using BZIP2 and its OpenPGP
signature.

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe  (2578k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe.sig

This is an installer for Windows without graphical frontends except for
a basic Pinentry tool.  Note that on Windows TLS access to keyservers is
not yet available.  The sources used to build the installer can be found
in the same directory with an ".tar.xz" suffix.


Checking the Integrity
======================

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-2.1.7.tar.bz2 you would use this command:

     gpg --verify gnupg-2.1.7.tar.bz2.sig gnupg-2.1.7.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See below for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-2.1.7.tar.bz2, you run the command like this:

     sha1sum gnupg-2.1.7.tar.bz2

   and check that the output matches the next line:

1a345804f34a2acd05c1555e40ddfa297f38438b  gnupg-2.1.7.tar.bz2
dfea3fa2499f64cac223c9329c9f017bc3da11a5  gnupg-w32-2.1.7_20150811.exe
20439f65b8d94ec79523c45ad72418670ca9d5eb  gnupg-w32-2.1.7_20150811.tar.xz



Release Signing Keys
====================

To guarantee that a downloaded GnuPG version has not been tampered by
malicious entities we provide signature files for all tarballs and
binary versions.  The keys are also signed by the long term keys of
their respective owners.  Current releases are signed by one or more
of these four keys:

  2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31]
  Key fingerprint = D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  Werner Koch (dist sig)

  rsa2048/E0856959 2014-10-29 [expires: 2019-12-31]
  Key fingerprint = 46CC 7308 65BB 5C78 EBAB  ADCF 0437 6F3E E085 6959
  David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com>

  rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28]
  Key fingerprint = 031E C253 6E58 0D8E A286  A9F2 2071 B08A 33BD 3F06
  NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org>

  rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31]
  Key fingerprint = D238 EA65 D64C 67ED 4C30  73F2 8A86 1B1C 7EFD 60D9
  Werner Koch (Release Signing Key)

You may retrieve these keys from a keyserver using this command

  gpg --keyserver hkp://keys.gnupg.net --recv-keys  \
                  249B39D24F25E3B6 04376F3EE0856959 \
                  2071B08A33BD3F06 8A861B1C7EFD60D9

The keys are also available at https://gnupg.org/signature_key.html and
in any recently released GnuPG tarball in the file g10/distsigkey.gpg .
Note that this mail has been signed using by a different key.


Internationalization
====================

This version of GnuPG has support for 26 languages with Chinese,
Czech, French, German, Japanese, Russian, and Ukrainian being almost
completely translated (2074 different strings).


Documentation
=============

If you used GnuPG in the past you should read the description of
changes and new features at doc/whats-new-in-2.1.txt or online at

  https://gnupg.org/faq/whats-new-in-2.1.html

The file gnupg.info has the complete user manual of the system.
Separate man pages are included as well but they have not all the
details available as are the manual.  It is also possible to read the
complete manual online in HTML format at

  https://gnupg.org/documentation/manuals/gnupg/

or in Portable Document Format at

  https://gnupg.org/documentation/manuals/gnupg.pdf .

The chapters on gpg-agent, gpg and gpgsm include information on how
to set up the whole thing.  You may also want search the GnuPG mailing
list archives or ask on the gnupg-users mailing lists for advise on
how to solve problems.  Many of the new features are around for
several years and thus enough public knowledge is already available.

You may also want to follow postings at https://gnupg.org/blob/.


Support
========

Please consult the archive of the gnupg-users mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  For commercial support
requests we keep a list of known service companies at:

  https://gnupg.org/service.html

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gnupg-devel mailing
list for discussion.


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Maintenance and development of GnuPG is possible due to many
individual and corporate donations; for a list of non-anonymous donors
see <https://gnupg.org/donate/kudos.html>.


For the GnuPG hackers,

   Werner


p.s.
This is a announcement only mailing list.  Please send replies only to
the gnupg-users at gnupg.org mailing list.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20150811/d8190055/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From the2nd at otpme.org  Tue Aug 11 20:10:18 2015
From: the2nd at otpme.org (the2nd at otpme.org)
Date: Tue, 11 Aug 2015 20:10:18 +0200
Subject: gpg-agent: error accessing card: Conflicting use
In-Reply-To: <ad006b8edb17b8c94a8f33cc7efa4dde@otpme.org>
References: <ad006b8edb17b8c94a8f33cc7efa4dde@otpme.org>
Message-ID: <05532bd82a9b5d55402d32215487b0a7@otpme.org>

Hi again :)

nobody else with this problem?



On 2015-05-30 14:25, the2nd at otpme.org wrote:
> Hi,
> 
> i have a problem with gpg-agent when using it with a yubikey neo.
> after some time gpg-agent refuses to sign any data and so any ssh
> login with my key stored on the yubikey will fail. the gpg-agent log
> shows the following messages:
> 
> 2015-05-30 13:49:36 gpg-agent[3600] error accessing card: Conflicting 
> use
> 2015-05-30 13:49:36 gpg-agent[3600] smartcard signing failed: 
> Conflicting use
> 2015-05-30 13:49:38 gpg-agent[3600] error getting default
> authentication keyID of card: Conflicting use
> 
> the command to start gpg-agent on KDE login is:
> eval "$(/usr/bin/gpg-agent --daemon --enable-ssh-support --log-file
> ~/.gnupg/gpg-agent.log)"
> 
> i haven't found the exact circumstances when it happens but its more
> likely to happen when the yubikey was plugged off and re-inserted, but
> it also happens without pull off from time to time. a restart of
> gpg-agent fixes the issue. it also often happens after i've pressed
> the yubikey button to generate an OTP but not always.
> 
> gnupg version is 2.0.27-r1 running on sabayon linux.
> 
> when using the same yubikey on my ubuntu 14.04 notebook at work i
> never had this problem.
> 
> thanks for any help.
> 
> regards
> the2nd


From bryant at bryantevans.com  Wed Aug 12 01:43:18 2015
From: bryant at bryantevans.com (Bryant Evans)
Date: Tue, 11 Aug 2015 18:43:18 -0500
Subject: Inability to export and then import my secret key
Message-ID: <55CA8896.4020606@bryantevans.com>

I am using Gpg4Win and Enigmail in Thunderbird. I have been a user of
Enigmail for years without difficulty. Today I tried to load a new
computer and tried to export my secret key from my old machine to the
new one. The system tells me

Importing the keys failed

gpg: key 1C0B95E5: "J. Bryant Evans <bryant at bryantevans.com>" not
changed gpg: key 1C0B95E5: "J. Bryant Evans
<bryant at bryantevans.com>" not changed gpg: key 1C0B95E5/1C0B95E5:
error sending to agent: End of file gpg: Total number processed: 3 
gpg:              unchanged: 2 gpg:       secret keys read: 2

The result is that I can neither sign nor decrypt using my secret key. I can verify signatures from other people. The system at home, on which I am now writing this message, works fine.

I appear to be running 2.0.19 and GPG4WIN 2.1.1

Your thoughts and suggestions would be appreciated.
Bryant



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 663 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150811/7f0fecaa/attachment.sig>

From mirimir at riseup.net  Wed Aug 12 04:00:00 2015
From: mirimir at riseup.net (Mirimir)
Date: Tue, 11 Aug 2015 20:00:00 -0600
Subject: Inability to export and then import my secret key
In-Reply-To: <55CA8896.4020606@bryantevans.com>
References: <55CA8896.4020606@bryantevans.com>
Message-ID: <55CAA8A0.8090408@riseup.net>

On 08/11/2015 05:43 PM, Bryant Evans wrote:
> I am using Gpg4Win and Enigmail in Thunderbird. I have been a user
> of Enigmail for years without difficulty. Today I tried to load a
> new computer and tried to export my secret key from my old machine
> to the new one. The system tells me
> 
> Importing the keys failed
> 
> gpg: key 1C0B95E5: "J. Bryant Evans <bryant at bryantevans.com>" not 
> changed gpg: key 1C0B95E5: "J. Bryant Evans 
> <bryant at bryantevans.com>" not changed gpg: key 1C0B95E5/1C0B95E5: 
> error sending to agent: End of file gpg: Total number processed: 3
>  gpg:              unchanged: 2 gpg:       secret keys read: 2
> 
> The result is that I can neither sign nor decrypt using my secret
> key. I can verify signatures from other people. The system at home,
> on which I am now writing this message, works fine.
> 
> I appear to be running 2.0.19 and GPG4WIN 2.1.1
> 
> Your thoughts and suggestions would be appreciated. Bryant

It's simplest to just copy the gpg folder. Importing private keys is
broken by design.


From nico at enigmail.net  Wed Aug 12 07:44:24 2015
From: nico at enigmail.net (nico at enigmail.net)
Date: Wed, 12 Aug 2015 07:44:24 +0200
Subject: How to deal with a 2nd OpenPGP Summit?
Message-ID: <55CADD38.5030603@enigmail.net>

Hi all,

in April 2015 we had a first OpenPGP summit.
It was a meeting where the technical experts of projects and tools
dealing with OpenPGP with a focus on email encryption
met to getting to know each other personally and
discuss several issues.
For details, see e.g.
- https://www.gnupg.org/blog/20150426-openpgp-summit.html
- https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html

The meting initially was organized by me to bring together
a few guys/projects working in that area, but it became
pretty big (about 30 people). This caused some problems,
because we had a host with limited space (so I finally
even had to reject some people wanting to attend).

We also discussed there how to continue.
On one hand we wanted to have the meeting open so that
anybody wanting to attend could do that and to give trust
by transparency.
On the other hand we want to be able to continue to focus
on technical issues (having a well signal to noise ratio)
in a not-too-large group of "experts".
We didn't find an appropriate way yet to deal with both
interests.

Now, I am about to organize a second meeting at the end of this year.
And I want to take the "wisdom" of this crowd to discuss this issue.

What I currently have in mind is a meeting open to the public
but with some limitations (one reason is to focus the work, another
is simply limited space although I don't know where we can meet
this time).
For example:
- Some priority for those who did attend the first meeting
- Some priority for "other experts", which didn't join
  the first meeting
  (but how do we handle that?)
- Some limitations that a person plays a "significant role"
  in the community
- Some limitation so that a tool/project should normally
  send only 1 or 2 guys

The obvious other option is to open the meeting to
everybody willing to come, which raises a couple of risks
(simply too many people, too many non-experts or people
 who want to change the focus, ...).

So, my questions are:
=====================

Is it OK for the public/community, if we meet in a way
that is limited as describe above (just for practical reasons)?

Is it OK even if we can't promise full transparency (e.g. by video
taping sessions)?

Would it even be OK, if we meet and constraint what is spoken there
to the Chatham House Rule (see
https://en.wikipedia.org/wiki/Chatham_House_Rule).
Some people requested that because
if anything they say might become public, they might or even
have to be careful what they say.

Any general thoughts or proposals about how to deal with this?

Note that I don't want to have it too complicated.
I organize this meeting in my free time to bring the issues
of this community forward.
And just having too many people is already a problem.
I need an approach I can handle.
Or is it better to have no meeting at all instead of a meeting
with some limitations?

Best
 Nico

-- 
Nicolai M. Josuttis
www.josuttis.de
mailto:nico at enigmail.net
PGP fingerprint: CFEA 3B9F 9D8E B52D BD3F 7AF6 1C16 A70A F92D 28F5



From peter at digitalbrains.com  Wed Aug 12 11:58:58 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 12 Aug 2015 11:58:58 +0200
Subject: Inability to export and then import my secret key
In-Reply-To: <55CAA8A0.8090408@riseup.net>
References: <55CA8896.4020606@bryantevans.com> <55CAA8A0.8090408@riseup.net>
Message-ID: <55CB18E2.6090906@digitalbrains.com>

On 12/08/15 04:00, Mirimir wrote:
> It's simplest to just copy the gpg folder. Importing private keys is
> broken by design.

I don't think I agree with either statement. Copying the folder comes
with its own caveats: don't copy random_seed, and you might not want two
identical installations with regard to present private keys and such.

And "broken by design" implies to me that GnuPG doesn't *want* to
support merging secret keys; which would be odd given that the latest
version, GnuPG 2.1, does support it. I also can't remember ever hearing
a reason why it would be bad.

Anyway, the reason I think Bryant is seeing this issue, is that GnuPG
1.4 and 2.0 don't support merging new things into existing secret keys.
I suppose the key already existed on the other system but you added new
subkeys and are trying to import those?

If you can get the up-to-date system (sys1) to export the secret key as
you want it to be on the other computer (sys2), it boils down to:

sys1 $ gpg2 -o sec.gpg --export-secret-keys 1C0B95E5
[copy sec.gpg to sys2]
sys2 $ gpg2 -o sec_backup.gpg --export-secret-keys 1C0B95E5
sys2 $ gpg2 --delete-secret-keys 1C0B95E5
sys2 $ gpg2 --import sec.gpg

Now check if everything is okay on sys2, and if so, you can delete
sec_backup.gpg.

I think this should be safe, since you keep a backup of the local copy
until you are sure the deletion didn't delete unintended stuff.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From mirimir at riseup.net  Wed Aug 12 12:25:31 2015
From: mirimir at riseup.net (Mirimir)
Date: Wed, 12 Aug 2015 04:25:31 -0600
Subject: Inability to export and then import my secret key
In-Reply-To: <55CB18E2.6090906@digitalbrains.com>
References: <55CA8896.4020606@bryantevans.com> <55CAA8A0.8090408@riseup.net>
 <55CB18E2.6090906@digitalbrains.com>
Message-ID: <55CB1F1B.2070500@riseup.net>

On 08/12/2015 03:58 AM, Peter Lebbing wrote:
> On 12/08/15 04:00, Mirimir wrote:
>> It's simplest to just copy the gpg folder. Importing private keys is
>> broken by design.
> 
> I don't think I agree with either statement. Copying the folder comes
> with its own caveats: don't copy random_seed, and you might not want two
> identical installations with regard to present private keys and such.

I got that OP is migrating to new hardware, so I don't see why identical
installations would be problematic.

> And "broken by design" implies to me that GnuPG doesn't *want* to
> support merging secret keys; which would be odd given that the latest
> version, GnuPG 2.1, does support it. I also can't remember ever hearing
> a reason why it would be bad.

Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But
maybe I'm wrong about "broken by design". I vaguely recall reading
something about that a year or two ago.

> Anyway, the reason I think Bryant is seeing this issue, is that GnuPG
> 1.4 and 2.0 don't support merging new things into existing secret keys.
> I suppose the key already existed on the other system but you added new
> subkeys and are trying to import those?
> 
> If you can get the up-to-date system (sys1) to export the secret key as
> you want it to be on the other computer (sys2), it boils down to:
> 
> sys1 $ gpg2 -o sec.gpg --export-secret-keys 1C0B95E5
> [copy sec.gpg to sys2]
> sys2 $ gpg2 -o sec_backup.gpg --export-secret-keys 1C0B95E5
> sys2 $ gpg2 --delete-secret-keys 1C0B95E5
> sys2 $ gpg2 --import sec.gpg
> 
> Now check if everything is okay on sys2, and if so, you can delete
> sec_backup.gpg.
> 
> I think this should be safe, since you keep a backup of the local copy
> until you are sure the deletion didn't delete unintended stuff.

That is for sure a more elegant path :)

> HTH,
> 
> Peter.
> 


From wk at gnupg.org  Wed Aug 12 12:39:47 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Aug 2015 12:39:47 +0200
Subject: Inability to export and then import my secret key
In-Reply-To: <55CB1F1B.2070500@riseup.net> (mirimir@riseup.net's message of
 "Wed, 12 Aug 2015 04:25:31 -0600")
References: <55CA8896.4020606@bryantevans.com> <55CAA8A0.8090408@riseup.net>
 <55CB18E2.6090906@digitalbrains.com> <55CB1F1B.2070500@riseup.net>
Message-ID: <87egj8dc3w.fsf@vigenere.g10code.de>

On Wed, 12 Aug 2015 12:25, mirimir at riseup.net said:

> Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But

That is not correct.  All version support import of secret keys.  What
versions < 2.1 don't allow is merging (updating) a secret key.  This can
be problematic in some cases but most of the time it is sufficient to
delete the secret key first and then import the other version of the
secret key.


Shalom-Salam,

   Werner

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



From peter at digitalbrains.com  Wed Aug 12 13:01:41 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 12 Aug 2015 13:01:41 +0200
Subject: Inability to export and then import my secret key
In-Reply-To: <55CB1F1B.2070500@riseup.net>
References: <55CA8896.4020606@bryantevans.com> <55CAA8A0.8090408@riseup.net>
 <55CB18E2.6090906@digitalbrains.com> <55CB1F1B.2070500@riseup.net>
Message-ID: <55CB2795.4030104@digitalbrains.com>

On 12/08/15 12:25, Mirimir wrote:
> I got that OP is migrating to new hardware, so I don't see why identical
> installations would be problematic.

Right, yes, then a full copy makes a whole lot more sense. I got thrown off by
the fact that the error message seems to indicate the key already existed, and
completely forgot about the introduction at the top of the message :). Such an
exceptionally short attention span seems to indicate an acute lack of caffeine,
I've taken swift action to remedy that!

Anyway, on-topic: don't copy random_seed though. And be aware that some options
in the *.conf files might only be applicable on the old system, and not on the
new one.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From mirimir at riseup.net  Wed Aug 12 13:15:55 2015
From: mirimir at riseup.net (Mirimir)
Date: Wed, 12 Aug 2015 05:15:55 -0600
Subject: Inability to export and then import my secret key
In-Reply-To: <87egj8dc3w.fsf@vigenere.g10code.de>
References: <55CA8896.4020606@bryantevans.com>
 <55CAA8A0.8090408@riseup.net>	<55CB18E2.6090906@digitalbrains.com>
 <55CB1F1B.2070500@riseup.net> <87egj8dc3w.fsf@vigenere.g10code.de>
Message-ID: <55CB2AEB.3040107@riseup.net>

On 08/12/2015 04:39 AM, Werner Koch wrote:
> On Wed, 12 Aug 2015 12:25, mirimir at riseup.net said:
> 
>> Well, GnuPG 1.4 _definitely_ doesn't support importing secret keys. But
> 
> That is not correct.  All version support import of secret keys.  What
> versions < 2.1 don't allow is merging (updating) a secret key.  This can
> be problematic in some cases but most of the time it is sufficient to
> delete the secret key first and then import the other version of the
> secret key.

I clearly recall 1) exporting both my private and public keys from an
old system, 2) importing them into a new system with no existing keys,
and 3) finding that I could decrypt, but not sign.

But I must have done something wrong. Sorry to confuse things.

> Shalom-Salam,
> 
>    Werner
> 


From thomas.jarosch at intra2net.com  Wed Aug 12 13:32:07 2015
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Wed, 12 Aug 2015 13:32:07 +0200
Subject: Card reader success report (openpgp card v2.1)
In-Reply-To: <55C967A4.2080709@fsij.org>
References: <55C52560.2070408@intra2net.com> <55C967A4.2080709@fsij.org>
Message-ID: <8520546.hnTs4LGUCy@storm>

On Tuesday, 11. August 2015 12:10:28 NIIBE Yutaka wrote:
> > Three readers were tested:
> > - Cherry ST-2000
> > - SCM SPR332
> > - Reiner SCT cyberjack go plus
> 
> I think that USB vendor ID and product ID are:
> 
> 	Cherry ST-2000  046a:003e
> 
> Please confirm that and please let me know IDs for those new products
> of SCM SPR332 and Reiner SCT cyberjack go plus.

here are the USB IDs from "lsusb":

0c4b:0504 Reiner SCT Kartensysteme GmbH cyberJack go / go plus
04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader
046a:003e Cherry GmbH SmartTerminal ST-2xxx


Funny that the SPR332 (that's the name on the backside of the reader)
announces itself as a "SPR532".

> That's because I maintain pages:
> 
>     http://wiki.gnupg.org/CardReader/PinpadInput
>     https://wiki.debian.org/GnuPG/CCID_Driver
> 
> ... along with the scdaemon implementation.

that page made me buy those specific readers :)
Chances were good they work fine with the openpgp card
and I really want the pinpad to work.

> Besides, if you can include information of your operating system and
> its version, it helps other users.

I tested it on Fedora 22 that ships gnupg 2.1.5. I manually upgraded
to gnupg 2.1.6 (recompiled the .rpm package with the updated source tarball) 
to get the Cherry ST-2000 up and running. Later on I also tested git HEAD.

Thomas



From fmv1992 at gmail.com  Wed Aug 12 14:24:09 2015
From: fmv1992 at gmail.com (fmv1992 at gmail.com)
Date: Wed, 12 Aug 2015 09:24:09 -0300
Subject: How to deal with a 2nd OpenPGP Summit?
In-Reply-To: <mailman.5656.1439377715.9341.gnupg-users@gnupg.org>
References: <mailman.5656.1439377715.9341.gnupg-users@gnupg.org>
Message-ID: <55CB3AE9.4020802@gmail.com>


> ------------------------------
> 
> Message: 3
> Date: Wed, 12 Aug 2015 07:44:24 +0200
> From: "nico at enigmail.net" <nico at enigmail.net>
> To: GnuPG-Users <Gnupg-users at gnupg.org>
> Subject: How to deal with a 2nd OpenPGP Summit?
> Message-ID: <55CADD38.5030603 at enigmail.net>
> Content-Type: text/plain; charset=utf-8
> 
> Hi all,
> 
> in April 2015 we had a first OpenPGP summit.
> It was a meeting where the technical experts of projects and tools
> dealing with OpenPGP with a focus on email encryption
> met to getting to know each other personally and
> discuss several issues.
> For details, see e.g.
> - https://www.gnupg.org/blog/20150426-openpgp-summit.html
> - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html
> 
> The meting initially was organized by me to bring together
> a few guys/projects working in that area, but it became
> pretty big (about 30 people). This caused some problems,
> because we had a host with limited space (so I finally
> even had to reject some people wanting to attend).
> 
> We also discussed there how to continue.
> On one hand we wanted to have the meeting open so that
> anybody wanting to attend could do that and to give trust
> by transparency.
> On the other hand we want to be able to continue to focus
> on technical issues (having a well signal to noise ratio)
> in a not-too-large group of "experts".
> We didn't find an appropriate way yet to deal with both
> interests.
> 
> Now, I am about to organize a second meeting at the end of this year.
> And I want to take the "wisdom" of this crowd to discuss this issue.
> 
> What I currently have in mind is a meeting open to the public
> but with some limitations (one reason is to focus the work, another
> is simply limited space although I don't know where we can meet
> this time).
> For example:
> - Some priority for those who did attend the first meeting
> - Some priority for "other experts", which didn't join
>   the first meeting
>   (but how do we handle that?)
> - Some limitations that a person plays a "significant role"
>   in the community
> - Some limitation so that a tool/project should normally
>   send only 1 or 2 guys
> 
> The obvious other option is to open the meeting to
> everybody willing to come, which raises a couple of risks
> (simply too many people, too many non-experts or people
>  who want to change the focus, ...).
> 
> So, my questions are:
> =====================
> 
> Is it OK for the public/community, if we meet in a way
> that is limited as describe above (just for practical reasons)?
> 
> Is it OK even if we can't promise full transparency (e.g. by video
> taping sessions)?
> 
> Would it even be OK, if we meet and constraint what is spoken there
> to the Chatham House Rule (see
> https://en.wikipedia.org/wiki/Chatham_House_Rule).
> Some people requested that because
> if anything they say might become public, they might or even
> have to be careful what they say.
> 
> Any general thoughts or proposals about how to deal with this?
> 
> Note that I don't want to have it too complicated.
> I organize this meeting in my free time to bring the issues
> of this community forward.
> And just having too many people is already a problem.
> I need an approach I can handle.
> Or is it better to have no meeting at all instead of a meeting
> with some limitations?
> 
> Best
>  Nico
> 

Dear Nico,

I think you are trying to achieve a compromise that is not possible. If I understood correctly
you are trying to reconcile developers interest with layman's enthusiasm. I myself belong to
the second group.
A good idea would be to organize one event for the developers and another open event so
everyone can join. Then I think everybody would be happy. Note that some overlap between groups
is expected and healthy for the community.

Kind regards,

-- 
Felipe Martins Vieira
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: 9640 F192 63DA D637 6750 AC08 7BCA 19BB 0E69 E45D

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150812/0cadbe06/attachment.sig>

From bryant at bryantevans.com  Wed Aug 12 13:55:01 2015
From: bryant at bryantevans.com (Bryant Evans)
Date: Wed, 12 Aug 2015 06:55:01 -0500
Subject: Inability to export and then import my secret key
In-Reply-To: <55CB18E2.6090906@digitalbrains.com>
References: <55CA8896.4020606@bryantevans.com> <55CAA8A0.8090408@riseup.net>
 <55CB18E2.6090906@digitalbrains.com>
Message-ID: <55CB3415.2060005@bryantevans.com>

Thank you all for your rapid assistance. I think I have the problem
solved but will know for sure in an hour or so when I test it out
thoroughly at the office.


*Bryant Evans*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150812/b3fe2838/attachment.html>

From wk at gnupg.org  Wed Aug 12 15:59:07 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 12 Aug 2015 15:59:07 +0200
Subject: Inability to export and then import my secret key
In-Reply-To: <55CB2795.4030104@digitalbrains.com> (Peter Lebbing's message of
 "Wed, 12 Aug 2015 13:01:41 +0200")
References: <55CA8896.4020606@bryantevans.com> <55CAA8A0.8090408@riseup.net>
 <55CB18E2.6090906@digitalbrains.com> <55CB1F1B.2070500@riseup.net>
 <55CB2795.4030104@digitalbrains.com>
Message-ID: <8737zod2vo.fsf@vigenere.g10code.de>

On Wed, 12 Aug 2015 13:01, peter at digitalbrains.com said:

> Anyway, on-topic: don't copy random_seed though. And be aware that some options

It would not be a catastrophically failure, though.  Here is a comment
from the function reading random_seed:

   Note: Multiple instances of applications sharing the same random
   seed file can be started in parallel, in which case they will read
   out the same pool and then race for updating it (the last update
   overwrites earlier updates).  They will differentiate only by the
   weak entropy that is added in read_seed_file based on the PID and
   clock, and up to 16 bytes of weak random non-blockingly.  The
   consequence is that the output of these different instances is
   correlated to some extent.  In the perfect scenario, the attacker
   can control (or at least guess) the PID and clock of the
   application, and drain the system's entropy pool to reduce the "up
   to 16 bytes" above to 0.  Then the dependencies of the initial
   states of the pools are completely known.  */

The above is for the general case of asking for random, for example
session keys.  When generating a new public key pair gpg (and Libgcrypt)
takes an extra step by making sure that at least 128 bit of fresh
entropy (e.g. from /dev/random) have been inserted into the pool.


Shalom-Salam,

   Werner


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



From robertc at broadcom.com  Wed Aug 12 19:57:20 2015
From: robertc at broadcom.com (Bob (Robert) Cavanaugh)
Date: Wed, 12 Aug 2015 17:57:20 +0000
Subject: How to deal with a 2nd OpenPGP Summit?
In-Reply-To: <55CB3AE9.4020802@gmail.com>
References: <mailman.5656.1439377715.9341.gnupg-users@gnupg.org>
 <55CB3AE9.4020802@gmail.com>
Message-ID: <8F0B09FC6339FA439524099BFCABC11F2D45A7AE@IRVEXCHMB11.corp.ad.broadcom.com>

Hi,
Just a thought: Have a "Star chamber" meeting for the technical group, invitation only. After that have a 1/2 to 1 hour session open to all where the technical people can present their progress and invite comment. This way you have a focused working session with the key people, but maintain community trust by allowing general input.

Thanks,
 
Bob Cavanaugh

> -----Original Message-----
> From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of
> fmv1992 at gmail.com
> Sent: Wednesday, August 12, 2015 5:24 AM
> To: gnupg-users at gnupg.org; nico at enigmail.net
> Subject: Re: How to deal with a 2nd OpenPGP Summit?
> 
> 
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 12 Aug 2015 07:44:24 +0200
> > From: "nico at enigmail.net" <nico at enigmail.net>
> > To: GnuPG-Users <Gnupg-users at gnupg.org>
> > Subject: How to deal with a 2nd OpenPGP Summit?
> > Message-ID: <55CADD38.5030603 at enigmail.net>
> > Content-Type: text/plain; charset=utf-8
> >
> > Hi all,
> >
> > in April 2015 we had a first OpenPGP summit.
> > It was a meeting where the technical experts of projects and tools
> > dealing with OpenPGP with a focus on email encryption met to getting
> > to know each other personally and discuss several issues.
> > For details, see e.g.
> > - https://www.gnupg.org/blog/20150426-openpgp-summit.html
> > - https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html
> >
> > The meting initially was organized by me to bring together a few
> > guys/projects working in that area, but it became pretty big (about 30
> > people). This caused some problems, because we had a host with limited
> > space (so I finally even had to reject some people wanting to attend).
> >
> > We also discussed there how to continue.
> > On one hand we wanted to have the meeting open so that anybody
> wanting
> > to attend could do that and to give trust by transparency.
> > On the other hand we want to be able to continue to focus on technical
> > issues (having a well signal to noise ratio) in a not-too-large group
> > of "experts".
> > We didn't find an appropriate way yet to deal with both interests.
> >
> > Now, I am about to organize a second meeting at the end of this year.
> > And I want to take the "wisdom" of this crowd to discuss this issue.
> >
> > What I currently have in mind is a meeting open to the public but with
> > some limitations (one reason is to focus the work, another is simply
> > limited space although I don't know where we can meet this time).
> > For example:
> > - Some priority for those who did attend the first meeting
> > - Some priority for "other experts", which didn't join
> >   the first meeting
> >   (but how do we handle that?)
> > - Some limitations that a person plays a "significant role"
> >   in the community
> > - Some limitation so that a tool/project should normally
> >   send only 1 or 2 guys
> >
> > The obvious other option is to open the meeting to everybody willing
> > to come, which raises a couple of risks (simply too many people, too
> > many non-experts or people  who want to change the focus, ...).
> >
> > So, my questions are:
> > =====================
> >
> > Is it OK for the public/community, if we meet in a way that is limited
> > as describe above (just for practical reasons)?
> >
> > Is it OK even if we can't promise full transparency (e.g. by video
> > taping sessions)?
> >
> > Would it even be OK, if we meet and constraint what is spoken there to
> > the Chatham House Rule (see
> > https://en.wikipedia.org/wiki/Chatham_House_Rule).
> > Some people requested that because
> > if anything they say might become public, they might or even have to
> > be careful what they say.
> >
> > Any general thoughts or proposals about how to deal with this?
> >
> > Note that I don't want to have it too complicated.
> > I organize this meeting in my free time to bring the issues of this
> > community forward.
> > And just having too many people is already a problem.
> > I need an approach I can handle.
> > Or is it better to have no meeting at all instead of a meeting with
> > some limitations?
> >
> > Best
> >  Nico
> >
> 
> Dear Nico,
> 
> I think you are trying to achieve a compromise that is not possible. If I
> understood correctly you are trying to reconcile developers interest with
> layman's enthusiasm. I myself belong to the second group.
> A good idea would be to organize one event for the developers and another
> open event so everyone can join. Then I think everybody would be happy.
> Note that some overlap between groups is expected and healthy for the
> community.
> 
> Kind regards,
> 
> --
> Felipe Martins Vieira
> Public PGP key: http://pgp.surfnet.nl
> Key Fingerprint: 9640 F192 63DA D637 6750 AC08 7BCA 19BB 0E69 E45D



From aslam at mythicflow.com  Wed Aug 12 19:57:27 2015
From: aslam at mythicflow.com (aslam karachiwala)
Date: Wed, 12 Aug 2015 13:57:27 -0400
Subject: Temporary lock files?
Message-ID: <55CB8907.2040608@mythicflow.com>

gpg (GnuPG) 2.0.22

My ~/.gnupg directory is getting filled with files named like
".#lk0x7feb6a637540.<hostname>.26914".

Shouldn't these get deleted automagically?

-- 
aslam
a k'wala's SciTech Daily <http://paper.li/akwala/1306116714>

PGP key <http://is.gd/aslampgpmit> fingerprint: 736C D83E 32DB A2FD 0208
9113 0FC8 BA7D FECF 84FB

/Join World Community Grid
<https://www.worldcommunitygrid.org/reg/viewRegister.do?recruiterId=877175>.
Help power cutting-edge research in health, poverty and sustainability./

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150812/e116cc46/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150812/e116cc46/attachment-0001.sig>

From me at viccuad.me  Wed Aug 12 20:55:10 2015
From: me at viccuad.me (=?UTF-8?B?VsOtY3RvciBDdWFkcmFkbyBKdWFu?=)
Date: Wed, 12 Aug 2015 20:55:10 +0200
Subject: Possible bug when using smartcards and gpg-agent2.0 as the ssh-agent
Message-ID: <55CB968E.90009@viccuad.me>

Hello,

I'm using gpg-agent 2.0.28 (Debian Stretch) as the ssh agent, with
"enable-ssh-suport".
I have disabled the Gnome Keyring, and I'm only using gpg-agent. I have
a properly configured Yubikey Neo with an auth subkey, and the Yubikey
is correctly configured and in use. I have a clean ~/.gnupg/sshcontrol
file, and no ~/.ssh directory at all.

At first instance everything works fine, 'ssh-add -l' and 'ssh-add -L'
show my key when I have my Yubikey connected: (I'm redacting the key and
the card number)

$ ssh-add -l
2048 **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
cardno:00060******* (RSA)

Yet when I try to use it to connect to the server by ssh I get a GUI
popup that says:

"take out the current card and insert the one with the serial number:
D*************0000060*******0000"
(In my case, in spanish, "Retire tarjeta actual e inserte la que
tiene n?mero de serie: ")

The serial number on ssh-add -L is the same "card-no" that appears next
to the auth subkey in gpg --card-status, which is 12 chars long.

The gpg-agent pop-up serial numbers seems to correspond to the
"Application ID" displayed in gpg --card-status, which is 32 chars long.

This seems like a bug. Am I missing something? Should I post this on
gnupg-devel?

Thanks in advance,

-- 
V?ctor

--
E-Mail: <me at viccuad.me>, OpenPGP-Key-ID: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150812/62e1c76a/attachment.sig>

From peter at digitalbrains.com  Wed Aug 12 21:48:11 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Wed, 12 Aug 2015 21:48:11 +0200
Subject: Possible bug when using smartcards and gpg-agent2.0 as the
 ssh-agent
In-Reply-To: <55CB968E.90009@viccuad.me>
References: <55CB968E.90009@viccuad.me>
Message-ID: <55CBA2FB.4000804@digitalbrains.com>

On 12/08/15 20:55, V?ctor Cuadrado Juan wrote:
> This seems like a bug.

The serial number is part of the application ID, it's not a bug. The one is
more verbose than the other. The AID ends in four zeroes, but the part before
that is the serial number and manufacturer ID.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From dongsheng.song at gmail.com  Thu Aug 13 07:35:40 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Thu, 13 Aug 2015 13:35:40 +0800
Subject: [Announce] GnuPG 2.1.7 released
In-Reply-To: <87egj9g7s5.fsf@vigenere.g10code.de>
References: <87egj9g7s5.fsf@vigenere.g10code.de>
Message-ID: <CAE8XmWq3O-PkfPGHXsAdiFzCD9gOMB8HnSbHNNg_rMJcYWGUyw@mail.gmail.com>

On Tue, Aug 11, 2015 at 11:32 PM, Werner Koch <wk at gnupg.org> wrote:
> Hello!
>
> The GnuPG Project is pleased to announce the availability of a new
> release of GnuPG modern: Version 2.1.7.
>

Thanks for your great work!

Any news on pinentry ? pinentry-0.9.4 (pinentry-w32.exe) works good on
windows, but both pinentry-0.9.5 and pinentry-0.9.5-13-g1532bf3 broken
on 32bit or 64 bit Windows.

C:\>gpg-connect-agent
> GET_CONFIRMATION Hello
ERR 67108949 No pinentry <GPG Agent>

Regards,
Cauchy


From wk at gnupg.org  Thu Aug 13 17:03:22 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Aug 2015 17:03:22 +0200
Subject: [Announce] GnuPG 2.1.7 released
In-Reply-To: <CAE8XmWq3O-PkfPGHXsAdiFzCD9gOMB8HnSbHNNg_rMJcYWGUyw@mail.gmail.com>
 (Dongsheng Song's message of "Thu, 13 Aug 2015 13:35:40 +0800")
References: <87egj9g7s5.fsf@vigenere.g10code.de>
 <CAE8XmWq3O-PkfPGHXsAdiFzCD9gOMB8HnSbHNNg_rMJcYWGUyw@mail.gmail.com>
Message-ID: <87h9o3b58l.fsf@vigenere.g10code.de>

On Thu, 13 Aug 2015 07:35, dongsheng.song at gmail.com said:

> Any news on pinentry ? pinentry-0.9.4 (pinentry-w32.exe) works good on
> windows, but both pinentry-0.9.5 and pinentry-0.9.5-13-g1532bf3 broken
> on 32bit or 64 bit Windows.

Right, I only noticed while testing the installer and had to go back to
0.9.4 for the released installer.  The native windows installer did not
change and thus there is no real drawback using 0.9.4.  You are anyway
better off using a Qt or Gtk+ based Pinentry as delivered with Gpg4win -
GnuPG 2.1.7 will prefer a Pinentry installed by Gpg4win


>
> C:\>gpg-connect-agent
>> GET_CONFIRMATION Hello
> ERR 67108949 No pinentry <GPG Agent>
>
> Regards,
> Cauchy
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>

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



From dongsheng.song at gmail.com  Fri Aug 14 05:49:28 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Fri, 14 Aug 2015 11:49:28 +0800
Subject: [Announce] GnuPG 2.1.7 released
In-Reply-To: <87h9o3b58l.fsf@vigenere.g10code.de>
References: <87egj9g7s5.fsf@vigenere.g10code.de>
 <CAE8XmWq3O-PkfPGHXsAdiFzCD9gOMB8HnSbHNNg_rMJcYWGUyw@mail.gmail.com>
 <87h9o3b58l.fsf@vigenere.g10code.de>
Message-ID: <CAE8XmWoDdBa43Yf_CB3jAzv5N+ZDS=3msDpwsRcHJJcqKcgOLw@mail.gmail.com>

On Thu, Aug 13, 2015 at 11:03 PM, Werner Koch <wk at gnupg.org> wrote:
> On Thu, 13 Aug 2015 07:35, dongsheng.song at gmail.com said:
>
>> Any news on pinentry ? pinentry-0.9.4 (pinentry-w32.exe) works good on
>> windows, but both pinentry-0.9.5 and pinentry-0.9.5-13-g1532bf3 broken
>> on 32bit or 64 bit Windows.
>
> Right, I only noticed while testing the installer and had to go back to
> 0.9.4 for the released installer.  The native windows installer did not
> change and thus there is no real drawback using 0.9.4.  You are anyway
> better off using a Qt or Gtk+ based Pinentry as delivered with Gpg4win -
> GnuPG 2.1.7 will prefer a Pinentry installed by Gpg4win
>

Thanks, I like gpg4win-vanilla, because Qt or Gtk+ is too fat for me.


From marcel at hsdev.com  Fri Aug 14 09:05:38 2015
From: marcel at hsdev.com (Marcel van der Boom)
Date: Fri, 14 Aug 2015 09:05:38 +0200
Subject: gpg-agent: error accessing card: Conflicting use
In-Reply-To: <05532bd82a9b5d55402d32215487b0a7@otpme.org>
References: <ad006b8edb17b8c94a8f33cc7efa4dde@otpme.org>
 <05532bd82a9b5d55402d32215487b0a7@otpme.org>
Message-ID: <20150814090538.65079202@hsdev.com>


> [the2nd at otpme.org:] > nobody else with this problem?


Yes, I have this problem with some regularity. I have been restarting
gpg-agent so far to resolve it and haven't investigated further.

I'm not sure exactly when this started, may have been around a 2.1
upgrade.

marcel

-- 
Marcel van der Boom ? marcel at hsdev.com
 ? +31?168?468?824        
 ? xmpp:marcel at hsdev.com | http://telegram.me/marcel
 ? http://hsdev.com
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150814/62dd4601/attachment.sig>

From dongsheng.song at gmail.com  Fri Aug 14 10:15:57 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Fri, 14 Aug 2015 16:15:57 +0800
Subject: signing failed with master key when I have stronger subkeys
Message-ID: <55CDA3BD.9090906@gmail.com>

Hi,

Here is my keyring status after I removed the secret key of these
stronger subkeys:

    sec   rsa2048/46D397FF 2008-02-02
    ssb   rsa2048/7547A8A9 2008-02-02
    ssb#  brainpoolP512r1/DD1C5659 2015-06-24
    ssb#  brainpoolP512r1/24BEAC25 2015-06-24
    ssb#  rsa4096/F7BC1BF1 2015-06-24

Then I can not signing anymore even when I use --default-key or
--local-user to specify 46D397FF or 7547A8A9:

    gpg: signing failed: No secret key

After I delete these stronger subkeys completely:

    sec   rsa2048/46D397FF 2008-02-02
    ssb   rsa2048/7547A8A9 2008-02-02

Then signing action succeeded. Bugs, features, or misused ?

Regards,
Dongsheng



From wk at gnupg.org  Fri Aug 14 12:34:41 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 14 Aug 2015 12:34:41 +0200
Subject: signing failed with master key when I have stronger subkeys
In-Reply-To: <55CDA3BD.9090906@gmail.com> (Dongsheng Song's message of "Fri,
 14 Aug 2015 16:15:57 +0800")
References: <55CDA3BD.9090906@gmail.com>
Message-ID: <87tws29n0e.fsf@vigenere.g10code.de>

On Fri, 14 Aug 2015 10:15, dongsheng.song at gmail.com said:

>     sec   rsa2048/46D397FF 2008-02-02
>     ssb   rsa2048/7547A8A9 2008-02-02
>     ssb#  brainpoolP512r1/DD1C5659 2015-06-24
>     ssb#  brainpoolP512r1/24BEAC25 2015-06-24
>     ssb#  rsa4096/F7BC1BF1 2015-06-24
>
> Then I can not signing anymore even when I use --default-key or
> --local-user to specify 46D397FF or 7547A8A9:
>
>     gpg: signing failed: No secret key

gpg uses the lates signing capable subkey.  However you removed the
secret part of that key (one of the brainpool keeys I assume) and thus
gpg can't do that.  The '#' indicates that the secret part is somewhere
available.

What about using 

  -u 7547A8A9\!

(note the exclamation mark) to force the use of that subkey?


Salam-Shalom,

   Werner

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



From dongsheng.song at gmail.com  Fri Aug 14 14:45:44 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Fri, 14 Aug 2015 20:45:44 +0800
Subject: signing failed with master key when I have stronger subkeys
In-Reply-To: <87tws29n0e.fsf@vigenere.g10code.de>
References: <55CDA3BD.9090906@gmail.com> <87tws29n0e.fsf@vigenere.g10code.de>
Message-ID: <CAE8XmWrsSQNpuNcci9cXDvSs1r74mjZaA2i7mvGDA6Ep_Ufkeg@mail.gmail.com>

On Fri, Aug 14, 2015 at 6:34 PM, Werner Koch <wk at gnupg.org> wrote:
> On Fri, 14 Aug 2015 10:15, dongsheng.song at gmail.com said:
>
>>     sec   rsa2048/46D397FF 2008-02-02
>>     ssb   rsa2048/7547A8A9 2008-02-02
>>     ssb#  brainpoolP512r1/DD1C5659 2015-06-24
>>     ssb#  brainpoolP512r1/24BEAC25 2015-06-24
>>     ssb#  rsa4096/F7BC1BF1 2015-06-24
>>
>> Then I can not signing anymore even when I use --default-key or
>> --local-user to specify 46D397FF or 7547A8A9:
>>
>>     gpg: signing failed: No secret key
>
> gpg uses the lates signing capable subkey.  However you removed the
> secret part of that key (one of the brainpool keeys I assume) and thus
> gpg can't do that.  The '#' indicates that the secret part is somewhere
> available.
>
> What about using
>
>   -u 7547A8A9\!
>
> (note the exclamation mark) to force the use of that subkey?
>

No good news.

D:\>gpg  -u "7547A8A9\!" --clearsign relay.txt
gpg: skipped "7547A8A9\!": No secret key
gpg: relay.txt: clearsign failed: No secret key

D:\>gpg  -u "7547A8A9!" --clearsign relay.txt
gpg: skipped "7547A8A9!": Unusable secret key
gpg: relay.txt: clearsign failed: Unusable secret key

D:\>gpg -K
----------------------------------------------------
sec   rsa2048/46D397FF 2008-02-02
ssb   rsa2048/7547A8A9 2008-02-02
ssb#  brainpoolP512r1/DD1C5659 2015-06-24
ssb#  brainpoolP512r1/24BEAC25 2015-06-24
ssb#  rsa4096/F7BC1BF1 2015-06-24


From peter at digitalbrains.com  Fri Aug 14 16:06:56 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 14 Aug 2015 16:06:56 +0200
Subject: signing failed with master key when I have stronger subkeys
In-Reply-To: <CAE8XmWrsSQNpuNcci9cXDvSs1r74mjZaA2i7mvGDA6Ep_Ufkeg@mail.gmail.com>
References: <55CDA3BD.9090906@gmail.com> <87tws29n0e.fsf@vigenere.g10code.de>
 <CAE8XmWrsSQNpuNcci9cXDvSs1r74mjZaA2i7mvGDA6Ep_Ufkeg@mail.gmail.com>
Message-ID: <55CDF600.8090209@digitalbrains.com>

On 14/08/15 14:45, Dongsheng Song wrote:
> D:\>gpg  -u "7547A8A9\!" --clearsign relay.txt
> gpg: skipped "7547A8A9\!": No secret key
> gpg: relay.txt: clearsign failed: No secret key

I think the escape of the exclamation mark might not be correct for Windows
shell usage.

> D:\>gpg  -u "7547A8A9!" --clearsign relay.txt
> gpg: skipped "7547A8A9!": Unusable secret key
> gpg: relay.txt: clearsign failed: Unusable secret key

This would probably be the correct form for Windows. But: is that subkey
actually encryption capable or is it an encryption subkey?

What about

D:\>gpg -u "46D397FF!" --clearsign relay.txt

?

You can see what your (sub)keys are capable of as follows:

D:\>gpg --edit-key 46D397FF
[...]
pub [...] usage: SC
sub [...] usage: S
sub [...] usage: E

The primary key can sign and certify, the first subkey can sign and the second
can encrypt.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From dongsheng.song at gmail.com  Fri Aug 14 16:36:33 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Fri, 14 Aug 2015 22:36:33 +0800
Subject: signing failed with master key when I have stronger subkeys
In-Reply-To: <55CDF600.8090209@digitalbrains.com>
References: <55CDA3BD.9090906@gmail.com> <87tws29n0e.fsf@vigenere.g10code.de>
 <CAE8XmWrsSQNpuNcci9cXDvSs1r74mjZaA2i7mvGDA6Ep_Ufkeg@mail.gmail.com>
 <55CDF600.8090209@digitalbrains.com>
Message-ID: <CAE8XmWp2R+UQtnFaeAPsw6OSvc-V2Hw=HpGAkFStoWU046fYpg@mail.gmail.com>

On Fri, Aug 14, 2015 at 10:06 PM, Peter Lebbing <peter at digitalbrains.com> wrote:
>> D:\>gpg  -u "7547A8A9!" --clearsign relay.txt
>> gpg: skipped "7547A8A9!": Unusable secret key
>> gpg: relay.txt: clearsign failed: Unusable secret key
>
> This would probably be the correct form for Windows. But: is that subkey
> actually encryption capable or is it an encryption subkey?
>
> What about
>
> D:\>gpg -u "46D397FF!" --clearsign relay.txt
>
> ?
>

Thank you, it works.


From aixtools at gmail.com  Fri Aug 14 16:45:57 2015
From: aixtools at gmail.com (Michael Felt)
Date: Fri, 14 Aug 2015 16:45:57 +0200
Subject: [Announce] GnuPG 2.1.7 released
In-Reply-To: <CAE8XmWoDdBa43Yf_CB3jAzv5N+ZDS=3msDpwsRcHJJcqKcgOLw@mail.gmail.com>
References: <87egj9g7s5.fsf@vigenere.g10code.de>
 <CAE8XmWq3O-PkfPGHXsAdiFzCD9gOMB8HnSbHNNg_rMJcYWGUyw@mail.gmail.com>
 <87h9o3b58l.fsf@vigenere.g10code.de>
 <CAE8XmWoDdBa43Yf_CB3jAzv5N+ZDS=3msDpwsRcHJJcqKcgOLw@mail.gmail.com>
Message-ID: <CANvxniWLQKjHd8xs8X47fs==u3jicph2ahTCdBmJwGyiR_M8ZQ@mail.gmail.com>

gpg4win - thinking slowly - does this mean there is a skeleton, or better
project, to minimize what is needed from gnome to run the "modern" versions
of gnupg.

I do not want to install much - actually nothing - of a X11 "server"
environment on AIX. I prefer to work with X things as applications my
DISPLAY "forwarded" over an ssh tunnel to my remote system.

So, maybe I would be happy with something like this for AIX - better is
that you reply - not needed with X server at remote side.

On Fri, Aug 14, 2015 at 5:49 AM, Dongsheng Song <dongsheng.song at gmail.com>
wrote:

> On Thu, Aug 13, 2015 at 11:03 PM, Werner Koch <wk at gnupg.org> wrote:
> > On Thu, 13 Aug 2015 07:35, dongsheng.song at gmail.com said:
> >
> >> Any news on pinentry ? pinentry-0.9.4 (pinentry-w32.exe) works good on
> >> windows, but both pinentry-0.9.5 and pinentry-0.9.5-13-g1532bf3 broken
> >> on 32bit or 64 bit Windows.
> >
> > Right, I only noticed while testing the installer and had to go back to
> > 0.9.4 for the released installer.  The native windows installer did not
> > change and thus there is no real drawback using 0.9.4.  You are anyway
> > better off using a Qt or Gtk+ based Pinentry as delivered with Gpg4win -
> > GnuPG 2.1.7 will prefer a Pinentry installed by Gpg4win
> >
>
> Thanks, I like gpg4win-vanilla, because Qt or Gtk+ is too fat for me.
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150814/5a6a1e37/attachment.html>

From oeko-kai at web.de  Fri Aug 14 22:44:07 2015
From: oeko-kai at web.de (Kai Lemke)
Date: Fri, 14 Aug 2015 22:44:07 +0200
Subject: gpg-agent as default ssh-agent on linux macines
Message-ID: <55CE5317.2040807@web.de>

Hallo,

gpg v2.1 claims to be easy to use for SSH-authentification, too.
For me that's really great, because you can have on public key with
subkeys for all purposes, but I tried some configs I found at blogs etc
vainly.
I would be very happy about an how-to use gpg v2.1 as default ssh client.

Sincerly,

Kai


From dgouttegattat at incenp.org  Sat Aug 15 08:50:53 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sat, 15 Aug 2015 08:50:53 +0200
Subject: gpg-agent as default ssh-agent on linux macines
In-Reply-To: <55CE5317.2040807@web.de>
References: <55CE5317.2040807@web.de>
Message-ID: <55CEE14D.1080201@incenp.org>

On 08/14/2015 10:44 PM, Kai Lemke wrote:
> gpg v2.1 claims to be easy to use for SSH-authentification, too.
> For me that's really great, because you can have on public key with
> subkeys for all purposes, but I tried some configs I found at blogs etc
> vainly.
> I would be very happy about an how-to use gpg v2.1 as default ssh client.

I wrote a short blog post on that topic a few months ago:

   http://www.incenp.org/notes/2015/gnupg-for-ssh-authentication.html

If it still does not work, please provide more details about what you 
tried and what happened.

Hope that helps,

Damien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150815/bd39b9d7/attachment.sig>

From melvincarvalho at gmail.com  Sat Aug 15 15:35:57 2015
From: melvincarvalho at gmail.com (Melvin Carvalho)
Date: Sat, 15 Aug 2015 15:35:57 +0200
Subject: gpg-agent as default ssh-agent on linux macines
In-Reply-To: <55CEE14D.1080201@incenp.org>
References: <55CE5317.2040807@web.de>
	<55CEE14D.1080201@incenp.org>
Message-ID: <CAKaEYhLnqtf7eYkYwpwRxJFYA0wMw6n2TjcFrLSa8u3btgP91w@mail.gmail.com>

On 15 August 2015 at 08:50, Damien Goutte-Gattat <dgouttegattat at incenp.org>
wrote:

> On 08/14/2015 10:44 PM, Kai Lemke wrote:
>
>> gpg v2.1 claims to be easy to use for SSH-authentification, too.
>> For me that's really great, because you can have on public key with
>> subkeys for all purposes, but I tried some configs I found at blogs etc
>> vainly.
>> I would be very happy about an how-to use gpg v2.1 as default ssh client.
>>
>
> I wrote a short blog post on that topic a few months ago:
>
>   http://www.incenp.org/notes/2015/gnupg-for-ssh-authentication.html


Fascinating, thanks!

Is it possible to go the other way?  openssh -> gpg

I recently wrote an openssh -> X.509 converter in nodejs

https://github.com/gitpay/util/blob/master/opensshToX509.js

I wonder if I could add openssh -> GPG?


>
>
> If it still does not work, please provide more details about what you
> tried and what happened.
>
> Hope that helps,
>
> Damien
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150815/99badf2f/attachment.html>

From dgouttegattat at incenp.org  Sat Aug 15 17:25:15 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Sat, 15 Aug 2015 17:25:15 +0200
Subject: gpg-agent as default ssh-agent on linux macines
In-Reply-To: <CAKaEYhLnqtf7eYkYwpwRxJFYA0wMw6n2TjcFrLSa8u3btgP91w@mail.gmail.com>
References: <55CE5317.2040807@web.de> <55CEE14D.1080201@incenp.org>
 <CAKaEYhLnqtf7eYkYwpwRxJFYA0wMw6n2TjcFrLSa8u3btgP91w@mail.gmail.com>
Message-ID: <55CF59DB.2040703@incenp.org>

On 08/15/2015 03:35 PM, Melvin Carvalho wrote:
> Is it possible to go the other way?  openssh -> gpg
>
> I recently wrote an openssh -> X.509 converter in nodejs
>
> https://github.com/gitpay/util/blob/master/opensshToX509.js
>
> I wonder if I could add openssh -> GPG?

It is certainly possible.

You can have a look at the pem2openpgp tool (provided by the 
Monkeysphere project [1]), which converts a RSA key in PEM format into 
an OpenPGP key.


[1] http://web.monkeysphere.info/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150815/a040f184/attachment-0001.sig>

From melvincarvalho at gmail.com  Sat Aug 15 21:51:01 2015
From: melvincarvalho at gmail.com (Melvin Carvalho)
Date: Sat, 15 Aug 2015 21:51:01 +0200
Subject: gpg-agent as default ssh-agent on linux macines
In-Reply-To: <55CF59DB.2040703@incenp.org>
References: <55CE5317.2040807@web.de> <55CEE14D.1080201@incenp.org>
 <CAKaEYhLnqtf7eYkYwpwRxJFYA0wMw6n2TjcFrLSa8u3btgP91w@mail.gmail.com>
 <55CF59DB.2040703@incenp.org>
Message-ID: <CAKaEYh+c-TyEzjT9NV9VjHotFfZ+WUz1fpywtKqSpwgjx7G-Wg@mail.gmail.com>

On 15 August 2015 at 17:25, Damien Goutte-Gattat <dgouttegattat at incenp.org>
wrote:

> On 08/15/2015 03:35 PM, Melvin Carvalho wrote:
>
>> Is it possible to go the other way?  openssh -> gpg
>>
>> I recently wrote an openssh -> X.509 converter in nodejs
>>
>> https://github.com/gitpay/util/blob/master/opensshToX509.js
>>
>> I wonder if I could add openssh -> GPG?
>>
>
> It is certainly possible.
>
> You can have a look at the pem2openpgp tool (provided by the Monkeysphere
> project [1]), which converts a RSA key in PEM format into an OpenPGP key.
>
>
> [1] http://web.monkeysphere.info/
>
>
This is excellent, thanks!

Do you know if there is any implementation of this in javascript?  Or if it
could be ported to JS -- I could give it a try, if I had some rough
instructions ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150815/92d9841a/attachment.html>

From admin at zwiebelfreund.de  Sun Aug 16 10:10:28 2015
From: admin at zwiebelfreund.de (Stefan Claas)
Date: Sun, 16 Aug 2015 10:10:28 +0200
Subject: protecting pub-keys from unwanted signatures
Message-ID: <20150816081028.GA26761@zwiebelfreund.de>

Hello Werner and all,

after seeing Facebook's public key a couple of days ago,
i was wondering if it's possible to enhance GnuPG in a
future version, so that it no longer allows someone to
sign a public key without approval of the owner.

As an example: Bob likes to sign Alice's pub key and
issues the sign key command, but instead of signing
the key directly GnuPG would create a "Signature
Reguest Certificate" which Alice reads and verifies
in GnuPG, thus allowing her to add Bob's signature
to her key. This mechanism, or a similar one would 
protect Alice's key from unwanted signatures.

Best regards
Stefan



From 2014-667rhzu3dc-lists-groups at riseup.net  Sun Aug 16 13:15:03 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sun, 16 Aug 2015 12:15:03 +0100
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816081028.GA26761@zwiebelfreund.de>
References: <20150816081028.GA26761@zwiebelfreund.de>
Message-ID: <1753867983.20150816121503@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Sunday 16 August 2015 at 9:10:28 AM, in
<mid:20150816081028.GA26761 at zwiebelfreund.de>, Stefan Claas wrote:



> after seeing Facebook's public key a couple of days
> ago, i was wondering if it's possible to enhance GnuPG
> in a future version, so that it no longer allows
> someone to sign a public key without approval of the
> owner.

If GnuPG were modified in this way the key could still be signed
using an old GnuPG version, or any other OpenPGP application.

I guess a modification would be possible that allowed a GnuPG user to
sign acceptance or rejection over a third-party signature, but I'm not
convinced there would be any point. Firstly, would such acceptance or
rejection be dropped by the keyservers? Secondly, any signature on a
key is only meaningful if you recognise (or have a trust path to) the
key that made that signature; the rest is meaningless background noise
that disappears if you use "keyserver-options import-clean" in your
gpg.conf or on your command line. (My local copy of Facebook's public
key has only self-signatures, and refreshing from a keyserver does not
change this).



> As an example: Bob likes to sign Alice's pub key and
> issues the sign key command, but instead of signing the
> key directly GnuPG would create a "Signature Reguest
> Certificate" which Alice reads and verifies in GnuPG,
> thus allowing her to add Bob's signature to her key.
> This mechanism, or a similar one would  protect Alice's
> key from unwanted signatures.

Or Alice could simply host a "clean" copy of her key without the
unwanted signatures on her website, Biglumber, an email
auto-responder, etc.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

The One with The Answer is seldom asked The Question
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJV0HDFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwP50H/1rj+rZoRbM7EIFht89O+G8t
4UdpvX3f8V73bJYW7CW288++QFqsLrJse2IsP6exK44ZUorR08MMSdn+5DSgiSGo
J5W3HgMQxM/jQZ25bDp1jLExfEtgKfGpXWPONPLP/CVe+iZpu44cTbsjA5dfYXwx
TSuyHD9t4auRzShHIDunPJWNqdt/WA5XGoGYZGIsICZG5lfHUBHUyrNXv3m/q/d0
DjmelfMUpecNZ3coRhizP33tpet3mCSN1GEie9CPEWzk8aig1j5rhd/eBCVsvq0Y
QVW7xJl+X7Esc0s8MeNnxbHshDco3TffRnSJFkSlKu992I61jg/O5e9d9IcS7FqI
vgQBFgoAZgUCVdBwz18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KBkAQDbT5Wo/zN+jhL5sNYRth+4QAm6
D7gUb7mAdvkpUqlUuAEA6D6968t1Nm6iTWgVyxcVDaXO1sH4ZkWdPy2FhTI25Ak=
=LenD
-----END PGP SIGNATURE-----



From admin at zwiebelfreund.de  Sun Aug 16 14:01:48 2015
From: admin at zwiebelfreund.de (Stefan Claas)
Date: Sun, 16 Aug 2015 14:01:48 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <1753867983.20150816121503@my_localhost>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <1753867983.20150816121503@my_localhost>
Message-ID: <20150816120148.GA31453@zwiebelfreund.de>

On Sun, Aug 16, 2015 at 12:15:03PM +0100, MFPA wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Hi
> 
> 
> On Sunday 16 August 2015 at 9:10:28 AM, in
> <mid:20150816081028.GA26761 at zwiebelfreund.de>, Stefan Claas wrote:
> 
> 
> 
> > after seeing Facebook's public key a couple of days
> > ago, i was wondering if it's possible to enhance GnuPG
> > in a future version, so that it no longer allows
> > someone to sign a public key without approval of the
> > owner.
> 
> If GnuPG were modified in this way the key could still be signed
> using an old GnuPG version, or any other OpenPGP application.
> 
> I guess a modification would be possible that allowed a GnuPG user to
> sign acceptance or rejection over a third-party signature, but I'm not
> convinced there would be any point. Firstly, would such acceptance or
> rejection be dropped by the keyservers? Secondly, any signature on a
> key is only meaningful if you recognise (or have a trust path to) the
> key that made that signature; the rest is meaningless background noise
> that disappears if you use "keyserver-options import-clean" in your
> gpg.conf or on your command line. (My local copy of Facebook's public
> key has only self-signatures, and refreshing from a keyserver does not
> change this).
> 
> 
> 
> > As an example: Bob likes to sign Alice's pub key and
> > issues the sign key command, but instead of signing the
> > key directly GnuPG would create a "Signature Reguest
> > Certificate" which Alice reads and verifies in GnuPG,
> > thus allowing her to add Bob's signature to her key.
> > This mechanism, or a similar one would  protect Alice's
> > key from unwanted signatures.
> 
> Or Alice could simply host a "clean" copy of her key without the
> unwanted signatures on her website, Biglumber, an email
> auto-responder, etc.
> 
> 
> - --
> Best regards
> 
> MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>
> 
> The One with The Answer is seldom asked The Question
> -----BEGIN PGP SIGNATURE-----
> 
> iQF8BAEBCgBmBQJV0HDFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
> QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwP50H/1rj+rZoRbM7EIFht89O+G8t
> 4UdpvX3f8V73bJYW7CW288++QFqsLrJse2IsP6exK44ZUorR08MMSdn+5DSgiSGo
> J5W3HgMQxM/jQZ25bDp1jLExfEtgKfGpXWPONPLP/CVe+iZpu44cTbsjA5dfYXwx
> TSuyHD9t4auRzShHIDunPJWNqdt/WA5XGoGYZGIsICZG5lfHUBHUyrNXv3m/q/d0
> DjmelfMUpecNZ3coRhizP33tpet3mCSN1GEie9CPEWzk8aig1j5rhd/eBCVsvq0Y
> QVW7xJl+X7Esc0s8MeNnxbHshDco3TffRnSJFkSlKu992I61jg/O5e9d9IcS7FqI
> vgQBFgoAZgUCVdBwz18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
> cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
> MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45KBkAQDbT5Wo/zN+jhL5sNYRth+4QAm6
> D7gUb7mAdvkpUqlUuAEA6D6968t1Nm6iTWgVyxcVDaXO1sH4ZkWdPy2FhTI25Ak=
> =LenD
> -----END PGP SIGNATURE-----

Thanks for your reply, all valid points.
However if my proposal would result in an enhanced OpenPGP file
format older versions could not sign such keys, while a never version
could read older or leagcy file formats. Same as with other software
applications. Current key servers would not be able to read/store
such enhanced format and needed to be updated too.

Regards
Stefan
 


From lion at lion.leolix.org  Sun Aug 16 13:18:20 2015
From: lion at lion.leolix.org (Philipp Schafft)
Date: Sun, 16 Aug 2015 11:18:20 +0000
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816081028.GA26761@zwiebelfreund.de>
References: <20150816081028.GA26761@zwiebelfreund.de>
Message-ID: <20150816111828.0BB8D12BB3@grassland.keep-cool.org>

reflum,

On Sun, 2015-08-16 at 10:10 +0200, Stefan Claas wrote:
> Hello Werner and all,
> 
> after seeing Facebook's public key a couple of days ago,
> i was wondering if it's possible to enhance GnuPG in a
> future version, so that it no longer allows someone to
> sign a public key without approval of the owner.

Maybe you can explain your use case a bit.
Think about this:
You can easily create a little document with the fingerprint of the key
you want to sign, timestamp, maybe other notions and sign that. Then you
can publish this document. In fact the signature on a key is very
similar to such a document. Just that it has a machine readable
structure.

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20150816/e229402c/attachment.sig>

From diafygi at gmail.com  Sun Aug 16 16:12:56 2015
From: diafygi at gmail.com (Daniel Roesler)
Date: Sun, 16 Aug 2015 07:12:56 -0700
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <1753867983.20150816121503@my_localhost>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <1753867983.20150816121503@my_localhost>
Message-ID: <CA+65Osr+cwKg+cyxTfMNCEybkOEgga5WeEH=A_8ycWY9z8NgFg@mail.gmail.com>

On Sun, Aug 16, 2015 at 4:15 AM, MFPA
<2014-667rhzu3dc-lists-groups at riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi
>
>
> On Sunday 16 August 2015 at 9:10:28 AM, in
> <mid:20150816081028.GA26761 at zwiebelfreund.de>, Stefan Claas wrote:
>
>
>
>> after seeing Facebook's public key a couple of days
>> ago, i was wondering if it's possible to enhance GnuPG
>> in a future version, so that it no longer allows
>> someone to sign a public key without approval of the
>> owner.
>
> If GnuPG were modified in this way the key could still be signed
> using an old GnuPG version, or any other OpenPGP application.
>
> I guess a modification would be possible that allowed a GnuPG user to
> sign acceptance or rejection over a third-party signature, but I'm not
> convinced there would be any point. Firstly, would such acceptance or
> rejection be dropped by the keyservers? <snip>

No, the keyserver pool does not reject any signatures, even if the
signature itself is invalid. When you receive a public key from the
keyserver pool it's the job of the client to clean/reject invalid or
unknown signatures. I've argued a bit that keyservers should start to
play a role in policing the pool, but it's a controversial topic.

https://lists.gnu.org/archive/html/sks-devel/2015-05/msg00022.html

Unfortunately, that leads to trolls tagging notable public keys (such
as Facebook and Adrian Lamo) with unseemly material, but these will
just be ignored by gpg when you fetch that public key.


From admin at zwiebelfreund.de  Sun Aug 16 16:26:16 2015
From: admin at zwiebelfreund.de (Stefan Claas)
Date: Sun, 16 Aug 2015 16:26:16 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
Message-ID: <20150816142616.GA1868@zwiebelfreund.de>

On Sun, Aug 16, 2015 at 11:18:20AM +0000, Philipp Schafft wrote:
> reflum,
> 
> On Sun, 2015-08-16 at 10:10 +0200, Stefan Claas wrote:
> > Hello Werner and all,
> > 
> > after seeing Facebook's public key a couple of days ago,
> > i was wondering if it's possible to enhance GnuPG in a
> > future version, so that it no longer allows someone to
> > sign a public key without approval of the owner.
> 
> Maybe you can explain your use case a bit.
> Think about this:
> You can easily create a little document with the fingerprint of the key
> you want to sign, timestamp, maybe other notions and sign that. Then you
> can publish this document. In fact the signature on a key is very
> similar to such a document. Just that it has a machine readable
> structure.
> 
> -- 
> Philipp.
>  (Rah of PH2)
if i understand you correctly it would not help me if someone
would sign my key without my approval, so to speak.

What i meaned whith my initial post was that it should in the
future not be possible to sign someones pub key directly, to
prevent unwanted signatures. Sure one can revoke his/her pub
key, but how often would you like to do that if a "prankster"
has lot's of energy?

I also forgot to mention in my first post that it would also
require that Alice has to enter her secrets key passphrase to
authorize Bob's Signature Request Certificate, after validating 
Bob's request cert.

I think it would be a welcome addition for  a future version of
GnuPG.

Regards
Stefan



From viktordick86 at gmail.com  Sun Aug 16 17:31:10 2015
From: viktordick86 at gmail.com (Viktor Dick)
Date: Sun, 16 Aug 2015 17:31:10 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816142616.GA1868@zwiebelfreund.de>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
Message-ID: <55D0ACBE.7050609@gmail.com>

On 16.08.2015 16:26, Stefan Claas wrote:
> if i understand you correctly it would not help me if someone
> would sign my key without my approval, so to speak.

Sure it helps. If Alice signs my key and Bob wants to send me something
and trusts Alice, he can derive some trust that my key is also genuine.
One could argue that anyone who I do not know and who anyhow signs my
key will probably not be (rightfully) trusted by anyone. However, some
magazines (I'm thinking of c't) for example might put their fingerprint
on each issue and someone who buys it might sign their key so that some
friend of theirs who has not direct access to that can still be somehow
sure that the key is correct.

I haven't looked at Facebook's public key, but let's assume that I want
to send them an e-mail and tell my client 'get the key of
info at facebook.com'. It will download the key with a lot of signatures,
some of which might be owned by someone in my web of trust. This person
has probably just checked that the fingerprint given on their webpage
matches the one of this particular key, but then that's something I do
not need to check myself.

(Not sure if that should be enough to sign a key, though...)

Kind regards
Viktor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150816/59b78d7d/attachment-0001.sig>

From admin at zwiebelfreund.de  Sun Aug 16 18:31:20 2015
From: admin at zwiebelfreund.de (Stefan Claas)
Date: Sun, 16 Aug 2015 18:31:20 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <55D0ACBE.7050609@gmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
 <55D0ACBE.7050609@gmail.com>
Message-ID: <20150816163120.GA3995@zwiebelfreund.de>

On Sun, Aug 16, 2015 at 05:31:10PM +0200, Viktor Dick wrote:
> On 16.08.2015 16:26, Stefan Claas wrote:
> > if i understand you correctly it would not help me if someone
> > would sign my key without my approval, so to speak.
> 
> Sure it helps. If Alice signs my key and Bob wants to send me something
> and trusts Alice, he can derive some trust that my key is also genuine.
> One could argue that anyone who I do not know and who anyhow signs my
> key will probably not be (rightfully) trusted by anyone. However, some
> magazines (I'm thinking of c't) for example might put their fingerprint
> on each issue and someone who buys it might sign their key so that some
> friend of theirs who has not direct access to that can still be somehow
> sure that the key is correct.

Ok, i understand but it helps not to solve the issue of unwanted signatures,
which i'm talking about.
 
> I haven't looked at Facebook's public key, but let's assume that I want
> to send them an e-mail and tell my client 'get the key of
> info at facebook.com'. It will download the key with a lot of signatures,
> some of which might be owned by someone in my web of trust. This person
> has probably just checked that the fingerprint given on their webpage
> matches the one of this particular key, but then that's something I do
> not need to check myself.
> 
> (Not sure if that should be enough to sign a key, though...)
> 
> Kind regards
> Viktor
> 
Here's as an example the Facebook pub key:
https://pgp.mit.edu/pks/lookup?search=facebook+Inc&op=vindex

Should now GnuPG been enhaned, or the Key Server's been updated,
similar to the pgp.com one.in order to allow such things not in
the future?

Regards
Stefan



> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users



From einarr at pvv.org  Sun Aug 16 18:04:38 2015
From: einarr at pvv.org (Einar Ryeng)
Date: Sun, 16 Aug 2015 18:04:38 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816142616.GA1868@zwiebelfreund.de>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
Message-ID: <20150816160438.GA1462@pvv.ntnu.no>

On Sun, Aug 16, 2015 at 04:26:16PM +0200, Stefan Claas wrote:
> 
> What i meaned whith my initial post was that it should in the
> future not be possible to sign someones pub key directly, to
> prevent unwanted signatures. Sure one can revoke his/her pub
> key, but how often would you like to do that if a "prankster"
> has lot's of energy?

What harm do your see in "fake" signatures? There is a possibility of someone
making your key excessively large to download by adding tons of signatures to
it. If that happens, the correct place to fix it is probably the keyserver
code. Your "signed signatures" proposal would not inherently eliminate this
problem; Alice would still need to make a signature on Bob's key and upload it
to the server in order to allow Bob to download and sign the signature.

Is there any other problem arising from someone signing your key without
"permission"?

If you only want this for decluttering purposes, you will probably achieve
something similar by only looking at mutually signed keys. It won't be exactly
same, because the keys then have signed each other directly rather than each
other's signature packets, but depending on your problem it may do the job for
you.

-- 
Einar Ryeng



From vedaal at nym.hush.com  Sun Aug 16 19:15:16 2015
From: vedaal at nym.hush.com (vedaal at nym.hush.com)
Date: Sun, 16 Aug 2015 13:15:16 -0400
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816163120.GA3995@zwiebelfreund.de>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de> 
Message-ID: <20150816171516.9276343128@smtp.hushmail.com>

On 8/16/2015 at 12:34 PM, "Stefan Claas" <admin at zwiebelfreund.de> wrote:
 
>Should now GnuPG been enhaned, or the Key Server's been updated,
>similar to the pgp.com one.in order to allow such things not in
>the future?

=====

It would be very helpful if such a protection against unwanted key signatures could be instituted.
Here is a possible suggestion on how it might be done:

[1] Have GnuPG require a 'cross-certification' of signatures, similar to the cross-certification of subkeys.

[2] Have GnuPG give a message upon importing a public key, that
 
"Signatures from keyid's [...], [....], and [...] have not been cross-certified by their owner,
Clean these signatures, y / n ? "

(Alternatively, the default could be:
"These signatures will be removed. If you want to keep them, enter  'keep-sig' ",

and then each new sig would be displayed, and if the importer
wants the sig, the importer would need to enter 'keep-sig' for each sig individually.)

This would require the owners of the keys to do periodic checking of their keys and cross-certify the signatures they want.

It would also be a bit of work for the owners to cross-certify all the 'good'  signatures they were happy to get.


Just a suggestion.

The implementers can best decide how much extra work this would require, and if there is a simpler better way to accomplish the desired result.


vedaal




From admin at zwiebelfreund.de  Sun Aug 16 19:41:33 2015
From: admin at zwiebelfreund.de (Stefan Claas)
Date: Sun, 16 Aug 2015 19:41:33 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816160438.GA1462@pvv.ntnu.no>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
 <20150816160438.GA1462@pvv.ntnu.no>
Message-ID: <20150816174133.GA5884@zwiebelfreund.de>

On Sun, Aug 16, 2015 at 06:04:38PM +0200, Einar Ryeng wrote:
> On Sun, Aug 16, 2015 at 04:26:16PM +0200, Stefan Claas wrote:
> > 
> > What i meaned whith my initial post was that it should in the
> > future not be possible to sign someones pub key directly, to
> > prevent unwanted signatures. Sure one can revoke his/her pub
> > key, but how often would you like to do that if a "prankster"
> > has lot's of energy?
> 
> What harm do your see in "fake" signatures? There is a possibility of someone
> making your key excessively large to download by adding tons of signatures to
> it. If that happens, the correct place to fix it is probably the keyserver
> code. Your "signed signatures" proposal would not inherently eliminate this
> problem; Alice would still need to make a signature on Bob's key and upload it
> to the server in order to allow Bob to download and sign the signature.
> 
> Is there any other problem arising from someone signing your key without
> "permission"?
> 
> If you only want this for decluttering purposes, you will probably achieve
> something similar by only looking at mutually signed keys. It won't be exactly
> same, because the keys then have signed each other directly rather than each
> other's signature packets, but depending on your problem it may do the job for
> you.
> 
> -- 
> Einar Ryeng

Hi,

what harm do i see with "fake" signatures or signatures without permission?

Well, i think everybody here or elsewere can imagine by themselves how
"happy" one would be to receive unwanted signatures, depending on the
content...

Regards
Stefan



From aarcane at aarcane.org  Sun Aug 16 20:24:38 2015
From: aarcane at aarcane.org (Schlacta, Christ)
Date: Sun, 16 Aug 2015 11:24:38 -0700
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816171516.9276343128@smtp.hushmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
 <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
Message-ID: <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>

I'll reiterate that there's really no such thing as unwanted signatures.
The more signatures on a key,  the stronger the Web of Trust. End of story.
Please try to understand that no signature is inherently unwanted. Your
proposal, in any form,  would weaken gpg on the whole by increasing the
already high burden on users to maintain their keys.
On Aug 16, 2015 10:16 AM, <vedaal at nym.hush.com> wrote:

> On 8/16/2015 at 12:34 PM, "Stefan Claas" <admin at zwiebelfreund.de> wrote:
>
> >Should now GnuPG been enhaned, or the Key Server's been updated,
> >similar to the pgp.com one.in order to allow such things not in
> >the future?
>
> =====
>
> It would be very helpful if such a protection against unwanted key
> signatures could be instituted.
> Here is a possible suggestion on how it might be done:
>
> [1] Have GnuPG require a 'cross-certification' of signatures, similar to
> the cross-certification of subkeys.
>
> [2] Have GnuPG give a message upon importing a public key, that
>
> "Signatures from keyid's [...], [....], and [...] have not been
> cross-certified by their owner,
> Clean these signatures, y / n ? "
>
> (Alternatively, the default could be:
> "These signatures will be removed. If you want to keep them, enter
> 'keep-sig' ",
>
> and then each new sig would be displayed, and if the importer
> wants the sig, the importer would need to enter 'keep-sig' for each sig
> individually.)
>
> This would require the owners of the keys to do periodic checking of their
> keys and cross-certify the signatures they want.
>
> It would also be a bit of work for the owners to cross-certify all the
> 'good'  signatures they were happy to get.
>
>
> Just a suggestion.
>
> The implementers can best decide how much extra work this would require,
> and if there is a simpler better way to accomplish the desired result.
>
>
> vedaal
>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150816/06337159/attachment.html>

From admin at zwiebelfreund.de  Sun Aug 16 22:19:06 2015
From: admin at zwiebelfreund.de (Stefan Claas)
Date: Sun, 16 Aug 2015 22:19:06 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
 <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
Message-ID: <20150816201906.GA8860@zwiebelfreund.de>

On Sun, Aug 16, 2015 at 11:24:38AM -0700, Schlacta, Christ wrote:
> I'll reiterate that there's really no such thing as unwanted signatures.
> The more signatures on a key,  the stronger the Web of Trust. End of story.
> Please try to understand that no signature is inherently unwanted. Your
> proposal, in any form,  would weaken gpg on the whole by increasing the
> already high burden on users to maintain their keys.

With all due respect, but why should a GnuPG user not been allowed to decide
by him/herself which signatures he/she likes to have on his/her pub key? 
I don't get it, seriously. BTW. maybe a language barrier, but an unwanted 
signature for me is a signature which contains crap or false content which 
does not help the Web of Trust in any way and which i or others don't like
to see on our public keys.

P.S. last post for today, getting late here.

Regards
Stefan



From rjh at sixdemonbag.org  Sun Aug 16 22:41:14 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 16 Aug 2015 16:41:14 -0400
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
Message-ID: <55D0F56A.4060002@sixdemonbag.org>

> I'll reiterate that there's really no such thing as unwanted
> signatures.

No?  So you'd be fine if someone generated a fake certificate belonging
to "White Power Action Network <wpan at stormfront.org>" and added a
signature to your certificate from it?

There are definitely such things as unwanted signatures.

> The more signatures on a key,  the stronger the Web of Trust. End of 
> story.

No.  This isn't even in the same postal code as reality.  More
signatures from *real people* may result in a better WoT; more
signatures, period, or signatures from fake identities, really don't add
anything.


From rjh at sixdemonbag.org  Sun Aug 16 23:26:15 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 16 Aug 2015 17:26:15 -0400
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <CACpWn9S9rn7d52nY5nqdUg0wWFQJefGR0PYofD=uEbo9f3tT8Q@mail.gmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
 <55D0F56A.4060002@sixdemonbag.org>
 <CACpWn9S9rn7d52nY5nqdUg0wWFQJefGR0PYofD=uEbo9f3tT8Q@mail.gmail.com>
Message-ID: <55D0FFF7.8090709@sixdemonbag.org>

> What other people do says nothing about me, and everything about
> them.

Except that 99% of people who see that signature will think you have an
association with white supremacists.

Should they?  No.

Will they?  Yes.

The average person doesn't have a formal/mathematical model of trust and
what it means.  They have a loose, poorly-specified understanding, like
"only sign certificates of people you know well."  This leads them to
thinking, "well, this white supremacist group must know Chris well".
That's a false inference, but it's one a *large* number of people draw.

> On popular keys,  such as Facebook's, or any other public figure,
> there are going to accumulate signatures that aren't a part of
> anybody's Web of Trust. Until such time that these signatures can
> constitute a genuine threat to the Web of Trust, they're irrelevant.

So you're now changing your statement: signatures *don't* always
strengthen the WoT -- a large number of them are irrelevant.  This is
much closer to reality.


From aarcane at aarcane.org  Mon Aug 17 00:05:59 2015
From: aarcane at aarcane.org (Schlacta, Christ)
Date: Sun, 16 Aug 2015 15:05:59 -0700
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <55D0FFF7.8090709@sixdemonbag.org>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de>
 <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
 <55D0F56A.4060002@sixdemonbag.org>
 <CACpWn9S9rn7d52nY5nqdUg0wWFQJefGR0PYofD=uEbo9f3tT8Q@mail.gmail.com>
 <55D0FFF7.8090709@sixdemonbag.org>
Message-ID: <CACpWn9SJTHp=c-YxV4x-1iXZwxDoJJX7-msnk7_H9XWzOdL2jQ@mail.gmail.com>

On Aug 16, 2015 2:27 PM, "Robert J. Hansen" <rjh at sixdemonbag.org> wrote:
>
> > What other people do says nothing about me, and everything about
> > them.
>
> Except that 99% of people who see that signature will think you have an
> association with white supremacists.
>
> Should they?  No.
>
> Will they?  Yes.

People are stupid. Not necessarily any individual person, but people at
large are.

>
> The average person doesn't have a formal/mathematical model of trust and
> what it means.  They have a loose, poorly-specified understanding, like
> "only sign certificates of people you know well."  This leads them to
> thinking, "well, this white supremacist group must know Chris well".
> That's a false inference, but it's one a *large* number of people draw.
>
> > On popular keys,  such as Facebook's, or any other public figure,
> > there are going to accumulate signatures that aren't a part of
> > anybody's Web of Trust. Until such time that these signatures can
> > constitute a genuine threat to the Web of Trust, they're irrelevant.
>
> So you're now changing your statement: signatures *don't* always
> strengthen the WoT -- a large number of them are irrelevant.  This is
> much closer to reality.

If you rounded up all the signatures on a key server,  and just started
deleting them at random,  any given deletion is significantly more likely
to weaken the Web of Trust than to make no change, therefore,
mathematically, every signature strengthens the WoT on average.

Let's assign a value if 0 to every irrelevant signature, and a value of 1
to every relevant signature.  The total strength of the Web is the sum of
the keys in the Web.   Then the expected value of any given key's deletion
is in fact a negative value greater than 0, and if we rebuild the Web from
those signatures,  the addition of any key has an expected value greater
than 0, therefore, every key strengthens the Web
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150816/28ac19ce/attachment.html>

From 2014-667rhzu3dc-lists-groups at riseup.net  Mon Aug 17 00:53:07 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sun, 16 Aug 2015 23:53:07 +0100
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816171516.9276343128@smtp.hushmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
Message-ID: <569591126.20150816235307@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Sunday 16 August 2015 at 6:15:16 PM, in
<mid:20150816171516.9276343128 at smtp.hushmail.com>, vedaal at nym.hush.com
wrote:


> This would require the owners of the keys to do
> periodic checking of their keys and cross-certify the
> signatures they want.

Why bother periodically checking? If somebody doesn't have the
courtesy to send the signature to the key owner rather than publishing
it themselves, they shouldn't expect the key owner to cross-certify
it.



> The implementers can best decide how much extra work
> this would require, and if there is a simpler better
> way to accomplish the desired result.

The "keyserver no-modify" flag was simple. But it didn't achieve the
desired result.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

The second mouse gets the cheese
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJV0RSHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwP00H+wf3fJ5febGlQixq2npTGVa2
PqQL8Ipr1202a9PUS/milX0VJL/pb3a9JoKMNlp0g91HktedcxU+ageqhZYWD+d9
NtymQfnyrHk7jwHM6SJFhEo5t9/ZzIsmqaqnXBglrg3a7mj2fcfNe7N5wkn52MFJ
0GtgE2NM1WcHgv0EaJkjAj8JnB1eU+liOAz773/yUCf99IK7yv4hTVTAKQq4ElhV
6ZiBjYLOWXAhTCSVp0H/U8j7WnN2xrrSfiC7o9xCOsXkqjtoDoVyrkzmffl/zbkX
VCkwYoLdPh23Noe+QxB/Q9dVz7GiB7kcUFcycvJQbzDLqif2kZ96J6wXfmaW+jaI
vgQBFgoAZgUCVdEUjF8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45P97AQCS0hy8ocOPOYCXN/xnkSnwxRZG
W6Pr/INQ7c6/0NR7HwEAxqFjpYel0Xb38bRZk+kwm1wayjEBOARTMTbYzcI5SQE=
=+DOC
-----END PGP SIGNATURE-----



From rjh at sixdemonbag.org  Mon Aug 17 01:02:22 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 16 Aug 2015 19:02:22 -0400
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <CACpWn9SJTHp=c-YxV4x-1iXZwxDoJJX7-msnk7_H9XWzOdL2jQ@mail.gmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
 <55D0F56A.4060002@sixdemonbag.org>
 <CACpWn9S9rn7d52nY5nqdUg0wWFQJefGR0PYofD=uEbo9f3tT8Q@mail.gmail.com>
 <55D0FFF7.8090709@sixdemonbag.org>
 <CACpWn9SJTHp=c-YxV4x-1iXZwxDoJJX7-msnk7_H9XWzOdL2jQ@mail.gmail.com>
Message-ID: <55D1167E.4080906@sixdemonbag.org>

> People are stupid. Not necessarily any individual person, but people at
> large are.

https://xkcd.com/1386/

> If you rounded up all the signatures on a key server,  and just started
> deleting them at random,  any given deletion is significantly more
> likely to weaken the Web of Trust than to make no change, therefore,
> mathematically, every signature strengthens the WoT on average.

This is quickly becoming tendentious.


From administrador at unseen.is  Mon Aug 17 01:27:10 2015
From: administrador at unseen.is (Administrador)
Date: Sun, 16 Aug 2015 23:27:10 +0000
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <CACpWn9SJTHp=c-YxV4x-1iXZwxDoJJX7-msnk7_H9XWzOdL2jQ@mail.gmail.com>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
 <55D0F56A.4060002@sixdemonbag.org>
 <CACpWn9S9rn7d52nY5nqdUg0wWFQJefGR0PYofD=uEbo9f3tT8Q@mail.gmail.com>
 <55D0FFF7.8090709@sixdemonbag.org>
 <CACpWn9SJTHp=c-YxV4x-1iXZwxDoJJX7-msnk7_H9XWzOdL2jQ@mail.gmail.com>
Message-ID: <55D11C4E.1010505@unseen.is>


For me there is no trust in the fact that anyone can sign my key and put
it on a keyserver, and because I do not know the person who did can not
validate their signiture/identity.  What trust does this offer the
people who are real, trusted and known by me and whos keys have been
validated by me and my key(s) by them?

Give the owner the authority of his own public key and this issue would
fixed.  For example: Only the owner of the public key has the right to
put/remove/modify his own public key on a keyserver.


Schlacta, Christ:
> On Aug 16, 2015 2:27 PM, "Robert J. Hansen" <rjh at sixdemonbag.org> wrote:
>>
>>> What other people do says nothing about me, and everything about
>>> them.
>>
>> Except that 99% of people who see that signature will think you have an
>> association with white supremacists.
>>
>> Should they?  No.
>>
>> Will they?  Yes.
> 
> People are stupid. Not necessarily any individual person, but people at
> large are.
> 
>>
>> The average person doesn't have a formal/mathematical model of trust and
>> what it means.  They have a loose, poorly-specified understanding, like
>> "only sign certificates of people you know well."  This leads them to
>> thinking, "well, this white supremacist group must know Chris well".
>> That's a false inference, but it's one a *large* number of people draw.
>>
>>> On popular keys,  such as Facebook's, or any other public figure,
>>> there are going to accumulate signatures that aren't a part of
>>> anybody's Web of Trust. Until such time that these signatures can
>>> constitute a genuine threat to the Web of Trust, they're irrelevant.
>>
>> So you're now changing your statement: signatures *don't* always
>> strengthen the WoT -- a large number of them are irrelevant.  This is
>> much closer to reality.
> 
> If you rounded up all the signatures on a key server,  and just started
> deleting them at random,  any given deletion is significantly more likely
> to weaken the Web of Trust than to make no change, therefore,
> mathematically, every signature strengthens the WoT on average.
> 
> Let's assign a value if 0 to every irrelevant signature, and a value of 1
> to every relevant signature.  The total strength of the Web is the sum of
> the keys in the Web.   Then the expected value of any given key's deletion
> is in fact a negative value greater than 0, and if we rebuild the Web from
> those signatures,  the addition of any key has an expected value greater
> than 0, therefore, every key strengthens the Web
>>
>> _______________________________________________
>> Gnupg-users mailing list
>> Gnupg-users at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 

administrador.

aut viam inveniam aut faciam

GPG KEY: 0CA6758D CA89F37F 49AE9799 D8D493A8 1CB8EEC8



From ndk.clanbo at gmail.com  Mon Aug 17 11:02:33 2015
From: ndk.clanbo at gmail.com (NdK)
Date: Mon, 17 Aug 2015 11:02:33 +0200
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <20150816160438.GA1462@pvv.ntnu.no>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <20150816160438.GA1462@pvv.ntnu.no>
Message-ID: <55D1A329.9070509@gmail.com>

Il 16/08/2015 18:04, Einar Ryeng ha scritto:

> Is there any other problem arising from someone signing your key without
> "permission"?
The only problem I see is that you can easily get associated with the
wrong people. Like what happened here in Italy with Fidobust (about 25
years ago): some pirates' phone lines were being tapped, and since they
connected to Fidonet BBSs, those got tapped too... then their lines were
tapped and the other nodes they connected to became "suspects" and so
on. As a result, a lot of people have had their bedrooms (where they
kept the BBS PC) locked for the YEARS needed by "justice" to do its work.

That's why my skin crawls when Robert J Hansen says
> Except that 99% of people who see that signature will think you have
> an association with white supremacists.
> Should they?  No.
> Will they?  Yes.
Especially if one of those is a judge. When the average person have to
pay for a lawyer, (s)he has already lost.

BYtE,
 Diego


From 2014-667rhzu3dc-lists-groups at riseup.net  Wed Aug 19 00:54:41 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Tue, 18 Aug 2015 23:54:41 +0100
Subject: protecting pub-keys from unwanted signatures
In-Reply-To: <55D11C4E.1010505@unseen.is>
References: <20150816081028.GA26761@zwiebelfreund.de>
 <20150816111828.0BB8D12BB3@grassland.keep-cool.org>
 <20150816142616.GA1868@zwiebelfreund.de> <55D0ACBE.7050609@gmail.com>
 <20150816163120.GA3995@zwiebelfreund.de>
 <20150816171516.9276343128@smtp.hushmail.com>
 <CACpWn9ReUMYk+MQJ2txfvg2Xi1g8Ayx7-QxyVXq0k1WOKoz0CQ@mail.gmail.com>
 <55D0F56A.4060002@sixdemonbag.org>
 <CACpWn9S9rn7d52nY5nqdUg0wWFQJefGR0PYofD=uEbo9f3tT8Q@mail.gmail.com>
 <55D0FFF7.8090709@sixdemonbag.org>
 <CACpWn9SJTHp=c-YxV4x-1iXZwxDoJJX7-msnk7_H9XWzOdL2jQ@mail.gmail.com>
 <55D11C4E.1010505@unseen.is>
Message-ID: <1689656813.20150818235441@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Monday 17 August 2015 at 12:27:10 AM, in
<mid:55D11C4E.1010505 at unseen.is>, Administrador wrote:


> For me there is no trust in the fact that anyone can sign my key and put
> it on a keyserver, and because I do not know the person who did can not
> validate their signiture/identity.

For the time being, forget keys and think about people in the real
world. Do you know the name of everybody who knows your name? Do you
know the name of anybody who does not know your name?



> What trust does this offer the
> people who are real, trusted and known by me and whos keys have been
> validated by me and my key(s) by them?

None: if you know each other and have verified each other's keys, you
do not need a certification from anybody else. In that case all
signatures are just "noise".

What about somebody who has not verified your key, but has verified
one or more of the keys that have signed your key? They can use the
presence of those signatures as a factor in deciding whether to trust
your key. In that case, signatures from keys that person has verified
are useful _to_that_person_ but any other signatures are "noise"
_to_that_person_. The signatures that have been found useful in this
case won't necessarily be signatures from keys that you have verified,
but their presence may have enabled somebody to decide to trust your
key.



> Give the owner the authority of his own public key and
> this issue would fixed.  For example: Only the owner of
> the public key has the right to put/remove/modify his
> own public key on a keyserver.

If such a server were implemented, anybody wanting to add a signature
without the key-owner's sanction could fetch the key, sign it, and
upload it to an ordinary server.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Free advice costs nothing until you act upon it
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJV07e6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwJsIH/AiGwS+qXe1y80Kk6poG+gKT
lPIFaBOnZGQC382vj5j90SdBo6mwcZai7BOQpHQ8l0aPn1VnhDPUUO6mWALybRlc
mRay5C1CUvVHSLTGzQXN8rR4PGDNUABPdYPp68L03tvo5sN3CgTJ/I+qdEVhDUFi
1vBJJClJBFFEcPoda+1svamJEOkQ7NQHCLOlnrnFW52ATLq5eHumnLJSSVx9Hbpv
3fqv3H7I5Qoe7N2rvehPW0fcj8JubbVKbPqMN6vnhTMWcbpUeX8SvFbMfrhIh0u0
pr8fUsOVX27BZfzFzPQk6Y14ZStWYDxVx+eDy3OEdcJ+ORBTY4OM4xC8xrzUV8CI
vgQBFgoAZgUCVdO34l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45DT5AQC4d6i6z/NskkymgzVc1/vxnyiL
RVT7hOVcqtkCfmeetgD+JZ0rptgB3ZmTe55AObv+6mtRZF3dLoNraUJPotw2CQo=
=nWsm
-----END PGP SIGNATURE-----



From dongsheng.song at gmail.com  Thu Aug 20 15:55:08 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Thu, 20 Aug 2015 21:55:08 +0800
Subject: The best practice of master/sub key capabilities
Message-ID: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>

Hi all,

When I create new master/sub key, in the following 2 choice, I'm
wondering which is better?

1) master key have SCEA capabilities

sec  rsa4096/A19676A1
     created: 2015-08-20  expires: never       usage: SCEA
     trust: ultimate      validity: ultimate
ssb  rsa4096/27ADD750
     created: 2015-08-20  expires: never       usage: SEA

2) master key have only Certify capability

sec  rsa4096/1F8AFCAD
     created: 2015-08-20  expires: never       usage: C
     trust: ultimate      validity: ultimate
ssb  rsa4096/8E1D2A87
     created: 2015-08-20  expires: never       usage: SEA

Regards,
Dongsheng


From peter at digitalbrains.com  Thu Aug 20 17:01:15 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Thu, 20 Aug 2015 17:01:15 +0200
Subject: The best practice of master/sub key capabilities
In-Reply-To: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
Message-ID: <55D5EBBB.90004@digitalbrains.com>

> When I create new master/sub key, in the following 2 choice, I'm
> wondering which is better?

I'd recommend the defaults as best practice. They're there for a reason.
Why are you restricting yourself to "the following 2 choices"? They both
seem ill-advised (and unusual as well). Most importantly, it's generally
advised not to do encryption and signing with the same key material.
Furthermore, it is disputed whether RSA-4096 offers a useful
cost/benefit tradeoff. Personally, I'm on the side that thinks it does
not. But who am I.

You also didn't indicate what your usage scenario is, so without that
information, "the defaults" again seem like a pretty solid answer.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From shtrom at ssji.net  Fri Aug 21 01:41:20 2015
From: shtrom at ssji.net (Olivier Mehani)
Date: Thu, 20 Aug 2015 23:41:20 +0000 (UTC)
Subject: PAM/Poldi and GPG/scdaemon interactions
Message-ID: <mr5oj0$5b3$1@ger.gmane.org>

Hi all,

I'm using an OpenPGP smartcard, and am trying to use it to authenticate
to the system using Poldi. I seem to have a race condition betwen the
system's pam_poldi, and my user's gpg-agent/scdaemon processes.
Essentially, it seems I can either login, but not use the card for
GPG---I get this sort of errors

	$ gpg --card-status
	gpg: OpenPGP card not available: Not supported

---or (after killing scdaemon and restarting pcscd), use the card through
gpg-agent, but no longer for system auth, with the following errors:

	$ sudo whatever
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: no supported card application found: General error
	Waiting for card for user `USER'...
	scdaemon[29109]: updating reader 0 (0) status: 0x0000->0x0007 (0->1)
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: apdu_send_simple(0) failed: unknown host status error
	scdaemon[29109]: no supported card application found: General error
	scdaemon[29109]: scdaemon (GnuPG) 2.1.7 stopped


What is the proper way to set this up? Should scdaemon by started by the
system explicitely (poldi.conf has the right path set up to the scdaemon
binary already)? Or should I tell the gpg-agent to use the existing
scdaemon, if any? If so, how?

Thanks!

-- 
Olivier Mehani <shtrom at ssji.net>
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE  F5F9 F012 A6E2 98C6 6655
Confidentiality cannot be guaranteed on emails sent or received unencrypted.



From peter at digitalbrains.com  Fri Aug 21 10:44:14 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 21 Aug 2015 10:44:14 +0200
Subject: The best practice of master/sub key capabilities
In-Reply-To: <55D5EBBB.90004@digitalbrains.com>
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
 <55D5EBBB.90004@digitalbrains.com>
Message-ID: <55D6E4DE.4050803@digitalbrains.com>

On 20/08/15 17:01, Peter Lebbing wrote:
> Most importantly, it's generally advised not to do encryption and 
> signing with the same key material.

This is just a general recommendation, and abusing the fact a key is
used for both encryption and signatures is an intricate matter. But
since OpenPGP supports subkeys, the matter is easily avoided completely
by using a separate subkey for encryption, so it's a good idea to do so.

But it suddenly dawned on me you might have an actual issue when you
assign both Sign and Authenticate capabilities to a key! Authentication
is pretty much proving that you can sign what the server sends you. It
might be the case that these signatures can actually pass for data
signatures or key certifications! I don't think RFC 4880 says anything
about authentication (except when used to refer to data signatures and
key certifications). Checking the OpenPGP Card Specification 3.0, it
would seem that the key in the Authenticate command can indeed issue
signatures, since the PKCS#1 padding is identical to the Sign command,
and there is no check on the signed data.

It seems like a genuinely bad idea to assign Authenticate capability to
a key that has Certify or Sign set. Even if GnuPG or GPG-Agent does
checks to catch abuse, it's just asking for trouble that is easily
avoided, in my opinion.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From peter at digitalbrains.com  Fri Aug 21 11:00:45 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 21 Aug 2015 11:00:45 +0200
Subject: Mixing Authenticate capability with others
Message-ID: <55D6E8BD.30807@digitalbrains.com>

In the thread "The best practice of master/sub key capabilities",
Dongsheng Song asked for advice and gave an example where a master key
has both Certify and Authenticate set, and an example where a subkey has
both Sign and Authenticate set. I wrote in a reply in that thread:

> But it suddenly dawned on me you might have an actual issue when you
> assign both Sign and Authenticate capabilities to a key!
> Authentication is pretty much proving that you can sign what the
> server sends you. It might be the case that these signatures can
> actually pass for data signatures or key certifications! I don't
> think RFC 4880 says anything about authentication (except when used
> to refer to data signatures and key certifications). Checking the
> OpenPGP Card Specification 3.0, it would seem that the key in the
> Authenticate command can indeed issue signatures, since the PKCS#1
> padding is identical to the Sign command, and there is no check on
> the signed data.

Does GnuPG (or GPG-Agent in 2.1) actually check that the challenge sent
by the server is not a validly formatted OpenPGP signature or certification?

And should GnuPG in general perhaps refuse to assign Authenticate
capability to key material with other signature capabilities, just to be
safe?

Oh, I forgot to mention in that other mail that I'm fairly sure I
actually had a signature subkey in the Authenticate slot of an OpenPGP
v.1 card, which worked fine. This corresponds with the observation that
the padding is the same for both operations.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From dongsheng.song at gmail.com  Fri Aug 21 11:31:28 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Fri, 21 Aug 2015 17:31:28 +0800
Subject: The best practice of master/sub key capabilities
In-Reply-To: <55D6E4DE.4050803@digitalbrains.com>
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
 <55D5EBBB.90004@digitalbrains.com> <55D6E4DE.4050803@digitalbrains.com>
Message-ID: <CAE8XmWooEC=soTzC2Oogv5DD8NnJqdF7JFSQT6Uf2smBc0NkZQ@mail.gmail.com>

Thanks, now I see why I should use a exclusively subkey for
authenticate capability.

But I still did't know why the master key have sign and certify
capabilities in the default ? I think the sign capability should move
to a exclusively subkey.


From peter at digitalbrains.com  Fri Aug 21 12:49:05 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 21 Aug 2015 12:49:05 +0200
Subject: The best practice of master/sub key capabilities
In-Reply-To: <CAE8XmWooEC=soTzC2Oogv5DD8NnJqdF7JFSQT6Uf2smBc0NkZQ@mail.gmail.com>
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
 <55D5EBBB.90004@digitalbrains.com> <55D6E4DE.4050803@digitalbrains.com>
 <CAE8XmWooEC=soTzC2Oogv5DD8NnJqdF7JFSQT6Uf2smBc0NkZQ@mail.gmail.com>
Message-ID: <55D70221.5020108@digitalbrains.com>

On 21/08/15 11:31, Dongsheng Song wrote:
> But I still did't know why the master key have sign and certify
> capabilities in the default ?

I suppose because it doesn't hurt. They're both signatures in essence;
cryptographically they are the same and exchangable. The difference only
lies in the interpretation.

Also note that anyone who has access to the primary key material can
issue data signatures at will. They could either add the Sign capability
to the key or (easier) create a new subkey with which to issue signatures.

The actual reason why the default is as it is can probably best be
answered by someone else, though, since I can only guess.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From simon at josefsson.org  Sat Aug 22 00:12:02 2015
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 22 Aug 2015 00:12:02 +0200
Subject: The best practice of master/sub key capabilities
In-Reply-To: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w__38279.2785684161$1440079056$gmane$org@mail.gmail.com>
 (Dongsheng Song's message of "Thu, 20 Aug 2015 21:55:08 +0800")
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w__38279.2785684161$1440079056$gmane$org@mail.gmail.com>
Message-ID: <871tew8f65.fsf@latte.josefsson.org>

Dongsheng Song <dongsheng.song at gmail.com> writes:

> Hi all,
>
> When I create new master/sub key, in the following 2 choice, I'm
> wondering which is better?
>
> 1) master key have SCEA capabilities
>
> sec  rsa4096/A19676A1
>      created: 2015-08-20  expires: never       usage: SCEA
>      trust: ultimate      validity: ultimate
> ssb  rsa4096/27ADD750
>      created: 2015-08-20  expires: never       usage: SEA
>
> 2) master key have only Certify capability
>
> sec  rsa4096/1F8AFCAD
>      created: 2015-08-20  expires: never       usage: C
>      trust: ultimate      validity: ultimate
> ssb  rsa4096/8E1D2A87
>      created: 2015-08-20  expires: never       usage: SEA

I would use a SC master key because I would want to use it to certify
other's keys, and would also be able to use it to sign statements in
case something bad happened to my sub-keys.

I would use three separate sub-keys, one each for the three SEA usages.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: </pipermail/attachments/20150822/98dedb76/attachment.sig>

From rpr.nospam at gmail.com  Sat Aug 22 12:02:59 2015
From: rpr.nospam at gmail.com (rpr)
Date: Sat, 22 Aug 2015 12:02:59 +0200
Subject: PGP Global Directory does not send verification email
Message-ID: <55D848D3.2090401@gmail.com>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I followed instructions given on
https://support.symantec.com/en_US/article.HOWTO42020.html
to submit my public PGP key to PGP Global Directory
(https://keyserver.pgp.com) but after uploading the key file
I have not received the verification email to the corresponding email
address at gmail.com. (I also checked the spam folder.)

After a few hours I tried to repeat the submission but the page gave
the following message:

"A pending key submission is already in progress for email addresses
on the submitted key. The instructions in the previous verification
emails must be followed in order to make a change, or you may resubmit
this request in 24 hours."

which shows that the server actually knows about my submission.

Has anyone seen this recently?

Regarding this issue I wanted to open a case at Symantec Support (as
it seems that the PGP Global Directory is maintained by the Symantec
Corporation since they acquired the PGP Corporation in 2010) but I was
not able to do that as the PGP Global Directory was not listed among
their products. :-( Shame on you Symantec )

BTW, I would like to publish my PGP keys to the PGP Global Directory
as it offers a better protection against harvesting email addresses by
spammers, as explained on the following pages:

https://pgp.mit.edu/faq.html
Q. 6. I think spammers got my email address from the PGP keyserver.
What can I do?

https://keyserver.pgp.com/vkd/VKDHelpPGPCom.html
Will I get spam if I use the PGP Global Directory?

Harvesting email addresses from OpenPGP key servers is quite easy.
Try the following commands:

gpg --keyserver hkp://pool.sks-keyservers.net --search-keys rms
gpg --keyserver hkp://pool.sks-keyservers.net --search-keys rpr

You can also try these queries e.g. at https://pgp.mit.edu

- -- rpr.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJV2EjBAAoJEKlXjuYlVL8IK9wQAJUoVvEok/KAd4koZnjAEz6p
CK1Gc4p0SbMKGcpIOHOSUBX19wsQj/QhhSOOdJPt/JynSPQcBcGrCovnkukQ0S1e
qTA5ZTNlzbVoaEd4RIjC+1r1+DJVT1BffcT2dWzjBpCrMKkDp3smiZslYviKhGNB
9Xfy1oonUFqLu7q/Ppm4dG+ntwZUg8ecdj917US8XnXobrdrLSplv1zGysLbR99b
wQMpDUOEqYtEupYUR6bE9Y7JZd+hMouhXLNRG3dkHqIZQCpwZYEcUyto9WbrQAvk
Fs1Ye/lRkH9vSyVWM1TdrwW00MwLGfS4MYaMGV7HeJFoxcfY2Qyg0ec33sDyqAQn
CsGsCJt2fGhu1sIHSCfB/OVp+q/tkXhFLVelDekVZeXM1BlWYENGlQ1HaXg3gWe+
fbJtjC165+YaY9xcphUxwS9NW87V+uS4b1sFtnZDkDiRM2WrHuAI0bhYfDuhaCZU
zuqyOFzkVlgf78as0w8Tx5gkbj7rBYDejYk2bcRUOHBIrP2aCHS7eGIszk1n4Y89
X3k/pQSsnDwSvB5s5fsp7aAYBclTdzsAdgB1VFQruhaql+vgqB5fqnYGVwYOBuhQ
G6T6jf1PP+ZD8pqS03HjJFpar1Gl4MtjPVXepQ+F32F/rKfsc5la9rsf/CErnqR0
jKsSPGB3Nzgr+9XuLkPx
=CcKg
-----END PGP SIGNATURE-----



From rjh at sixdemonbag.org  Sat Aug 22 13:55:15 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 22 Aug 2015 07:55:15 -0400
Subject: PGP Global Directory does not send verification email
In-Reply-To: <55D848D3.2090401@gmail.com>
References: <55D848D3.2090401@gmail.com>
Message-ID: <55D86323.3080802@sixdemonbag.org>

It's long-standing list policy that we avoid talking about non-libre
software, except in the sense of interoperability concerns.  If you have
concerns with how the PGP Global Keyserver is working, I'd suggest
bringing that up to Symantec's technical support, or a mailing list like
PGP-Basics which explicitly supports PGP and their products.

> BTW, I would like to publish my PGP keys to the PGP Global Directory
> as it offers a better protection against harvesting email addresses by
> spammers, as explained on the following pages:

This is a complete nonissue.  Search the list archives and you'll find
this discussion has been done to death many, many times.  The takeaway:

1.  Spammers don't work by harvesting email addresses.
2.  Honeytrapped email addresses on the global keyserver have not
    been harvested to any significant extent.  (I think the record
    is something like four spam emails over a year-long period.)
3.  Keeping your email address private is the wrong way to address
    the spam problem, anyway.


From 2014-667rhzu3dc-lists-groups at riseup.net  Sat Aug 22 14:02:37 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sat, 22 Aug 2015 13:02:37 +0100
Subject: PGP Global Directory does not send verification email
In-Reply-To: <55D848D3.2090401@gmail.com>
References: <55D848D3.2090401@gmail.com>
Message-ID: <8110363416.20150822130237@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Saturday 22 August 2015 at 11:02:59 AM, in
<mid:55D848D3.2090401 at gmail.com>, rpr wrote:


> "A pending key submission is already in progress for
> email addresses on the submitted key. The instructions
> in the previous verification emails must be followed in
> order to make a change, or you may resubmit this
> request in 24 hours."

I would try again the next day. (-:


> Has anyone seen this recently?

I just tried uploading a key using PGP Global Directory's website
interface, it thought about it for nearly two minutes and then told me
"An unexpected error has occured [sic]. Please try your request
again." This was repeated twice with that key, then happened again
with another key.



> BTW, I would like to publish my PGP keys to the PGP
> Global Directory as it offers a better protection
> against harvesting email addresses by spammers


Conventional keyservers contain many keys with obsolete email
addresses in their UIDs, so much of the harvest would be of no use.
Any results returned by PGP Global Directory will contain email
addresses that were valid in the last six months or so.



> Harvesting email addresses from OpenPGP key servers is
> quite easy.

Not as easy as generating email addresses at random.



> Try the following commands:
>
> gpg --keyserver hkp://pool.sks-keyservers.net --search-keys rms
> gpg --keyserver hkp://pool.sks-keyservers.net --search-keys rpr


The first gave me 130 hits, the second 27 hits. But use a search term
that would bring up lots of matches and you get nothing. Try:-

gpg --keyserver hkp://pool.sks-keyservers.net --search-keys gmail
gpg --keyserver hkp://pool.sks-keyservers.net --search-keys yahoo
gpg --keyserver hkp://pool.sks-keyservers.net --search-keys john
gpg --keyserver hkp://pool.sks-keyservers.net --search-keys smith




- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Something must be done. This is something. Therefore, we must do it.
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJV2GTqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwNp4H/An3xCdyTqHYmGPj5kqeaQJr
XQLubBhNdXgPk0pUgqaIUac1nrgEB1+pB/Fy6LrGLWBAHH0w9/v+x7FA2TTOKNIh
jwAFM4Fzhh4Z6cwMXfvCvzYnQjwRYeF8wuY+ITvDz+x+NnYiIt7Yun7CoQwzTYbO
H/uXzPu6P/Ue2u+XvEvOzwxW9d9psUD9Ufj2FhFR2ndql+Tyh5mMjbEtn6CzyKnA
OttpGnZi789+pcWorLwZAOqKWU5x/hMfADVmJsvKXlCk5xojGFYXOTBTmeD54NQ9
mqFJzybm390qWB59pbwCHsAk0j69OLdLiOZVQab8Lj9KhR+XMXAAD86jjTc7QtGI
vgQBFgoAZgUCVdhk8l8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OefAP4wiv2MnnIGqyAvgbcg0iBuFyL8
rOCUqlEwc1IvDtAJ6QD+Mp2OafxSVzm56+3AJaI1XdsQ0IOzpy+cr3/QhIEpZAY=
=PzVD
-----END PGP SIGNATURE-----



From dongsheng.song at gmail.com  Sat Aug 22 17:25:27 2015
From: dongsheng.song at gmail.com (Dongsheng Song)
Date: Sat, 22 Aug 2015 23:25:27 +0800
Subject: The best practice of master/sub key capabilities
In-Reply-To: <55D70221.5020108@digitalbrains.com>
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
 <55D5EBBB.90004@digitalbrains.com> <55D6E4DE.4050803@digitalbrains.com>
 <CAE8XmWooEC=soTzC2Oogv5DD8NnJqdF7JFSQT6Uf2smBc0NkZQ@mail.gmail.com>
 <55D70221.5020108@digitalbrains.com>
Message-ID: <CAE8XmWoUBcvvJ2Dekp6HHx0CPHnmenMYLTpNdP8ghr6K3CZu8w@mail.gmail.com>

On Fri, Aug 21, 2015 at 6:49 PM, Peter Lebbing <peter at digitalbrains.com> wrote:
> On 21/08/15 11:31, Dongsheng Song wrote:
>> But I still did't know why the master key have sign and certify
>> capabilities in the default ?
>
> I suppose because it doesn't hurt. They're both signatures in essence;
> cryptographically they are the same and exchangable. The difference only
> lies in the interpretation.
>
> Also note that anyone who has access to the primary key material can
> issue data signatures at will. They could either add the Sign capability
> to the key or (easier) create a new subkey with which to issue signatures.
>
> The actual reason why the default is as it is can probably best be
> answered by someone else, though, since I can only guess.
>

Maybe create more subkey need more entropy, gain enough entropy need
very long time ?

Now I want to create my new key like this:

sec   rsa4096/93D374EB 2015-08-22 [C]
uid         [ultimate] example <example at someone.xyz>
ssb   rsa2048/466D08E1 2015-08-22 [S]
ssb   rsa2048/AD92E667 2015-08-22 [E]
ssb   rsa2048/07DEFA25 2015-08-22 [A]
ssb   ed25519/AE83BE7C 2015-08-22 [S]
ssb   cv25519/0FACE148 2015-08-22 [E]
ssb   ed25519/610E5096 2015-08-22 [A]

If something bad happened to my subkeys, I can create new subkeys as well.


From js-gnupg-users at webkeks.org  Sun Aug 23 14:28:15 2015
From: js-gnupg-users at webkeks.org (Jonathan Schleifer)
Date: Sun, 23 Aug 2015 14:28:15 +0200
Subject: Please remove MacGPG from gnupg.org due to serious security
 concerns
In-Reply-To: <B4A88F10-63D7-496D-893B-802F5A21D472@dressyvagabonds.com>
References: <ADECD045-2809-4362-8D5A-43EBA9428C33@mykolab.com>
 <68F2AA9B-B192-4727-9AA3-2BC33CBE5434@mykolab.com>
 <DD18C5EF-523B-4E99-9C84-55C2D8F862B8@gpgtools.org>
 <EB263EDB-EF9B-4702-98A7-212F0C1046EC@webkeks.org>
 <87sie3i7kb.fsf@vigenere.g10code.de>
 <AB173B31-D818-41A6-B7B7-5978C52211CE@webkeks.org>
 <873861d8eq.fsf@vigenere.g10code.de>
 <483FE4A0-C58E-44AB-AD78-EA5E1A80C8D1@gpgtools.org>
 <2786DC31-AEAC-4406-9143-94F32C74A644@webkeks.org>
 <EF669FD7-889C-49C4-AC86-728B6A94B94A@dressyvagabonds.com>
 <B8217C71-71D1-4134-AD58-A6B9E5FFEA08@webkeks.org>
 <B4A88F10-63D7-496D-893B-802F5A21D472@dressyvagabonds.com>
Message-ID: <0F53D2EE-B575-4C60-8C9B-969C39F93AAC@webkeks.org>

Sorry for reviving this old thread. But since you guys still don't accept bug reports (why?!)?

I'm not sure whether this is better or worse than the old situation, but now you include an unsigned binary in your tree that is executed as part of the build process. Nowhere can be found what this binary does or from which sources it has been built. This is at least as bad as executing remove code. Can you please explain why you do this, or why you thought this would be a good idea after that long discussion on how important security is for a security product?

--
Jonathan

From baptiste at bitsofnetworks.org  Sun Aug 23 23:42:06 2015
From: baptiste at bitsofnetworks.org (Baptiste Jonglez)
Date: Sun, 23 Aug 2015 23:42:06 +0200
Subject: Silent re-encryption of private keys by gpg-agent: expected behaviour?
Message-ID: <20150823214203.GD2360@tuxmachine>

Hi,

I spent quite some time wondering why, a few days ago, one of my private
keys had suddenly changed.  More precisely, the file holding the private
key (~/.gnupg/private-keys-v1.d/${keygrip}.key) had changed, without any
obvious reason.  Note that I am using gnupg 2.1.6, so this is the new
private key format.

After some investigation with a backup, it looks like the change is merely
a re-encryption of the private key using a different algorithm.  I am not
familiar with the private key format, but it looks like bencoded data.
The old file exhibits the following string:

    9:protected14:openpgp-native(19:openpgp-private-key(7:version1:4)(4:algo3:RSA)(4:skey

while the modified file contains instead:

    9:protected25:openpgp-s2k3-sha1-aes-cbc((4:sha1

Besides this, lots of binary data has changed in the file.

This is an old subkey, created in 2010 and revoked in 2013, which got
converted to the new gpg-agent format in late 2014, when I started using
gnupg 2.1.0.

My theory is that, a few days ago, I have been reading an old email,
encrypted towards this old subkey.  Upon using the private key, gpg-agent
might have realised that the encryption algorithm of the private key is
weak, and decided to silently re-encrypt the key using a newer algorithm.
If this theory holds, then this behaviour was probably introduced between
gnupg 2.1.0 and 2.1.6, because gnupg 2.1.0 converted the old key to the
new gpg-agent format using the "weak" encryption algorithm.

Still, I am not very comfortable about a private key getting suddenly
modified.  Is this the expected behaviour?  I couldn't find any hint about
private key re-encryption in the release notes or in the various man
pages.

Thanks,
Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20150823/a4d9ec1a/attachment.sig>

From edivya.vyas at gmail.com  Mon Aug 24 08:12:08 2015
From: edivya.vyas at gmail.com (Divya Vyas)
Date: Mon, 24 Aug 2015 11:42:08 +0530
Subject: Fwd: rpm signing and verfiy with self signed certificate
In-Reply-To: <CAGfiMvCAV8p6kGR1XBpLd406gBq_fagNBjZ28ASR21WObA1Tqg@mail.gmail.com>
References: <CAGfiMvCAV8p6kGR1XBpLd406gBq_fagNBjZ28ASR21WObA1Tqg@mail.gmail.com>
Message-ID: <CAGfiMvBEaW3L9cDrURb=tMYkYz8Q5PyujtCULyidFcfLRfFzKQ@mail.gmail.com>

Hi,

I am signing rpms in the rpm database using public key/private key for
signing the rpms and verify on target. If public key is not available,
error is thrown that public key not available.

Now I am looking for certificate verification for signed rpms. Which
certificate technique should I use for host identity? How can I ask rpm or
gpg to check the certificate on given path and if not available then show
me the error or warning?

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150824/3104f66d/attachment.html>

From wk at gnupg.org  Mon Aug 24 09:42:17 2015
From: wk at gnupg.org (Werner Koch)
Date: Mon, 24 Aug 2015 09:42:17 +0200
Subject: Silent re-encryption of private keys by gpg-agent: expected
 behaviour?
In-Reply-To: <20150823214203.GD2360@tuxmachine> (Baptiste Jonglez's message of
 "Sun, 23 Aug 2015 23:42:06 +0200")
References: <20150823214203.GD2360@tuxmachine>
Message-ID: <87pp2duo86.fsf@vigenere.g10code.de>

On Sun, 23 Aug 2015 23:42, baptiste at bitsofnetworks.org said:

> keys had suddenly changed.  More precisely, the file holding the private
> key (~/.gnupg/private-keys-v1.d/${keygrip}.key) had changed, without any
> obvious reason.  Note that I am using gnupg 2.1.6, so this is the new
> private key format.

The 2.1 migration process takes the keys from secring.gpg and stores
them in private-keys-v1.d.  Now, that format is different (it exists
since the introduction of GnuPG 2.0 but was only used for X.509 keys)
and thus it would required a re-encryption of the key.  Obviously this
requires the passphrase.  Now if you have several private keys you would
be asked for a passphrase for each key - this is not a good idea for a
key migration process which should run unattended.

Thus the key is stored in a temporary format until you use it the first
time - then the passphrase is required anyway and gpg=agent can convert
the key to the new format.

Details of the format can be found in  gnupg/agent/keyformat.txt.


Shalom-Salam,

   Werner

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



From peter at digitalbrains.com  Mon Aug 24 14:29:26 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Mon, 24 Aug 2015 14:29:26 +0200
Subject: Mixing Authenticate capability with others
In-Reply-To: <55D6E8BD.30807@digitalbrains.com>
References: <55D6E8BD.30807@digitalbrains.com>
Message-ID: <55DB0E26.6090907@digitalbrains.com>

On 21/08/15 11:00, Peter Lebbing wrote:
> Does GnuPG (or GPG-Agent in 2.1) actually check that the challenge sent
> by the server is not a validly formatted OpenPGP signature or certification?

I should note that it is not possible for an SSH server to evoke a data
signature from gpg-agent running as an SSH agent like this. The server
only controls a minor part of the hashed data.

Quickly browsing through the source code of the SSH agent code in
gpg-agent, it seems it will actually sign whatever it is sent, if I read
it correctly. I still don't think that's a problem because that is no
different than gpg-agent itself which will also happily sign with
unlocked keys, since this is actually its task. What gets sent to the
agent is still under the control of the SSH client, running as the user
themself.

But an SSH agent is only a possible application, it seems to me the
system with OpenPGP subkeys having the Authenticate flag is set up to be
more broad than that. Other applications might be built in a way that
the server controls all the data to be signed.

Am I seeing ghosts here or should the system be more careful of sharing
Authenticate with Sign/Certify?

Oh, and by the way, I quickly realised after my previous message that
authentication is probably always handled by the agent, not just in
GnuPG v2.1. It just didn't seem to be worth a message on its own ;).

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From wk at gnupg.org  Wed Aug 26 10:52:07 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Aug 2015 10:52:07 +0200
Subject: [Announce] GPGME 1.6.0 released
Message-ID: <87bndusa88.fsf@vigenere.g10code.de>

Hello!

We are pleased to announce version 1.6.0 of GPGME.

  GnuPG Made Easy (GPGME) is a C language library that allows to add
  support for cryptography to a program.  It is designed to make access
  to public key crypto engines as included in GnuPG easier for
  applications.  GPGME provides a high-level crypto API for encryption,
  decryption, signing, signature verification, and key management.
  

* Noteworthy changes in version 1.6.0

  - Added gpgme_set_offline to do a key listinging w/o requiring CRL.

  - Added gpgme_set_status_cb to allow a user to see some status
    messages.

  - Added an export mode for secret keys.

  - More precise error codes are returned if GnuPG >= 2.1.8 is used.

  - The passphrase handler for the loopback mode has been improved and may
    also be used with genkey.

  - [w32] The standard GnuPG 2.1 install directory is now seached for
    gpgconf.exe before a registry specified directory and the Gpg4win
    install directory.

  - [w32] gpgme-w32spawn.exe will now only be searched in the gpgme DLL
    directory.


* Download

  You may download this library and its OpenPGP signature from:

    ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.6.0.tar.bz2 (961k)
    ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.6.0.tar.bz2.sig
    
  The SHA-1 checksum is
  
  21510323495f6220f8f67610c3c27a23d761d43d  gpgme-1.6.0.tar.bz2


* Support

  Please send questions regarding the use of GPGME to the gnupg-devel
  mailing list:

    https://lists.gnupg.org/mailman/listinfo/gnupg-devel/

  If you need commercial support, you may want to consult this listing:

    https://gnupg.org/service.html



For the GnuPG team,


  Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20150826/869febc5/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Wed Aug 26 11:04:44 2015
From: wk at gnupg.org (Werner Koch)
Date: Wed, 26 Aug 2015 11:04:44 +0200
Subject: [Announce] Libgpg-error 1.20 released
Message-ID: <877fois9n7.fsf@vigenere.g10code.de>

Hello!

We are pleased to announce version 1.20 of Libgpg-error.

  Libgpg-error is a C language library to provides common error codes
  and a set useful functions.  It is mainly used by GnuPG related
  software like GnuPG, GPGME, GPA, and Libgcrypt.
  

* Noteworthy changes in version 1.20

  - New macros for GCC attributes.

  - Make es_set_binary actually work for Windows.

  - Allow building without thread support.

  - Build without a build timestamp by default.


* Download

  You may download this library and its OpenPGP signature from:

    ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.20.tar.bz2 (752k)
    ftp://ftp.gnupg.org/gcrypt/libgpg-error/libgpg-error-1.20.tar.bz2.sig
    
  The SHA-1 checksum is

  89c961f63469739fe816a56dcdd86c2e1897cace  libgpg-error-1.20.tar.bz2


* Support

  Please send questions regarding the use of Libgpg-error to the
  gnupg-devel mailing list:

    https://lists.gnupg.org/mailman/listinfo/gnupg-devel/

  If you need commercial support, you may want to consult this listing:

    https://gnupg.org/service.html



For the GnuPG team,


  Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20150826/4ae9c417/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From dkbryant at gmail.com  Wed Aug 26 17:16:56 2015
From: dkbryant at gmail.com (Dan Bryant)
Date: Wed, 26 Aug 2015 10:16:56 -0500
Subject: OSX: How to install gpg without Admin password
Message-ID: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA@mail.gmail.com>

I have a monitored OS X laptop that I would like to put GNU Privacy
Guard (gpg) on. Of course I can't because I don't have Admin rights,
but I was hoping there is a way to install it in user space through a
virtual environment or chroot, or some other wizardry, or by exacting
the package files.

Obviously I only need console access to the app.


From edivya.vyas at gmail.com  Mon Aug 24 07:07:25 2015
From: edivya.vyas at gmail.com (Divya Vyas)
Date: Mon, 24 Aug 2015 10:37:25 +0530
Subject: rpm signing and verfiy with self signed certificate
Message-ID: <CAGfiMvCAV8p6kGR1XBpLd406gBq_fagNBjZ28ASR21WObA1Tqg@mail.gmail.com>

Hi,

I am signing rpms in the rpm database using public key/private key for
signing the rpms and verify on target. If public key is not available,
error is thrown that public key not available.

I am using below steps:
https://iuscommunity.org/pages/CreatingAGPGKeyandSigningRPMs.html

Now I am looking for certificate verification for signed rpms. Which
certificate technique should I use for host identity? How can I ask rpm or
gpg to check the certificate on given path and if not available then show
me the error or warning?

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150824/91b7679e/attachment.html>

From frol.onn at gmail.com  Mon Aug 24 17:33:26 2015
From: frol.onn at gmail.com (Evgenii Frolov)
Date: Mon, 24 Aug 2015 18:33:26 +0300
Subject: Kleopatra Ultimate trust CA Cert Signing Authority
Message-ID: <3658999.RdFby5s3jx@myhp>

Hello!

I have the same question.
Did you find the answer?

Best regards!


From dkbryant at gmail.com  Thu Aug 27 01:19:32 2015
From: dkbryant at gmail.com (Dan Bryant)
Date: Wed, 26 Aug 2015 18:19:32 -0500
Subject: OSX: How to install gpg without Admin password
In-Reply-To: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA@mail.gmail.com>
References: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA@mail.gmail.com>
Message-ID: <CAAUFj13cQtPbu7qNCOYY7DyAoW5n5UuhHo-2b+6iX0FuE1_moQ@mail.gmail.com>

I went ahead and made a very very very light OpenSSL set of scripts to
encrypt / decrypt. Not nearly versatile enough, but at least I can
lock some files and send to my friends (if they run my scripts too).

https://gist.github.com/brianddk/a22febdca28f79ad58b0

On Wed, Aug 26, 2015 at 10:16 AM, Dan Bryant <dkbryant at gmail.com> wrote:
> I have a monitored OS X laptop that I would like to put GNU Privacy
> Guard (gpg) on. Of course I can't because I don't have Admin rights,
> but I was hoping there is a way to install it in user space through a
> virtual environment or chroot, or some other wizardry, or by exacting
> the package files.
>
> Obviously I only need console access to the app.


From patrick at enigmail.net  Thu Aug 27 08:31:19 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Thu, 27 Aug 2015 08:31:19 +0200
Subject: OSX: How to install gpg without Admin password
In-Reply-To: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA__259.692516601895$1440609547$gmane$org@mail.gmail.com>
References: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA__259.692516601895$1440609547$gmane$org@mail.gmail.com>
Message-ID: <55DEAEB7.6020201@enigmail.net>

On 26.08.15 17:16, Dan Bryant wrote:
> I have a monitored OS X laptop that I would like to put GNU Privacy
> Guard (gpg) on. Of course I can't because I don't have Admin rights,
> but I was hoping there is a way to install it in user space through a
> virtual environment or chroot, or some other wizardry, or by exacting
> the package files.
> 
> Obviously I only need console access to the app.


Just download a DMG file, open (=mount) it, and copy the PKG file to
some temporary location. Then use pkgutil in a terminal to unpack the
PKG file to some temp directory. Then copy whatever you need to your
home directory.

man pkgutil will tell you how to use it.

-Patrick


From edivya.vyas at gmail.com  Thu Aug 27 08:02:28 2015
From: edivya.vyas at gmail.com (Divya Vyas)
Date: Thu, 27 Aug 2015 11:32:28 +0530
Subject: Multiple GPG public keys with one private keys
Message-ID: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>

Hi,

I am looking at generating multiple public keys with one private keys. As I
have multiple identities. I dont want to generate separate keypair.

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150827/1ae96e0c/attachment.html>

From ndk.clanbo at gmail.com  Thu Aug 27 13:07:14 2015
From: ndk.clanbo at gmail.com (NdK)
Date: Thu, 27 Aug 2015 13:07:14 +0200
Subject: Multiple GPG public keys with one private keys
In-Reply-To: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>
References: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>
Message-ID: <55DEEF62.7000202@gmail.com>

Il 27/08/2015 08:02, Divya Vyas ha scritto:

> I am looking at generating multiple public keys with one private keys.
> As I have multiple identities. I dont want to generate separate keypair.
You can have multiple identities associated with one keypair, eventually
using different subkeys for different purposes.
But this "links" all your identities together, that could be undesirable
in some situations.
The only alternative is to generate different keypairs to keep
identities "unlinked", like if they belong to different people (good
luck having 'em signed by others!).

BYtE,
 Diego


From rjh at sixdemonbag.org  Thu Aug 27 20:41:37 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 27 Aug 2015 14:41:37 -0400
Subject: FAQ: drop mention of 1.4?
Message-ID: <55DF59E1.6090109@sixdemonbag.org>

After much delay, I've started work on overhauling the FAQ and making
the changes I've been threatening for some time.  So far the only
commits have been minor things not worthy of mention, but I'm about to
make a significant content change and I'd like to get the community's
feedback on it.

Namely, I plan on dropping (most) mention of 1.4.  1.4 will get
mentioned as an older branch of GnuPG meant for system administrators,
but for the rest of the FAQ I plan on focusing entirely on GnuPG 2.0 and
2.1.

My rationale for this is simple: we don't want to encourage new users to
use 1.4.  We want to encourage new users to use 2.0 and/or 2.1.

Some tools (e.g., Enigmail) now require 2.0 or later.

I, personally, don't think it's a big deal to drop mention of 1.4 except
to talk about "it's for system administrators, not regular users".
However, I'd really like to hear your feedback on this.  Should we make
this change?  Yes or no?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1016 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150827/5201ccf1/attachment.sig>

From 2014-667rhzu3dc-lists-groups at riseup.net  Thu Aug 27 21:08:24 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Thu, 27 Aug 2015 20:08:24 +0100
Subject: Multiple GPG public keys with one private keys
In-Reply-To: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>
References: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>
Message-ID: <1466183049.20150827200824@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Thursday 27 August 2015 at 7:02:28 AM, in
<mid:CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g at mail.gmail.com>,
Divya Vyas wrote:


> I am looking at generating multiple public keys with
> one private keys.

How would you go about that? The public and private key are generated
at the same time and the pair are mathematically related.

If a private key could have multiple public keys, a signature made
with that private key would be ambiguous.



> As I have multiple identities. I dont
> want to generate separate keypair.

You could add multiple User-IDs to a single key-pair.


- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

He's an environmentalist - his arguments are 100% recycled
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJV32BMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw4qIIAJEzQgim7DgKgERe8hw9wlGw
yUObd/qza3p/YhRkOVgF2rbAUoIVD6SfLgPHmAWuBkgqk2/z0m7iiPn4SVXl4TwG
edZZAPv3VzDUUFEnExWscPUkCfiAdn6kkIq7O7lSx/JiJWF7S332i9mjAXUHMRLH
L4/jXbIDAa2uAtLTrkK+w81Xt1cCPDpi94DRTgJ5de4XkkKFxLQlObjWO7ieFJrI
BipJ9EvZBW+xO0r6dlTOjITA9GaYAlgCFSkWvIpZJxpEWGKEv0Voed9slK939kPk
hWXZ3aEtJZxplePBxfVWNERvfXA9pypobgLHFSKjWw8pqw20fVjnbGvvSuab5seI
vgQBFgoAZgUCVd9gXl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45M0XAP0eb2FVx13s65D7FNM7rtfEJuIb
9U4K8uwHpSk+m26D1QEA3Yqd1Yz61fbWrUDWuwyOXdxESvmw7S1oOuziN4KDFwA=
=dFwL
-----END PGP SIGNATURE-----



From wk at gnupg.org  Thu Aug 27 22:04:35 2015
From: wk at gnupg.org (Werner Koch)
Date: Thu, 27 Aug 2015 22:04:35 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF59E1.6090109@sixdemonbag.org> (Robert J. Hansen's message of
 "Thu, 27 Aug 2015 14:41:37 -0400")
References: <55DF59E1.6090109@sixdemonbag.org>
Message-ID: <87si74o5v0.fsf@vigenere.g10code.de>

On Thu, 27 Aug 2015 20:41, rjh at sixdemonbag.org said:

> I, personally, don't think it's a big deal to drop mention of 1.4 except
> to talk about "it's for system administrators, not regular users".
> However, I'd really like to hear your feedback on this.  Should we make
> this change?  Yes or no?

Yes, please.


Salam-Shalom,

   Werner

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



From johanw at vulcan.xs4all.nl  Thu Aug 27 22:32:21 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Thu, 27 Aug 2015 22:32:21 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF59E1.6090109@sixdemonbag.org>
References: <55DF59E1.6090109@sixdemonbag.org>
Message-ID: <55DF73D5.9020505@vulcan.xs4all.nl>

On 27-08-2015 20:41, Robert J. Hansen wrote:

> My rationale for this is simple: we don't want to encourage new users to
> use 1.4.  We want to encourage new users to use 2.0 and/or 2.1.

Why? I still use 1.4. It is easily usable through the command line if
needed, while 2.x has a very complicated setup with lots of external
dependencies and has a feature bloat most users will never need.

I would certainly include a discussion of the incompatabilities that
exist between 1.4 and 2.1: the dropped V3 keys support and ECC keys in 2.1.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From avi.wiki at gmail.com  Thu Aug 27 20:53:31 2015
From: avi.wiki at gmail.com (Avi)
Date: Thu, 27 Aug 2015 14:53:31 -0400
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF59E1.6090109@sixdemonbag.org>
References: <55DF59E1.6090109@sixdemonbag.org>
Message-ID: <CAF5O_jxb-YhKeioTEZxXMAtZuqNGagQZXOQFA+8OBYFKemXPLg@mail.gmail.com>

I still find it much easier to use off of a USB key than 2.x, and so
continue to use it, FWIW. The 2.x version doesn't work with the (non-FLOSS)
shell I use either, but that isn't a reason to keep it mentioned.

Avi

----
User:Avraham

pub 3072D/F80E29F9 1/30/2009 Avi (Wikimedia-related key) <avi.wiki at gmail.com
>
   Primary key fingerprint: 167C 063F 7981 A1F6 71EC ABAA 0D62 B019 F80E
29F9

On Thu, Aug 27, 2015 at 2:41 PM, Robert J. Hansen <rjh at sixdemonbag.org>
wrote:

> After much delay, I've started work on overhauling the FAQ and making
> the changes I've been threatening for some time.  So far the only
> commits have been minor things not worthy of mention, but I'm about to
> make a significant content change and I'd like to get the community's
> feedback on it.
>
> Namely, I plan on dropping (most) mention of 1.4.  1.4 will get
> mentioned as an older branch of GnuPG meant for system administrators,
> but for the rest of the FAQ I plan on focusing entirely on GnuPG 2.0 and
> 2.1.
>
> My rationale for this is simple: we don't want to encourage new users to
> use 1.4.  We want to encourage new users to use 2.0 and/or 2.1.
>
> Some tools (e.g., Enigmail) now require 2.0 or later.
>
> I, personally, don't think it's a big deal to drop mention of 1.4 except
> to talk about "it's for system administrators, not regular users".
> However, I'd really like to hear your feedback on this.  Should we make
> this change?  Yes or no?
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150827/ef6a3011/attachment.html>

From rjh at sixdemonbag.org  Thu Aug 27 23:11:13 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 27 Aug 2015 17:11:13 -0400
Subject: The FAQ's 4GiB recommendation
Message-ID: <55DF7CF1.406@sixdemonbag.org>

I had someone wonder why the FAQ recommends avoiding CAST, BLOWFISH,
IDEA, or 3DES for bulk encryption.  It occurs to me that this is a
pretty reasonable question and probably should get placed in the FAQ.
So, here's proposed new content -- please feel free to chime in with
thoughts or criticism.

For the technically inclined, yes, this explanation simplifies things an
awful lot -- maybe too far, I don't know.  If you can come up with
better phrasings *that are still understandable to non-technical users*,
I'd love to hear them.  :)

=====

Q:  Why should some ciphers be avoided for bulk encryption?

A:  Ciphers are deterministic.  This means that for the same inputs, you
get the same outputs.

The OpenPGP standard requires that ciphers run in what's called a
"feedback mode," where the ciphertext of one block becomes an input to
the next block.

But what happens if two identical ciphertext blocks are found?  Since
the cipher is deterministic, the cipher will begin repeating its output.
This creates a distinctive pattern which a cryptanalyst can exploit.

For a 64-bit cipher, you'll probably wind up repeating a block after
about 32 gigabytes.  In order to reduce the risk of this happening, we
recommend that if you use a 64-bit cipher  you don't use it to encrypt
more than a single DVD's worth of data -- about four gigabytes.

A 128-bit cipher will begin to repeat after about 100 exabytes.  This is
a number so mind-bogglingly large it's unlikely to ever become a problem
for even the most demanding of users.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1016 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150827/0cc38032/attachment.sig>

From rjh at sixdemonbag.org  Thu Aug 27 23:37:22 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Thu, 27 Aug 2015 17:37:22 -0400
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF73D5.9020505@vulcan.xs4all.nl>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl>
Message-ID: <55DF8312.8090708@sixdemonbag.org>

> Why? I still use 1.4. It is easily usable through the command line if
> needed, while 2.x has a very complicated setup with lots of external
> dependencies and has a feature bloat most users will never need.

The 2.x branch is the future of GnuPG development, has been for some
years now, and is what the GnuPG developers recommend for new users.
Further, a good part of the GnuPG ecosystem is moving to 2.0-only (e.g.,
Enigmail).

Given this, it would only make sense to tell new users about the 1.4
branch if the 1.4 branch offered the average user something that 2.x
doesn't or couldn't.  As near as I can tell, it doesn't.

> I would certainly include a discussion of the incompatabilities that
>  exist between 1.4 and 2.1: the dropped V3 keys support and ECC keys 
> in 2.1.

PGP 2.6 has been obsolete since before I could legally drink, and now
I'm on the wrong side of forty.  You have to draw the line somewhere.
With respect to the FAQ, I'm drawing it here.

I applaud the decision to drop V3 support and MD5, and I don't plan on
making mention of a PGP version that's been obsolete for longer than a
lot of our users have been alive.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1016 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150827/6b4a65f6/attachment-0001.sig>

From wk at gnupg.org  Fri Aug 28 09:30:07 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Aug 2015 09:30:07 +0200
Subject: The FAQ's 4GiB recommendation
In-Reply-To: <55DF7CF1.406@sixdemonbag.org> (Robert J. Hansen's message of
 "Thu, 27 Aug 2015 17:11:13 -0400")
References: <55DF7CF1.406@sixdemonbag.org>
Message-ID: <871tenooow.fsf@vigenere.g10code.de>

On Thu, 27 Aug 2015 23:11, rjh at sixdemonbag.org said:

> But what happens if two identical ciphertext blocks are found?  Since
> the cipher is deterministic, the cipher will begin repeating its output.

What do you thing of

  But what happens if two identical ciphertext blocks are found in the
  same message?

to make it more clear that this is per message?


Shalom-Salam,

   Werner

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



From wk at gnupg.org  Fri Aug 28 09:37:54 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Aug 2015 09:37:54 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF8312.8090708@sixdemonbag.org> (Robert J. Hansen's message of
 "Thu, 27 Aug 2015 17:37:22 -0400")
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
Message-ID: <87wpwfn9rh.fsf@vigenere.g10code.de>

On Thu, 27 Aug 2015 23:37, rjh at sixdemonbag.org said:

> The 2.x branch is the future of GnuPG development, has been for some
> years now, and is what the GnuPG developers recommend for new users.
> Further, a good part of the GnuPG ecosystem is moving to 2.0-only (e.g.,

FWIW: 2.1 even made it into Debian unstable and 1.4 will very likely be
renamed for the next Debian release.

> I applaud the decision to drop V3 support and MD5, and I don't plan on
> making mention of a PGP version that's been obsolete for longer than a
> lot of our users have been alive.

Some of these old time users may not follow the news thus may be baffled
when they figure that gpg is not able to decrypt their old data.  Thus a
short note that a GPG 1 version is maintained to allow decryption of
PGP-2 data or to be used on ancient platforms[1] should be helpful.


Salam-Shalom,

   Werner



[1] Neal is nagging be to agree to the use of some C99 features (varargs
    macros etc.).  I assume we will use them for 2.x - but not for 1.4.

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



From wk at gnupg.org  Fri Aug 28 15:18:24 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Aug 2015 15:18:24 +0200
Subject: [Announce] Libassuan 2.3.0 released
Message-ID: <878u8vmtzz.fsf@vigenere.g10code.de>

Hello!

The GnuPG Project is pleased to announce the availability of
Libassuan 2.3.0.

Libassuan is a generic IPC library used by GnuPG, GPGME, and a few other
packages.  This release fixes two bugs and introduces new support
functions for the socket wrappers.


Noteworthy changes in version 2.3.0
===================================

 * Now wipes out the memory of the context structure before freeing.
   The context may have stored sensitive data in its line buffers.

 * Fixed a problem with the data length limit in assuan_inquire.

 * Returns GPG_ERR_SOURCE_ASSUAN with errors from functions w/o a
   context.

 * Two new functions to tweak the behaviour of the socket wrappers.

 * Experimental code to support Cygwin's local sockets.

 * By default build without a build timestamp.

 * Interface changes relative to the 2.2.1 release:
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 assuan_sock_set_flag     NEW.
 assuan_sock_get_flag     NEW.


Getting the Software
====================

You may download the library and its OpenPGP signature from

  ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.3.0.tar.bz2 (531k)
  ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.3.0.tar.bz2.sig

or

  https://gnupg.org/ftp/gcrypt/libassuan/libassuan-2.3.0.tar.bz2 (531k)
  https://gnupg.org/ftp/gcrypt/libassuan/libassuan-2.3.0.tar.bz2.sig


The SHA-1 checksum is:

23f7ea010983b869f765c36d169dec51c8296cff  libassuan-2.3.0.tar.bz2


Documentation
=============

The file assuan.info has the complete manual of the library.  It is also
possible to read the manual online at

  https://gnupg.org/documentation/manuals/assuan/

or as PDF at

  https://gnupg.org/documentation/manuals/assuan.pdf

You can search the GnuPG mailing list archives or ask on the gnupg-devel
mailing list for advise on how to use Libassuan.


Support
========

Please consult the archive of the gnupg-devel mailing list before
reporting a bug <https://gnupg.org/documentation/mailing-lists.html>.
We suggest to send bug reports for a new release to this list in favor
of filing a bug at <https://bugs.gnupg.org>.  For commercial support
requests we keep a list of known service companies at:

  https://gnupg.org/service.html

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gnupg-devel mailing
list for discussion.


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Maintenance and development of GnuPG and related software is
possible due to many individual and corporate donations; for a list of
non-anonymous donors see <https://gnupg.org/donate/kudos.html>.


For the GnuPG hackers,

   Werner


p.s.
This is a announcement only mailing list.  Please send replies only to
the gnupg-devel 'at' gnupg.org mailing list.

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 180 bytes
Desc: not available
URL: </pipermail/attachments/20150828/2336f06a/attachment.sig>
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From johanw at vulcan.xs4all.nl  Fri Aug 28 16:12:03 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Fri, 28 Aug 2015 16:12:03 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF8312.8090708@sixdemonbag.org>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
Message-ID: <55E06C33.30800@vulcan.xs4all.nl>

On 27-08-2015 23:37, Robert J. Hansen wrote:

> The 2.x branch is the future of GnuPG development, has been for some
> years now, and is what the GnuPG developers recommend for new users.

I see this attitude a lot among software developers and it irritates me:
drop support for "obsolete" features and still try to force everyone to
upgrade, combined with the inability to accept that at some time
software can be feature-complete and only bugfixes are needed. It's the
same attitude MS has when pushing windows 10 to windows 7 users.

Last time I saw this with crypto software was when TextSecure dropped
support of encrypted SMS. Being open source, it was quickly forked but
now people have to use 2 different applications. A pitty.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From dionyziz at gmail.com  Fri Aug 28 16:02:44 2015
From: dionyziz at gmail.com (Dionysis Zindros)
Date: Fri, 28 Aug 2015 17:02:44 +0300
Subject: Multiple GPG public keys with one private keys
In-Reply-To: <1466183049.20150827200824@my_localhost>
References: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>
 <1466183049.20150827200824@my_localhost>
Message-ID: <CAE-c3me=SVzwxmzy-f9Fno5ujNOLMO+etYLEJE2GVLxHZ2fAPg@mail.gmail.com>

You can have multiple public/private key pairs for your public
identities. Then you can maintain a secret public/private key pair
that links your identities together. Encrypt the private keys of your
public identities with the public key of your secret identity and
publish them. Then all you need to decrypt any message sent to the
public key of any of your public identities is the private key of your
secret identity. Simply use your secret identity private key to
decrypt the secret key of your public identity (which is a published
encrypted message) and subsequently use that private key to decrypt
the message that was communicated to you.

This could be easily automated, but I'm not aware of any
implementations that currently do that. However scripting it should
not be too hard.

Finally, mathematically, in the bitcoin world, we've seen hierarchical
deterministic keys. I see no reason why they could not be adopted in
GPG also, although the bitcoin implementation requires use of elliptic
curve keys. However, no implementation exists for GPG as far as I'm
aware.

On Thu, Aug 27, 2015 at 10:08 PM, MFPA
<2014-667rhzu3dc-lists-groups at riseup.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi
>
>
> On Thursday 27 August 2015 at 7:02:28 AM, in
> <mid:CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g at mail.gmail.com>,
> Divya Vyas wrote:
>
>
>> I am looking at generating multiple public keys with
>> one private keys.
>
> How would you go about that? The public and private key are generated
> at the same time and the pair are mathematically related.
>
> If a private key could have multiple public keys, a signature made
> with that private key would be ambiguous.
>
>
>
>> As I have multiple identities. I dont
>> want to generate separate keypair.
>
> You could add multiple User-IDs to a single key-pair.
>
>
> - --
> Best regards
>
> MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>
>
> He's an environmentalist - his arguments are 100% recycled
> -----BEGIN PGP SIGNATURE-----
>
> iQF8BAEBCgBmBQJV32BMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
> QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw4qIIAJEzQgim7DgKgERe8hw9wlGw
> yUObd/qza3p/YhRkOVgF2rbAUoIVD6SfLgPHmAWuBkgqk2/z0m7iiPn4SVXl4TwG
> edZZAPv3VzDUUFEnExWscPUkCfiAdn6kkIq7O7lSx/JiJWF7S332i9mjAXUHMRLH
> L4/jXbIDAa2uAtLTrkK+w81Xt1cCPDpi94DRTgJ5de4XkkKFxLQlObjWO7ieFJrI
> BipJ9EvZBW+xO0r6dlTOjITA9GaYAlgCFSkWvIpZJxpEWGKEv0Voed9slK939kPk
> hWXZ3aEtJZxplePBxfVWNERvfXA9pypobgLHFSKjWw8pqw20fVjnbGvvSuab5seI
> vgQBFgoAZgUCVd9gXl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
> cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
> MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45M0XAP0eb2FVx13s65D7FNM7rtfEJuIb
> 9U4K8uwHpSk+m26D1QEA3Yqd1Yz61fbWrUDWuwyOXdxESvmw7S1oOuziN4KDFwA=
> =dFwL
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From peter at digitalbrains.com  Fri Aug 28 18:12:39 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Fri, 28 Aug 2015 18:12:39 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E06C33.30800@vulcan.xs4all.nl>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl>
Message-ID: <55E08877.70808@digitalbrains.com>

On 28/08/15 16:12, Johan Wevers wrote:
> I see this attitude a lot among software developers and it irritates me:
> drop support for "obsolete" features and still try to force everyone to
> upgrade, [...]

1.4 is fully supported, but occupies a niche. Support is not dropped, nobody
forces you to upgrade. I really don't see where that is coming from. This is
about what one specific document, the FAQ, should treat. 1.4 is still completely
documented, but this niche application you cherish might not warrant the label
/frequently/, the letter F of the FAQ.

Can we please stay on subject. Your message feels like a general rant that has
nothing to do with the FAQ whatsoever.

> [...] combined with the inability to accept that at some time
> software can be feature-complete and only bugfixes are needed.

Funny you mention that. I thought the main difference between 1.4 and 2.x was
that 1.4 just receives bugfixes and new features end up in 2.x. It sounds like
you got exactly what you wanted, yet you feel the need to lash out in a
discussion that has nothing to do with reducing support for 1.4.

There's some tension between two of your desires, by the way. What if your
correspondents in a few years have ECC keys? When 1.4 doesn't get ECC support,
you could complain that they apparently have dropped support for 1.4. But if it
does get ECC support, you can complain that 1.4 is feature-complete and should
only receive bugfixes. Or if your glass is half full, you could even be happy
with either outcome. I think Brian from Monty Python has something to say about it.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From rjh at sixdemonbag.org  Fri Aug 28 18:52:16 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 28 Aug 2015 12:52:16 -0400
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E06C33.30800@vulcan.xs4all.nl>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl>
Message-ID: <55E091C0.3050905@sixdemonbag.org>

> I see this attitude a lot among software developers and it irritates
> me: drop support for "obsolete" features

PGP 2.6 *is* obsolete.  There's no point in using quotation marks.  Read
this URL: http://www.kb.cert.org/vuls/id/836068

"Software developers, Certification Authorities, website owners, and
users should avoid using the MD5 algorithm in any capacity. As previous
research has demonstrated, it should be considered cryptographically
broken and unsuitable for further use."

You don't get clearer than that.  PGP 2.6 is a dead letter.  Obsolete.
And with PGP 2.6 being obsolete, so are V3 keys.

You seem to believe PGP 2.6 (and V3 keys) are still in fine health.
They're not.  They need to be abandoned.  The fire alarm went off 17
years ago, people have had plenty of time to move to the exits, the
thing to do now is watch the thing burn down, share stories about how
well it served us, roast some s'mores, and maybe sing a round of
"Kumbaya, My Lord".

(For non-Americans: s'mores are a dessert involving marshmallows and
chocolate, normally eaten around a campfire.  "Kumbaya, My Lord" is a
well-known campfire song.)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1016 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150828/9f458141/attachment.sig>

From johanw at vulcan.xs4all.nl  Fri Aug 28 19:14:02 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Fri, 28 Aug 2015 19:14:02 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E08877.70808@digitalbrains.com>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl> <55E08877.70808@digitalbrains.com>
Message-ID: <55E096DA.2050503@vulcan.xs4all.nl>

On 28-08-2015 18:12, Peter Lebbing wrote:

> 1.4 is fully supported, but occupies a niche. Support is not dropped, nobody
> forces you to upgrade.

It's starting to feel a little bit with ECC not coming to 1.4 (missing
function required to exchange messages with 2.1 users) and v3 key
support removed from 2.1 (people unable to communicate with pgp 2.x
users) but I'll see how that works out. It forces you to choose or run a
double installation.

> Can we please stay on subject. Your message feels like a general rant that has
> nothing to do with the FAQ whatsoever.

OK, I might have been caried away a little. If someone feels offended I
apologise.

> There's some tension between two of your desires, by the way. What if your
> correspondents in a few years have ECC keys? When 1.4 doesn't get ECC support,
> you could complain that they apparently have dropped support for 1.4.

Whan that happens I think it's time for patches on 1.4 to put ECC in.

> But if it
> does get ECC support, you can complain that 1.4 is feature-complete and should

Those are changes to remain able to communicate encrypted with others,
the mail function of gpg. I'm not asking for features like card support
to be backported to 1.4.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From johanw at vulcan.xs4all.nl  Fri Aug 28 19:25:56 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Fri, 28 Aug 2015 19:25:56 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E091C0.3050905@sixdemonbag.org>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl> <55E091C0.3050905@sixdemonbag.org>
Message-ID: <55E099A4.2080602@vulcan.xs4all.nl>

On 28-08-2015 18:52, Robert J. Hansen wrote:

> You don't get clearer than that.  PGP 2.6 is a dead letter.  Obsolete.

Yes, I agree.

> And with PGP 2.6 being obsolete, so are V3 keys.

No they are not. Reading encrypted archives might be usefull,
re-encrypting received mails is impractical and re-signing them probably
impossible.

The sane thing to do is then to make v3 support read only.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From rjh at sixdemonbag.org  Fri Aug 28 19:36:24 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Fri, 28 Aug 2015 13:36:24 -0400
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E099A4.2080602@vulcan.xs4all.nl>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl> <55E091C0.3050905@sixdemonbag.org>
 <55E099A4.2080602@vulcan.xs4all.nl>
Message-ID: <55E09C18.9060207@sixdemonbag.org>

> Reading encrypted archives might be useful,

Then keep a copy of PGP 2.6 around.

But don't expect GnuPG, which exists to provide a libre implementation
of OpenPGP and S/MIME, to support ClassicPGP.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1016 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150828/d92a2c04/attachment.sig>

From marko.bauhardt at mailbox.org  Fri Aug 28 21:15:55 2015
From: marko.bauhardt at mailbox.org (Marko Bauhardt (private))
Date: Fri, 28 Aug 2015 21:15:55 +0200
Subject: uploading subkeys
Message-ID: <BE7D6933-3133-401A-B77C-7DDD3117A59D@mailbox.org>

Hi,
i have a keyring which contains a master key for certification and 3 sub keys, one for encryption, one for sign and the third one for authentication.
So my question is which key should i upload to a key server. I mean should i upload the master key id via `gpg ?send-key <EMAIL>` / `gpg ?send-key <MASTERKEY>` or should i send sub key after by  sub key. For example first the encryption key and after that the key for signing, via `gpg -send-key <SUBKEY>!`?

What is the difference between uploading the master key and uploading the sub keys separately? I have the feeling that it make sense to share my public key for encryption and my public key for signing separately.
Which key server do you recommend to use?

Thx
Marko



From juanmi.3000 at gmail.com  Fri Aug 28 22:54:55 2015
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Fri, 28 Aug 2015 22:54:55 +0200
Subject: uploading subkeys
In-Reply-To: <BE7D6933-3133-401A-B77C-7DDD3117A59D@mailbox.org>
References: <BE7D6933-3133-401A-B77C-7DDD3117A59D@mailbox.org>
Message-ID: <55E0CA9F.2070208@gmail.com>

You can either upload the whole public set or none of it, you can't or
at least I know of no way of uploading only the public part of the subkeys.

As for the keyserver, I recommend sks-keyservers.net[1], either
hkp://pool.sks-keyservers.net or hkps://hkps.pool.sks-keyservers.net
which you will need to have a GnuPG compiled with GnuTLS support and
also the cert from the keyserver[2]

[1]: https://sks-keyservers.net/
[2]: https://sks-keyservers.net/overview-of-pools.php#pool_hkps

On 2015-08-28 at 21:15, Marko Bauhardt (private) wrote:
> Hi,
> i have a keyring which contains a master key for certification and 3
> sub keys, one for encryption, one for sign and the third one for
> authentication.
> So my question is which key should i upload to a key server. I mean
> should i upload the master key id via `gpg ?send-key <EMAIL>` / `gpg
> ?send-key <MASTERKEY>` or should i send sub key after by  sub key.
> For example first the encryption key and after that the key for
> signing, via `gpg -send-key <SUBKEY>!`?
>
> What is the difference between uploading the master key and
> uploading the sub keys separately? I have the feeling that it make
> sense to share my public key for encryption and my public key for
> signing separately.
> Which key server do you recommend to use?
>
> Thx
> Marko


_______________________________________________
Gnupg-users mailing list
Gnupg-users at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF


From wk at gnupg.org  Fri Aug 28 23:27:50 2015
From: wk at gnupg.org (Werner Koch)
Date: Fri, 28 Aug 2015 23:27:50 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E096DA.2050503@vulcan.xs4all.nl> (Johan Wevers's message of
 "Fri, 28 Aug 2015 19:14:02 +0200")
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl> <55E08877.70808@digitalbrains.com>
 <55E096DA.2050503@vulcan.xs4all.nl>
Message-ID: <87y4gvksrt.fsf@vigenere.g10code.de>

On Fri, 28 Aug 2015 19:14, johanw at vulcan.xs4all.nl said:

> It's starting to feel a little bit with ECC not coming to 1.4 (missing
> function required to exchange messages with 2.1 users) and v3 key

If we would add ECC support to 1.4, it would end up as a rewrite of 2.1
with the only difference that all modules would be lumped together into
one large binary. 

You want better software?  Then make it less complex and separate tasks
- 2.x does just that - since 2003.


Salam-Shalom,

   Werner


ps.
Anyone still insisting on using BIND 4?

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



From listofactor at mail.ru  Fri Aug 28 22:41:31 2015
From: listofactor at mail.ru (listo factor)
Date: Fri, 28 Aug 2015 20:41:31 +0000
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF59E1.6090109@sixdemonbag.org>
References: <55DF59E1.6090109@sixdemonbag.org>
Message-ID: <55E0C77B.1030306@mail.ru>

On 08/27/2015 06:41 PM, Robert J. Hansen wrote:
>
> My rationale for this is simple: we don't want to encourage new users to
> use 1.4.  We want to encourage new users to use 2.0 and/or 2.1.
> ...
> I, personally, don't think it's a big deal to drop mention of 1.4 except
> to talk about "it's for system administrators, not regular users".
> However, I'd really like to hear your feedback on this.  Should we make
> this change?  Yes or no?

NO!

Those that use GPG as a matter of principle or because of "geek appeal"
have no problem with TSR ("terminate-but-stay-resident" :) components 
and the fallacy of "always on-line and trusted" computer. Those that
use GPG because they need to, depend on 1.4.




From philip.jackson at nordnet.fr  Fri Aug 28 22:30:02 2015
From: philip.jackson at nordnet.fr (Philip Jackson)
Date: Fri, 28 Aug 2015 22:30:02 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55DF59E1.6090109@sixdemonbag.org>
References: <55DF59E1.6090109@sixdemonbag.org>
Message-ID: <55E0C4CA.3050807@nordnet.fr>

On 27/08/15 20:41, Robert J. Hansen wrote:
> I, personally, don't think it's a big deal to drop mention of 1.4 except
> to talk about "it's for system administrators, not regular users".
> However, I'd really like to hear your feedback on this.  Should we make
> this change?  Yes or no?

Yes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150828/809789a7/attachment.sig>

From wk at gnupg.org  Sat Aug 29 13:01:05 2015
From: wk at gnupg.org (Werner Koch)
Date: Sat, 29 Aug 2015 13:01:05 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E0C77B.1030306@mail.ru> (listo factor's message of "Fri, 28
 Aug 2015 20:41:31 +0000")
References: <55DF59E1.6090109@sixdemonbag.org> <55E0C77B.1030306@mail.ru>
Message-ID: <87pp26l5ou.fsf@vigenere.g10code.de>

On Fri, 28 Aug 2015 22:41, listofactor at mail.ru said:

> have no problem with TSR ("terminate-but-stay-resident" :) components
> and the fallacy of "always on-line and trusted" computer. Those that
> use GPG because they need to, depend on 1.4.

Sorry, I do not understand what you are saying. 


Shalom-Salam,

   Werner

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



From dkbryant at gmail.com  Sat Aug 29 19:13:21 2015
From: dkbryant at gmail.com (Dan Bryant)
Date: Sat, 29 Aug 2015 12:13:21 -0500
Subject: OSX: How to install gpg without Admin password
In-Reply-To: <55DEAEB7.6020201@enigmail.net>
References: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA__259.692516601895$1440609547$gmane$org@mail.gmail.com>
 <55DEAEB7.6020201@enigmail.net>
Message-ID: <CAAUFj11OtD-AgoBBjQEpd2Ay-1ZtTanE+Xiqx+h2sZ0DP-_cZA@mail.gmail.com>

OK, this worked in getting the binaries extracted and by setting PATH
and DYNLD_LIBRARY_PATH I can get the bins to load and dump version
information... SUCCESS...

Now my biggest problem is getting the agent and pinentry (I assume) to
talk to gpg.

I was hoping I could set bindir, libdir, libexecdir with gpgconf
(gpgconf.conf) but I can't seem to figure out how to convice gpg to
look in nonstandard paths for binaries and libraries.  Seems to be
ignoring PATH environment.

Suggestions?

On Thu, Aug 27, 2015 at 1:31 AM, Patrick Brunschwig
<patrick at enigmail.net> wrote:
> On 26.08.15 17:16, Dan Bryant wrote:
>> I have a monitored OS X laptop that I would like to put GNU Privacy
>> Guard (gpg) on. Of course I can't because I don't have Admin rights,
>> but I was hoping there is a way to install it in user space through a
>> virtual environment or chroot, or some other wizardry, or by exacting
>> the package files.
>>
>> Obviously I only need console access to the app.
>
>
> Just download a DMG file, open (=mount) it, and copy the PKG file to
> some temporary location. Then use pkgutil in a terminal to unpack the
> PKG file to some temp directory. Then copy whatever you need to your
> home directory.
>
> man pkgutil will tell you how to use it.
>
> -Patrick


From rjh at sixdemonbag.org  Sat Aug 29 21:47:09 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sat, 29 Aug 2015 15:47:09 -0400
Subject: The FAQ's 4GiB recommendation
In-Reply-To: <871tenooow.fsf@vigenere.g10code.de>
References: <55DF7CF1.406@sixdemonbag.org> <871tenooow.fsf@vigenere.g10code.de>
Message-ID: <78EB75B8-767D-4EAB-BB33-2B33F6D95ACD@sixdemonbag.org>

> What do you thing of
> 
>  But what happens if two identical ciphertext blocks are found in the
>  same message?
> 
> to make it more clear that this is per message?

I think it?s a good idea.  :)



From juanmi.3000 at gmail.com  Sat Aug 29 22:27:20 2015
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Sat, 29 Aug 2015 22:27:20 +0200
Subject: Can't create or import secret keys: "End of file" error. Possible old
 bug
Message-ID: <55E215A8.7070600@gmail.com>

OS: Windows 10 (Build 10240) x64
GnuPG version: 2.1.7

Whenever trying to create a new pair of keys or when importing secret
keys, it ends with End of file error and when using a created gpg-agent
daemon process via CLI it looks like if gpg-agent crashes just at the
end. No secret keys created nor imported but public keys import just fine.

As far as I searched, other GnuPG versions affected were 2.1.1[1,3,5],
2.1.2[4], 2.1.5[2] on Windows versions 8 x64[5], 8.1 with no
architecture given[4] and 8.1 x64[1,2,3]. Versions 2.1.3 and 2.1.4 were
mentioned on Issue 1819[1] with no info of its success.

On my experience, it didn't affect Windows 7 x64 with GnuPG version
either 2.1.1 or 2.1.2, which was when I created my first ECC key, nor
Windows 7 x86 with GnuPG 2.1.7 (just tested on a VM), so the assumption
is it affects all GnuPG 2.1 versions up to 2.1.7 while using a x64-based
Windows version equal or higher than Windows 8. I could try setting up a
Windows 10 x86 VM but it may take a while.

Attached are logs of both creation and importing of keys for both GnuPG
CLI tracing and GPG Agent with some parts skipped or replaced in some
way. I'm fine with creating a shareable secret key for testing and show
the skipped parts if needed.

Also, if this has to be continued on a bug report, should Issue 1819 or
2010 be continued or should it be on a new one?

[1]: https://bugs.gnupg.org/gnupg/issue1819
[2]: https://bugs.gnupg.org/gnupg/issue2010
[3]:
https://www.reddit.com/r/GnuPG/comments/2r37qf/importing_my_private_key_to_gnupg_21_fails/
[4]:
https://www.thunderbird-mail.de/index.php/Thread/69202-Enigmail-PGP-Import-von-privatem-Schl%C3%BCssel-funktioniert-nicht/
[4b]: (Google Translate version) https://goo.gl/PYj7Bh
[5]: https://lists.gnupg.org/pipermail/gnupg-users/2015-January/052100.html

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF
-------------- next part --------------
?Microsoft Windows [Versi?n 10.0.10240]
(c) 2015 Microsoft Corporation. Todos los derechos reservados.

C:\Users\Usuario>gpg --debug-all --verbose --import .\Desktop\secrets.key
gpg: Note: no default option file 'C:/Users/Usuario/AppData/Roaming/gnupg/gpg.conf'
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: fd_cache_open (.\Desktop\secrets.key) not cached
gpg: DBG: iobuf-1.0: open '.\Desktop\secrets.key' fd=440
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf-1.1: push 'armor_filter'
gpg: DBG: armor-filter: control: 5
gpg: DBG: iobuf chain: 1.1 'armor_filter' filter_eof=0 start=0 len=0
gpg: DBG: iobuf chain: 1.0 'file_filter(fd)' filter_eof=0 start=0 len=0
gpg: DBG: armor-filter: control: 1
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: req=8192
gpg: DBG: iobuf-1.0: underflow: got=8192 rc=0
gpg: DBG: iobuf-1.1: underflow: got=430 rc=0
gpg: DBG: parse_packet(iob=1): type=5 length=533 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: req=8192
gpg: DBG: iobuf-1.0: underflow: got=6147 rc=0
gpg: DBG: iobuf-1.1: underflow: got=8192 rc=0
gpg: DBG: parse_packet(iob=1): type=13 length=55 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=287 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=284 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=576 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=13 length=53 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=13 length=55 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=7 length=1862 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=549 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=7 length=966 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=836 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=5 length=533 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: sec  rsa4096/00000000 2014-11-17   Name <user at domain.tld>
gpg: pub  rsa4096/00000000 2014-11-17  Name <user at domain.tld>
									* * * * * *
gpg: DBG: rsa_verify    => Good
									* * * * * *
gpg: DBG: rsa_verify    => Good
									* * * * * *
gpg: DBG: rsa_verify    => Good
									* * * * * *
gpg: DBG: rsa_verify    => Good
									* * * * * *
gpg: DBG: rsa_verify    => Good
									* * * * * *
gpg: DBG: rsa_verify    => Good
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: mode=fpr  (hd=0x0265baa8)
gpg: DBG: [not enabled in the source] keydb_search leave (not found)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search_reset
gpg: DBG: keydb_search: reset  (hd=0x0265cae8)
gpg: DBG: keydb: kid_not_found_flush
gpg: DBG: build_packet() type=6
gpg: DBG: iobuf-3.0: close '?'
gpg: DBG: build_packet() type=13
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-4.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-5.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-6.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-7.0: close '?'
gpg: DBG: build_packet() type=13
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-8.0: close '?'
gpg: DBG: build_packet() type=13
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-9.0: close '?'
gpg: DBG: build_packet() type=14
gpg: DBG: iobuf-10.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-11.0: close '?'
gpg: DBG: build_packet() type=14
gpg: DBG: iobuf-12.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-13.0: close '?'
gpg: DBG: iobuf-2.0: close '?'
gpg: C:/Users/Usuario/AppData/Roaming/gnupg/trustdb.gpg: trustdb created
gpg: using PGP trust model
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: mode=fpr  (hd=0x0265d308)
gpg: DBG: [not enabled in the source] keydb_search leave (found)
gpg: DBG: [not enabled in the source] keydb_get_keybock enter
gpg: DBG: parse_packet(iob=14): type=6 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=13 length=55 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=287 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=284 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=576 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=13 length=53 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=13 length=55 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=14 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=549 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=14 length=269 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=14): type=2 length=836 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: [not enabled in the source] keydb_get_keyblock leave
gpg: DBG: iobuf-15.0: close '?'
									* * * * * *
gpg: DBG: rsa_verify    => Good
gpg: DBG: finish_lookup: checking key 00000000 (one)(req_usage=0)
gpg: DBG:       using key 00000000
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: key 00000000: public key "Name <user at domain.tld>" imported
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=14
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: mode=long_kid  (hd=0x0265c2c8) 0000000000000000
gpg: DBG: keydb: kid_not_found_p (0000000000000000) => false
gpg: DBG: iobuf-14.0: close '?'
gpg: DBG: keydb: kid_not_found_insert (0000000000000000, 1)
gpg: DBG: [not enabled in the source] keydb_search leave (found)
gpg: DBG: [not enabled in the source] keydb_get_keybock enter
gpg: DBG: parse_packet(iob=16): type=6 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=13 length=55 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=287 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=284 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=576 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=13 length=53 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=13 length=55 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=14 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=549 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=14 length=269 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=16): type=2 length=836 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: iobuf-16.0: close '?'
gpg: DBG: [not enabled in the source] keydb_get_keyblock leave
gpg: DBG: iobuf-17.0: close '?'
									* * * * * *
gpg: DBG: finish_lookup: checking key 00000000 (all)(req_usage=0)
gpg: DBG:       using key 00000000
gpg: DBG: cache_user_id: already in cache
gpg: DBG: chan_000001C4 <- OK Pleased to meet you
gpg: DBG: connection to agent established
gpg: DBG: chan_000001C4 -> RESET
gpg: DBG: chan_000001C4 <- OK
gpg: DBG: chan_000001C4 -> OPTION allow-pinentry-notify
gpg: DBG: chan_000001C4 <- OK
gpg: DBG: chan_000001C4 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_000001C4 <- OK
gpg: DBG: chan_000001C4 -> AGENT_ID
gpg: DBG: chan_000001C4 <- ERR 67109139 Unknown IPC command <GPG Agent>
gpg: DBG: chan_000001C4 -> KEYWRAP_KEY --import
gpg: DBG: chan_000001C4 <- [ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...(2 byte(s) skipped) ]
gpg: DBG: chan_000001C4 <- OK
gpg: DBG: chan_000001C4 -> SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22Name+<user at domain.tld>%22%0A4096-bit+RSA+key,+ID+11111111,%0Acreated+2014-11-17+(main+key+ID+00000000).%0A
gpg: DBG: chan_000001C4 <- OK
gpg: DBG: chan_000001C4 -> IMPORT_KEY
gpg: DBG: chan_000001C4 <- INQUIRE KEYDATA
gpg: DBG: chan_000001C4 -> [ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...(982 byte(s) skipped) ]
gpg: DBG: chan_000001C4 -> [ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...(982 byte(s) skipped) ]
gpg: DBG: chan_000001C4 -> [ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...(24 byte(s) skipped) ]
gpg: DBG: chan_000001C4 -> END
gpg: DBG: chan_000001C4 <- [eof]
gpg: key 00000000/11111111: error sending to agent: End of file
gpg: error building skey array: End of file
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=5
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=7
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=7
gpg: DBG: free_packet() type=2
gpg: DBG: parse_packet(iob=1): type=13 length=50 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: req=8192
gpg: DBG: iobuf-1.0: underflow: got=0 rc=-1
gpg: DBG: .\Desktop\secrets.key: close fd/handle 440
gpg: DBG: fd_cache_close (.\Desktop\secrets.key) new slot created
gpg: DBG: iobuf-1.0: underflow: eof
gpg: DBG: iobuf-1.1: underflow: got=5717 rc=0
gpg: DBG: parse_packet(iob=1): type=7 length=1854 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=549 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=7 length=1854 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: parse_packet(iob=1): type=2 length=1092 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/import.c.545)
gpg: DBG: iobuf-1.1: underflow: req=8192
gpg: DBG: armor-filter: control: 3
gpg: DBG: iobuf-1.0: underflow: eof (due to filter eof)
gpg: DBG: iobuf-1.1: underflow: got=0 rc=-1
gpg: DBG: armor-filter: control: 2
gpg: DBG: iobuf-1.1: pop in underflow (!len)
gpg: DBG: iobuf chain: 1.0 '[none]' filter_eof=0 start=6147 len=6147
gpg: DBG: iobuf-1.0: underflow: eof
gpg: sec  rsa4096/22222222 2015-07-26   Name2 <user2 at domain.tld>
gpg: pub  rsa4096/22222222 2015-07-26  Name2 <user2 at domain.tld>
									* * * * * *
gpg: DBG: rsa_verify    => Good
									* * * * * *
gpg: DBG: rsa_verify    => Good
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: mode=fpr  (hd=0x0265d510)
gpg: DBG: [not enabled in the source] keydb_search leave (not found)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search_reset
gpg: DBG: keydb_search: reset  (hd=0x0265c0c0)
gpg: DBG: keydb: kid_not_found_flush
gpg: DBG: build_packet() type=6
gpg: DBG: iobuf-19.0: close '?'
gpg: DBG: build_packet() type=13
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-20.0: close '?'
gpg: DBG: build_packet() type=14
gpg: DBG: iobuf-21.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-22.0: close '?'
gpg: DBG: build_packet() type=14
gpg: DBG: iobuf-23.0: close '?'
gpg: DBG: build_packet() type=2
gpg: DBG: iobuf-24.0: close '?'
gpg: DBG: iobuf-18.0: close '?'
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: mode=fpr  (hd=0x0265c4d0)
gpg: DBG: [not enabled in the source] keydb_search leave (found)
gpg: DBG: [not enabled in the source] keydb_get_keybock enter
gpg: DBG: parse_packet(iob=25): type=6 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=25): type=13 length=50 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=25): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=25): type=14 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=25): type=2 length=549 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=25): type=14 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=25): type=2 length=1092 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: [not enabled in the source] keydb_get_keyblock leave
gpg: DBG: iobuf-26.0: close '?'
									* * * * * *
gpg: DBG: rsa_verify    => Good
gpg: DBG: finish_lookup: checking key 22222222 (one)(req_usage=0)
gpg: DBG:       using key 22222222
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: key 22222222: public key "Name2 <user2 at domain.tld>" imported
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=14
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: mode=long_kid  (hd=0x0265c8e0) 2222222222222222
gpg: DBG: keydb: kid_not_found_p (2222222222222222) => false
gpg: DBG: iobuf-25.0: close '?'
gpg: DBG: keydb: kid_not_found_insert (2222222222222222, 1)
gpg: DBG: [not enabled in the source] keydb_search leave (found)
gpg: DBG: [not enabled in the source] keydb_get_keybock enter
gpg: DBG: parse_packet(iob=27): type=6 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=27): type=13 length=50 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=27): type=2 length=573 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=27): type=14 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=27): type=2 length=549 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=27): type=14 length=525 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: parse_packet(iob=27): type=2 length=1092 (parse./home/wk/b-w32/speedo/gnupg-w32-2.1.7/g10/keydb.c.946)
gpg: DBG: iobuf-27.0: close '?'
gpg: DBG: [not enabled in the source] keydb_get_keyblock leave
gpg: DBG: iobuf-28.0: close '?'
									* * * * * *
gpg: DBG: rsa_verify    => Good
gpg: DBG: finish_lookup: checking key 22222222 (all)(req_usage=0)
gpg: DBG:       using key 22222222
gpg: DBG: cache_user_id: already in cache
gpg: DBG: chan_000001C4 -> KEYWRAP_KEY --import
gpg: error getting the KEK: Input/output error
gpg: DBG: free_packet() type=6
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=14
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=5
gpg: DBG: free_packet() type=13
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=7
gpg: DBG: free_packet() type=2
gpg: DBG: free_packet() type=7
gpg: DBG: free_packet() type=2
gpg: DBG: iobuf-1.0: underflow: eof (no filter)
gpg: DBG: iobuf-1.0: close '?'
gpg: DBG: iobuf-*.*: ioctl '.\Desktop\secrets.key' invalidate
gpg: DBG: fd_cache_invalidate (.\Desktop\secrets.key)
gpg: DBG:                 did (.\Desktop\secrets.key)
gpg: Total number processed: 5
gpg:               imported: 2
gpg:       secret keys read: 5
gpg: DBG: [not enabled in the source] keydb_new
gpg: 0 keys processed (0 validity counts cleared)
gpg: no ultimately trusted keys found
gpg: DBG: [not enabled in the source] stop
gpg: keydb: kid_not_found_table: total: 1
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 0/32768 bytes in 0 blocks

C:\Users\Usuario>
-------------- next part --------------
2015-08-29 03:15:38 gpg-agent[3656] listening on socket 'C:\Users\Usuario\AppData\Roaming\gnupg\S.gpg-agent'
2015-08-29 03:15:38 gpg-agent[3656] gpg-agent (GnuPG) 2.1.7 started
2015-08-29 03:16:10 gpg-agent[3656] handler 0x2 for fd 476 started
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> OK Pleased to meet you
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- RESET
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> OK
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- OPTION allow-pinentry-notify
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> OK
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- OPTION agent-awareness=2.1.0
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> OK
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- AGENT_ID
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> ERR 67109139 Unknown IPC command <GPG Agent>
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- KEYWRAP_KEY --import
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> [ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ...(2 byte(s) skipped) ]
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> OK
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22Name+<user at domain.tld>%22%0A4096-bit+RSA+key,+ID+11111111,%0Acreated+2014-11-17+(main+key+ID+00000000).%0A
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> OK
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- IMPORT_KEY
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC -> [[Confidential data not shown]]
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- [[Confidential data not shown]]
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- [[Confidential data not shown]]
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- [[Confidential data not shown]]
2015-08-29 03:16:10 gpg-agent[3656] DBG: chan_000001DC <- [[Confidential data not shown]]
-------------- next part --------------
Microsoft Windows [Versi?n 10.0.10240]
(c) 2015 Microsoft Corporation. Todos los derechos reservados.

C:\Users\Usuario>gpg --debug-level guru --verbose --full-gen-key
gpg (GnuPG) 2.1.7; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing cardio ipc clock lookup extprog
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: Testing
Email address: test at doma.in
Comment:
You selected this USER-ID:
    "Testing <test at doma.in>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: DBG: [not enabled in the source] start
gpg: DBG: chan_000001A4 <- OK Pleased to meet you
gpg: DBG: connection to agent established
gpg: DBG: chan_000001A4 -> RESET
gpg: DBG: chan_000001A4 <- OK
gpg: DBG: chan_000001A4 -> OPTION allow-pinentry-notify
gpg: DBG: chan_000001A4 <- OK
gpg: DBG: chan_000001A4 -> OPTION agent-awareness=2.1.0
gpg: DBG: chan_000001A4 <- OK
gpg: DBG: chan_000001A4 -> AGENT_ID
gpg: DBG: chan_000001A4 <- ERR 67109139 Unknown IPC command <GPG Agent>
gpg: DBG: chan_000001A4 -> RESET
gpg: DBG: chan_000001A4 <- OK
gpg: DBG: chan_000001A4 -> GENKEY
gpg: DBG: chan_000001A4 <- S INQUIRE_MAXLEN 1024
gpg: DBG: chan_000001A4 <- INQUIRE KEYPARAM
gpg: DBG: chan_000001A4 -> D (genkey(rsa(nbits 4:2048)))
gpg: DBG: chan_000001A4 -> END
gpg: DBG: chan_000001A4 <- INQUIRE PINENTRY_LAUNCHED 2936
gpg: DBG: chan_000001A4 -> END
gpg: DBG: chan_000001A4 <- INQUIRE PINENTRY_LAUNCHED 2828
gpg: DBG: chan_000001A4 -> END
gpg: DBG: chan_000001A4 <- [eof]
gpg: agent_genkey failed: End of file
Key generation failed: End of file
gpg: DBG: [not enabled in the source] stop
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 1344/32768 bytes in 2 blocks

C:\Users\Usuario>
-------------- next part --------------
2015-08-29 03:22:30 gpg-agent[2204] listening on socket 'C:\Users\Usuario\AppData\Roaming\gnupg\S.gpg-agent'
2015-08-29 03:22:30 gpg-agent[2204] gpg-agent (GnuPG) 2.1.7 started
2015-08-29 03:23:25 gpg-agent[2204] handler 0x2 for fd 476 started
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> OK Pleased to meet you
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- RESET
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> OK
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- OPTION allow-pinentry-notify
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> OK
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- OPTION agent-awareness=2.1.0
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> OK
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- AGENT_ID
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> ERR 67109139 Unknown IPC command <GPG Agent>
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- RESET
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> OK
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- GENKEY
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> S INQUIRE_MAXLEN 1024
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> INQUIRE KEYPARAM
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- D (genkey(rsa(nbits 4:2048)))
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- END
2015-08-29 03:23:25 gpg-agent[2204] starting a new PIN Entry
2015-08-29 03:23:25 gpg-agent[2204] DBG: connection to PIN entry established
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC -> INQUIRE PINENTRY_LAUNCHED 2936
2015-08-29 03:23:25 gpg-agent[2204] DBG: chan_000001DC <- END
2015-08-29 03:23:28 gpg-agent[2204] starting a new PIN Entry
2015-08-29 03:23:28 gpg-agent[2204] DBG: connection to PIN entry established
2015-08-29 03:23:28 gpg-agent[2204] DBG: chan_000001DC -> INQUIRE PINENTRY_LAUNCHED 2828
2015-08-29 03:23:28 gpg-agent[2204] DBG: chan_000001DC <- END
					* * * * * *
2015-08-29 03:23:33 gpg-agent[2204] DBG: storing private key
2015-08-29 03:23:33 gpg-agent[2204] S2K calibration: 3847168 -> 93ms
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150829/c2621636/attachment-0001.sig>

From peter at digitalbrains.com  Sun Aug 30 11:01:54 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 30 Aug 2015 11:01:54 +0200
Subject: The FAQ's 4GiB recommendation
In-Reply-To: <55DF7CF1.406@sixdemonbag.org>
References: <55DF7CF1.406@sixdemonbag.org>
Message-ID: <55E2C682.5020904@digitalbrains.com>

On 27/08/15 23:11, Robert J. Hansen wrote:
> For a 64-bit cipher, you'll probably wind up [...]

> A 128-bit cipher will begin to repeat after [...]

I think it's a good idea to stress you're talking about the block size,
not about the key size. Something like "a cipher with a 64 bit block size".

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From rjh at sixdemonbag.org  Sun Aug 30 11:21:41 2015
From: rjh at sixdemonbag.org (Robert J. Hansen)
Date: Sun, 30 Aug 2015 05:21:41 -0400
Subject: The FAQ's 4GiB recommendation
In-Reply-To: <55E2C682.5020904@digitalbrains.com>
References: <55DF7CF1.406@sixdemonbag.org> <55E2C682.5020904@digitalbrains.com>
Message-ID: <55E2CB25.2020202@sixdemonbag.org>

> I think it's a good idea to stress you're talking about the block size,
> not about the key size. Something like "a cipher with a 64 bit block size".

Good point; thank you!



From peter at digitalbrains.com  Sun Aug 30 11:24:00 2015
From: peter at digitalbrains.com (Peter Lebbing)
Date: Sun, 30 Aug 2015 11:24:00 +0200
Subject: The best practice of master/sub key capabilities
In-Reply-To: <CAE8XmWoUBcvvJ2Dekp6HHx0CPHnmenMYLTpNdP8ghr6K3CZu8w@mail.gmail.com>
References: <CAE8XmWrtYt0DTZ7i+n8Nb9q+vs4_JdAYe7egAiacm2H=SRSk2w@mail.gmail.com>
 <55D5EBBB.90004@digitalbrains.com> <55D6E4DE.4050803@digitalbrains.com>
 <CAE8XmWooEC=soTzC2Oogv5DD8NnJqdF7JFSQT6Uf2smBc0NkZQ@mail.gmail.com>
 <55D70221.5020108@digitalbrains.com>
 <CAE8XmWoUBcvvJ2Dekp6HHx0CPHnmenMYLTpNdP8ghr6K3CZu8w@mail.gmail.com>
Message-ID: <55E2CBB0.1020406@digitalbrains.com>

On 22/08/15 17:25, Dongsheng Song wrote:
> Now I want to create my new key like this:
> 
> sec   rsa4096/93D374EB 2015-08-22 [C]
> uid         [ultimate] example <example at someone.xyz>
> ssb   rsa2048/466D08E1 2015-08-22 [S]
> ssb   rsa2048/AD92E667 2015-08-22 [E]
> ssb   rsa2048/07DEFA25 2015-08-22 [A]
> ssb   ed25519/AE83BE7C 2015-08-22 [S]
> ssb   cv25519/0FACE148 2015-08-22 [E]
> ssb   ed25519/610E5096 2015-08-22 [A]

Sorry I forgot to answer earlier. This seems a reasonable setup. If this
makes you feel happy, go for it :). I still think RSA-4096 is a bit
much, though. People who have your public key and use an underpowered
system will see that building the trust database can take significantly
longer in checking your certifications.

I don't know when GnuPG checks subkey bindings, but that takes
significantly longer as well. Subkey bindings verify the correspondence
between a primary key and a subkey, and are part of your public key.

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>


From 2014-667rhzu3dc-lists-groups at riseup.net  Sun Aug 30 14:59:59 2015
From: 2014-667rhzu3dc-lists-groups at riseup.net (MFPA)
Date: Sun, 30 Aug 2015 13:59:59 +0100
Subject: Multiple GPG public keys with one private keys
In-Reply-To: <CAE-c3me=SVzwxmzy-f9Fno5ujNOLMO+etYLEJE2GVLxHZ2fAPg@mail.gmail.com>
References: <CAGfiMvD3g8-9BcVX_ez-1G1L-2K8eNNHUz6ttHQH7TYpEBrm+g@mail.gmail.com>
 <1466183049.20150827200824@my_localhost>
 <CAE-c3me=SVzwxmzy-f9Fno5ujNOLMO+etYLEJE2GVLxHZ2fAPg@mail.gmail.com>
Message-ID: <225155370.20150830135959@my_localhost>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Friday 28 August 2015 at 3:02:44 PM, in
<mid:CAE-c3me=SVzwxmzy-f9Fno5ujNOLMO+etYLEJE2GVLxHZ2fAPg at mail.gmail.com>,
Dionysis Zindros wrote:


> You can have multiple public/private key pairs for your
> public identities. Then you can maintain a secret
> public/private key pair that links your identities
> together. Encrypt the private keys of your public
> identities with the public key of your secret identity
> and publish them. Then all you need to decrypt any
> message sent to the public key of any of your public
> identities is the private key of your secret identity.
> Simply use your secret identity private key to decrypt
> the secret key of your public identity (which is a
> published encrypted message) and subsequently use that
> private key to decrypt the message that was
> communicated to you.

Interesting use of "simply". That procedure sounds far more
complicated than storing your various secret keys on your keyring and
having GnuPG use them in the normal way. I'm not sure what you gain in
return for the increased complexity.



> Finally, mathematically, in the bitcoin world, we've
> seen hierarchical deterministic keys. I see no reason
> why they could not be adopted in GPG also,

I did a quick search for "hierarchical deterministic keys" and found
<https://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/>.
Which tells me that if the parent public key is published and one of
the child secret keys is leaked, the parent secret key can be
calculated. So the parent key and all possible child keys are
compromised by the compromise of just one child secret key.



- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at riseup.net>

Don't learn safety rules by accident...
-----BEGIN PGP SIGNATURE-----

iQF8BAEBCgBmBQJV4v5ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwTgoH/19c4d2Lu0cHzAQbG0UR2MIS
Qv95wZOKVQA4xOKhLqzVJdqnTjT/YChEpqWmdmrMPRM5o0z1oFhrZZEFPZZheC4s
yxMMEhKuWkFfXQxUFhGr20aFropE2bvl4FJFD95NcPvLTUIUvnT/qhZkZm8AAKal
NxlwyVQVBvt4q2xH8UOXEyg359sOu96H1wr8sCuTJmkhcOb2Zy4jWPNycYTbKT1v
cm5jKbQ+WLizzYtCf7LeGbDelAk2GbJFNkw98ha8K97GTuJLxNyFHhQXTf6dAYgu
uMZYSEd6OLvIhH4AOO2W2NtAlNbC2rDIJWiOhCiSJ2GLp3JxsxCwlSrG6ohc6WOI
vgQBFgoAZgUCVeL+Y18UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45A5kAQC4DsSElGnzjlF56Y5kF/e4fqLf
+Owzf1f/E34bYz3ULgD9GGeFxYhh8rwBQcVFvvdSHWsGp0rHOvnV01DDGHyaKQI=
=QycK
-----END PGP SIGNATURE-----



From patrick at enigmail.net  Sun Aug 30 16:19:42 2015
From: patrick at enigmail.net (Patrick Brunschwig)
Date: Sun, 30 Aug 2015 16:19:42 +0200
Subject: OSX: How to install gpg without Admin password
In-Reply-To: <CAAUFj11OtD-AgoBBjQEpd2Ay-1ZtTanE+Xiqx+h2sZ0DP-_cZA__11596.7754544274$1440872399$gmane$org@mail.gmail.com>
References: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA__259.692516601895$1440609547$gmane$org@mail.gmail.com>
 <55DEAEB7.6020201@enigmail.net>
 <CAAUFj11OtD-AgoBBjQEpd2Ay-1ZtTanE+Xiqx+h2sZ0DP-_cZA__11596.7754544274$1440872399$gmane$org@mail.gmail.com>
Message-ID: <55E310FE.6080704@enigmail.net>

You'll need to set the path to pinentry in gpg-agent.conf Something like:
pinentry-program /home/xyz/pinentry-mac.app/Contents/MacOS/pinentry-mac

-Patrick

On 29.08.15 19:13, Dan Bryant wrote:
> OK, this worked in getting the binaries extracted and by setting PATH
> and DYNLD_LIBRARY_PATH I can get the bins to load and dump version
> information... SUCCESS...
> 
> Now my biggest problem is getting the agent and pinentry (I assume) to
> talk to gpg.
> 
> I was hoping I could set bindir, libdir, libexecdir with gpgconf
> (gpgconf.conf) but I can't seem to figure out how to convice gpg to
> look in nonstandard paths for binaries and libraries.  Seems to be
> ignoring PATH environment.
> 
> Suggestions?
> 
> On Thu, Aug 27, 2015 at 1:31 AM, Patrick Brunschwig
> <patrick at enigmail.net> wrote:
>> On 26.08.15 17:16, Dan Bryant wrote:
>>> I have a monitored OS X laptop that I would like to put GNU Privacy
>>> Guard (gpg) on. Of course I can't because I don't have Admin rights,
>>> but I was hoping there is a way to install it in user space through a
>>> virtual environment or chroot, or some other wizardry, or by exacting
>>> the package files.
>>>
>>> Obviously I only need console access to the app.
>>
>>
>> Just download a DMG file, open (=mount) it, and copy the PKG file to
>> some temporary location. Then use pkgutil in a terminal to unpack the
>> PKG file to some temp directory. Then copy whatever you need to your
>> home directory.
>>
>> man pkgutil will tell you how to use it.
>>
>> -Patrick



From dkbryant at gmail.com  Sun Aug 30 23:15:05 2015
From: dkbryant at gmail.com (Dan Bryant)
Date: Sun, 30 Aug 2015 16:15:05 -0500
Subject: OSX: How to install gpg without Admin password
In-Reply-To: <55E310FE.6080704@enigmail.net>
References: <CAAUFj11ixi-kmhUWunMeDn8hZF7BuD=-ue3iTHjeW-wrwp7ovA__259.692516601895$1440609547$gmane$org@mail.gmail.com>
 <55DEAEB7.6020201@enigmail.net>
 <CAAUFj11OtD-AgoBBjQEpd2Ay-1ZtTanE+Xiqx+h2sZ0DP-_cZA__11596.7754544274$1440872399$gmane$org@mail.gmail.com>
 <55E310FE.6080704@enigmail.net>
Message-ID: <CAAUFj131CFH48+xK+BJ=W5mZFwKs2k2-KPRGQ1z937CQpw792A@mail.gmail.com>

COMPLETE SUCCESS.

I had to add the *-program argument to both the gpg and gpg-agent
config files.  Below is very very crude shell script to show others
how it was done.  The script wasn't tested as is, but rather was a
notepad I had open to try to record the steps as I did them.  It is
almost guaranteed to have one or two bus in it.

--
cd ~
gpgosx=http://downloads.sourceforge.net/project/gpgosx
curl -LO ${gpgosx}/GnuPG-2.1.7.dmg
curl -LO ${gpgosx}/GnuPG-2.1.7.dmg.sig
mkdir GnuPG
mkdir GnuPG/tmp
cd ~/GnuPG/tmp
7z x ../../GnuPG-2.1.7.dmg
7z x 4.hfs
tar -xf Install.pkg
cd ..
cat ./tmp/GnuPG.pkg/Payload | gunzip -dc |cpio -i
export PATH=${PATH}:`pwd`/bin
export DYLD_FALLBACK_LIBRARY_PATH=`pwd`/lib
export GNUPGHOME=${HOME}/.gnupg
echo "agent-program" \
  "`pwd`/bin/gpg-agent" \
  > ${GNUPGHOME}/gpg.conf
echo "pinentry-program" \
  "`pwd`/bin/pinentry-mac.app/Contents/MacOS/pinentry-mac" \
  > ${GNUPGHOME}/gpg-agent.conf
# this will start a gpg capable shell
bash
--

So if anyone is stumbles upon this thread later who is also trying to
get GPG on a Admin controlled Mac, hopefully this will guide the way.

Another path you could take would be to install Chrome and Mailvelope.
I know that Chrome allows "drag-and-drop" install of the browser
without Admin rights.  Once in chrome you can install the Mailvelope
extension which will give you a graphical interface for GPG
operations.  You can also export your Mailvelope key to GPG so you can
do finer manipulation of it through the shell.

Many thanks to Mr. Brunschwig for the tips along the way.

On Sun, Aug 30, 2015 at 9:19 AM, Patrick Brunschwig
<patrick at enigmail.net> wrote:
> You'll need to set the path to pinentry in gpg-agent.conf Something like:
> pinentry-program /home/xyz/pinentry-mac.app/Contents/MacOS/pinentry-mac
>
> -Patrick
>
> On 29.08.15 19:13, Dan Bryant wrote:
>> OK, this worked in getting the binaries extracted and by setting PATH
>> and DYNLD_LIBRARY_PATH I can get the bins to load and dump version
>> information... SUCCESS...
>>
>> Now my biggest problem is getting the agent and pinentry (I assume) to
>> talk to gpg.
>>
>> I was hoping I could set bindir, libdir, libexecdir with gpgconf
>> (gpgconf.conf) but I can't seem to figure out how to convice gpg to
>> look in nonstandard paths for binaries and libraries.  Seems to be
>> ignoring PATH environment.
>>
>> Suggestions?
>>
>> On Thu, Aug 27, 2015 at 1:31 AM, Patrick Brunschwig
>> <patrick at enigmail.net> wrote:
>>> On 26.08.15 17:16, Dan Bryant wrote:
>>>> I have a monitored OS X laptop that I would like to put GNU Privacy
>>>> Guard (gpg) on. Of course I can't because I don't have Admin rights,
>>>> but I was hoping there is a way to install it in user space through a
>>>> virtual environment or chroot, or some other wizardry, or by exacting
>>>> the package files.
>>>>
>>>> Obviously I only need console access to the app.
>>>
>>>
>>> Just download a DMG file, open (=mount) it, and copy the PKG file to
>>> some temporary location. Then use pkgutil in a terminal to unpack the
>>> PKG file to some temp directory. Then copy whatever you need to your
>>> home directory.
>>>
>>> man pkgutil will tell you how to use it.
>>>
>>> -Patrick
>


From 908974014 at qq.com  Mon Aug 31 07:49:06 2015
From: 908974014 at qq.com (=?utf-8?B?WmVybzA=?=)
Date: Mon, 31 Aug 2015 13:49:06 +0800
Subject: GnuPG modern can't genereate keys on my Windows
Message-ID: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>

I cleared the AppData and registry, installed https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe to D:\Program Files (x86)\GnuPG, started the command prompt, typed "gpg --full-gen-key --expert" and get an EOF error after I entered the password.
gpg (GnuPG) 2.1.7; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
   (7) DSA (set your own capabilities)
   (8) RSA (set your own capabilities)
   (9) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)
Your selection? 9
Please select which elliptic curve you want:
   (2) NIST P-256
   (3) NIST P-384
   (4) NIST P-521
   (5) Brainpool P-256
   (6) Brainpool P-384
   (7) Brainpool P-512
Your selection? 2
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 4y
Key expires at 08/30/19 12:23:32 China Standard Time
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: Anonymous
Email address: anon at example.com
Comment:
You selected this USER-ID:
    "Anonymous <anon at example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: agent_genkey failed: End of file
Key generation failed: End of file
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150831/2abf2e99/attachment-0001.html>

From juanmi.3000 at gmail.com  Mon Aug 31 13:53:48 2015
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Mon, 31 Aug 2015 13:53:48 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
Message-ID: <55E4404C.8050904@gmail.com>

I assume you are using a Windows 8 or higher. I already reported that on
another message in this same list. For some reason, making a passphrase
protected key makes GPG Agent crash.

On 2015-08-31 at 07:49, Zero0 wrote:
> I cleared the AppData and registry, installed https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe to D:\Program Files (x86)\GnuPG, started the command prompt, typed "gpg --full-gen-key --expert" and get an EOF error after I entered the password.
> gpg (GnuPG) 2.1.7; Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Please select what kind of key you want:
>    (1) RSA and RSA (default)
>    (2) DSA and Elgamal
>    (3) DSA (sign only)
>    (4) RSA (sign only)
>    (7) DSA (set your own capabilities)
>    (8) RSA (set your own capabilities)
>    (9) ECC and ECC
>   (10) ECC (sign only)
>   (11) ECC (set your own capabilities)
> Your selection? 9
> Please select which elliptic curve you want:
>    (2) NIST P-256
>    (3) NIST P-384
>    (4) NIST P-521
>    (5) Brainpool P-256
>    (6) Brainpool P-384
>    (7) Brainpool P-512
> Your selection? 2
> Please specify how long the key should be valid.
>          0 = key does not expire
>       <n>  = key expires in n days
>       <n>w = key expires in n weeks
>       <n>m = key expires in n months
>       <n>y = key expires in n years
> Key is valid for? (0) 4y
> Key expires at 08/30/19 12:23:32 China Standard Time
> Is this correct? (y/N) y
> GnuPG needs to construct a user ID to identify your key.
> Real name: Anonymous
> Email address: anon at example.com
> Comment:
> You selected this USER-ID:
>     "Anonymous <anon at example.com>"
> Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
> We need to generate a lot of random bytes. It is a good idea to perform
> some other action (type on the keyboard, move the mouse, utilize the
> disks) during the prime generation; this gives the random number
> generator a better chance to gain enough entropy.
> gpg: agent_genkey failed: End of file
> Key generation failed: End of file
> 
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150831/28c29d2a/attachment.sig>

From aheinecke at intevation.de  Mon Aug 31 18:44:30 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 31 Aug 2015 18:44:30 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
Message-ID: <1892667.MoqmGU4duf@esus>

Hi,

On Monday, August 31, 2015 01:49:06 PM Zero0 wrote:
> I cleared the AppData and registry, installed
> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe to
> D:\Program Files (x86)\GnuPG, started the command prompt, typed "gpg
> --full-gen-key --expert" and get an EOF error after I entered the
> password.

I can confirm your Problem. Even without full-gen-key or any special options.

I've opened an issue for this:
https://bugs.gnupg.org/gnupg/issue2085

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From aheinecke at intevation.de  Mon Aug 31 19:07:03 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 31 Aug 2015 19:07:03 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <55E4404C.8050904@gmail.com>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
 <55E4404C.8050904@gmail.com>
Message-ID: <1717502.cCitHcOi0v@esus>

Hi,

On Monday, August 31, 2015 01:53:48 PM Juan Miguel Navarro Mart?nez wrote:
> I assume you are using a Windows 8 or higher. I already reported that on
> another message in this same list. For some reason, making a passphrase
> protected key makes GPG Agent crash.

I think this is a different bug. When I use a pinentry from gpg4win I run into 
the gpg-agent crash described in this thread but still can do things that 
involve pinentry like signing.

If I use the pinentry-basic included in the gnupg-w32 installer I get the "No 
pinentry" error.
So it looks like pinentry-basic also has a Problem on Windows > 8.1

I've not reported a bug for this but I keep it in mind. (The issues are likely 
related)

Works fine on Windows 7 though, curious.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From guanx.bac at gmail.com  Mon Aug 31 18:13:15 2015
From: guanx.bac at gmail.com (Guan Xin)
Date: Mon, 31 Aug 2015 18:13:15 +0200
Subject: How large is the EEPROM of OpenPGP Card v2.1?
Message-ID: <CANeMGR6VxStpo0b-wY5f62H11RiZyGnkoLjLt6VLRGVHfh-3fw@mail.gmail.com>

Hi All,

(Not sure if this is the right list to discuss hardware.)

I've read "http://www.g10code.de/docs/openpgp-card-2.1.pdf"
but didn't find any information about its EEPROM size.
Anyone knows how large it is?

Thanks in advance!

Guan


From johanw at vulcan.xs4all.nl  Mon Aug 31 19:45:44 2015
From: johanw at vulcan.xs4all.nl (Johan Wevers)
Date: Mon, 31 Aug 2015 19:45:44 +0200
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <87y4gvksrt.fsf@vigenere.g10code.de>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl> <55E08877.70808@digitalbrains.com>
 <55E096DA.2050503@vulcan.xs4all.nl> <87y4gvksrt.fsf@vigenere.g10code.de>
Message-ID: <55E492C8.2040403@vulcan.xs4all.nl>

On 28-08-2015 23:27, Werner Koch wrote:

> You want better software?  Then make it less complex and separate tasks
> - 2.x does just that - since 2003.

Less complex by introducing communication issues between all separate
parts? We clearly have a different idea of complexity. Separartion of
tasks does not automatically mean separate binaries. That used to be the
Unix philosophy (there is systemd, but that's another discussion) but on
other systems that might not work as smoothly.

Just see how many issues there are with pinentry on this list.

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html



From juanmi.3000 at gmail.com  Mon Aug 31 20:02:50 2015
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Mon, 31 Aug 2015 20:02:50 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <1717502.cCitHcOi0v@esus>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
 <55E4404C.8050904@gmail.com> <1717502.cCitHcOi0v@esus>
Message-ID: <55E496CA.8010002@gmail.com>

On 2015-08-31 at 19:07, Andre Heinecke wrote:
> Hi,
> 
> On Monday, August 31, 2015 01:53:48 PM Juan Miguel Navarro Mart?nez wrote:
>> I assume you are using a Windows 8 or higher. I already reported that on
>> another message in this same list. For some reason, making a passphrase
>> protected key makes GPG Agent crash.
> 
> I think this is a different bug. When I use a pinentry from gpg4win I run into 
> the gpg-agent crash described in this thread but still can do things that 
> involve pinentry like signing.
> 

I've got no issues either using GPG4Win (Full) nor GPG4Win (Vanilla) on
Windows 10 x64 and the pinentry windows looks different, first uses a
Kleopatra-looking pinentry window, the other a GnuPG-2.1-like with the
GnuPG blue symbol.

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150831/f48a77a9/attachment.sig>

From juanmi.3000 at gmail.com  Mon Aug 31 20:26:31 2015
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Mon, 31 Aug 2015 20:26:31 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <1892667.MoqmGU4duf@esus>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com> <1892667.MoqmGU4duf@esus>
Message-ID: <55E49C57.4060504@gmail.com>

I don't know how to reply to the issue (or maybe I just can't), I wanted
to say that issues 2083[1], 2010[2] and 1819[3] may be related or just
the same. They all have the "End of file" error.

[1]: https://bugs.gnupg.org/gnupg/issue2083
[2]: https://bugs.gnupg.org/gnupg/issue2010
[3]: https://bugs.gnupg.org/gnupg/issue1819

On 2015-08-31 at 18:44, Andre Heinecke wrote:
> Hi,
> 
> On Monday, August 31, 2015 01:49:06 PM Zero0 wrote:
>> I cleared the AppData and registry, installed
>> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.1.7_20150811.exe to
>> D:\Program Files (x86)\GnuPG, started the command prompt, typed "gpg
>> --full-gen-key --expert" and get an EOF error after I entered the
>> password.
> 
> I can confirm your Problem. Even without full-gen-key or any special options.
> 
> I've opened an issue for this:
> https://bugs.gnupg.org/gnupg/issue2085
> 
> Regards,
> Andre
> 

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150831/f98e06f0/attachment.sig>

From dgouttegattat at incenp.org  Mon Aug 31 20:31:09 2015
From: dgouttegattat at incenp.org (Damien Goutte-Gattat)
Date: Mon, 31 Aug 2015 20:31:09 +0200
Subject: How large is the EEPROM of OpenPGP Card v2.1?
In-Reply-To: <CANeMGR6VxStpo0b-wY5f62H11RiZyGnkoLjLt6VLRGVHfh-3fw@mail.gmail.com>
References: <CANeMGR6VxStpo0b-wY5f62H11RiZyGnkoLjLt6VLRGVHfh-3fw@mail.gmail.com>
Message-ID: <55E49D6D.9090506@incenp.org>

On 08/31/2015 06:13 PM, Guan Xin wrote:
> I've read "http://www.g10code.de/docs/openpgp-card-2.1.pdf"
> but didn't find any information about its EEPROM size.
> Anyone knows how large it is?

It will depend on the specific implementation used.

The implementation distributed by Kernel Concepts is based on the 
BasicCard ZC7.5 from ZeitControl [1], which has a 32K EEPROM [2].


[1] http://lists.gnupg.org/pipermail/gnupg-users/2014-February/049059.html

[2] 
http://www.zeitcontrol.de/en/products/chip-cards/processor-chip-cards/basiccard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150831/416a976d/attachment-0001.sig>

From aheinecke at intevation.de  Mon Aug 31 21:01:20 2015
From: aheinecke at intevation.de (Andre Heinecke)
Date: Mon, 31 Aug 2015 21:01:20 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <55E49C57.4060504@gmail.com>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
 <1892667.MoqmGU4duf@esus> <55E49C57.4060504@gmail.com>
Message-ID: <2780603.DOCACNGTvR@esus>

Hi,

On Monday, August 31, 2015 08:26:31 PM Juan Miguel Navarro Mart?nez wrote:
> I don't know how to reply to the issue (or maybe I just can't),

I think you can't. I've already complained to Werner several times that I find 
the aspect that only "Developers" or the original reporter can add information 
to a bug report hurts bugs.g10code.com

> I wanted
> to say that issues 2083[1], 2010[2] and 1819[3] may be related or just
> the same. They all have the "End of file" error.
> 
> [1]: https://bugs.gnupg.org/gnupg/issue2083
> [2]: https://bugs.gnupg.org/gnupg/issue2010
> [3]: https://bugs.gnupg.org/gnupg/issue1819

Thanks for that list! I guess I just opened another duplicate for this
with issue 2085 :-o (Damn I thought I knew how roundup search worked but i did 
not find these.)
I've consolidated them in 2085 (because that was my bug ;-) )

2010 I guess is slightly different as it has the "No Pinentry" Problem so I've 
left that out.

Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998
Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


From juanmi.3000 at gmail.com  Mon Aug 31 21:46:59 2015
From: juanmi.3000 at gmail.com (=?UTF-8?Q?Juan_Miguel_Navarro_Mart=c3=adnez?=)
Date: Mon, 31 Aug 2015 21:46:59 +0200
Subject: GnuPG modern can't genereate keys on my Windows
In-Reply-To: <2780603.DOCACNGTvR@esus>
References: <tencent_0D977A7C7CCE2AE60C2E75AD@qq.com>
 <1892667.MoqmGU4duf@esus> <55E49C57.4060504@gmail.com>
 <2780603.DOCACNGTvR@esus>
Message-ID: <55E4AF33.2060701@gmail.com>

On 2015-08-31 at 21:01, Andre Heinecke wrote:
> 2010 I guess is slightly different as it has the "No Pinentry" Problem so I've 
> left that out.
> 
> Regards,
> Andre
> 

It could be or at least part of it may be different.

I know that I also get the "gpg: error getting the KEK: Input/output
error" when trying to import a file with multiple secret files on it
(like when you do `gpg --export-secret-keys`).

Just try it, create multiple secret keys with passphrase on GnuPG 1.4
(or GnuPG 2.0 with GPG4Win if you are fine with the rebooting after
uninstall) then install GnuPG 2.1 and try any command that may cause the
secring.gpg migration. I don't remember if I got or not any pinentry
window during migration.

-- 
Juan Miguel Navarro Mart?nez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150831/9d369d69/attachment.sig>

From misscrissylynn at gmail.com  Mon Aug 31 21:08:46 2015
From: misscrissylynn at gmail.com (Crissy Lynn)
Date: Mon, 31 Aug 2015 15:08:46 -0400
Subject: FAQ: drop mention of 1.4?
In-Reply-To: <55E492C8.2040403@vulcan.xs4all.nl>
References: <55DF59E1.6090109@sixdemonbag.org>
 <55DF73D5.9020505@vulcan.xs4all.nl> <55DF8312.8090708@sixdemonbag.org>
 <55E06C33.30800@vulcan.xs4all.nl> <55E08877.70808@digitalbrains.com>
 <55E096DA.2050503@vulcan.xs4all.nl> <87y4gvksrt.fsf@vigenere.g10code.de>
 <55E492C8.2040403@vulcan.xs4all.nl>
Message-ID: <C305DA75-0313-4F83-AFA9-D59DC8EE80BA@gmail.com>

I have tried any and everything the be taken OFF of this random mailing list!!! I've 'Unsubscribed' 10 times. Can someone PLEASE explain why I keep getting these emails!??????



> On Aug 31, 2015, at 1:45 PM, Johan Wevers <johanw at vulcan.xs4all.nl> wrote:
> 
>> On 28-08-2015 23:27, Werner Koch wrote:
>> 
>> You want better software?  Then make it less complex and separate tasks
>> - 2.x does just that - since 2003.
> 
> Less complex by introducing communication issues between all separate
> parts? We clearly have a different idea of complexity. Separartion of
> tasks does not automatically mean separate binaries. That used to be the
> Unix philosophy (there is systemd, but that's another discussion) but on
> other systems that might not work as smoothly.
> 
> Just see how many issues there are with pinentry on this list.
> 
> -- 
> ir. J.C.A. Wevers
> PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html
> 
> 
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


From guanx.bac at gmail.com  Mon Aug 31 23:23:17 2015
From: guanx.bac at gmail.com (Guan Xin)
Date: Mon, 31 Aug 2015 23:23:17 +0200
Subject: How large is the EEPROM of OpenPGP Card v2.1?
In-Reply-To: <55E49D6D.9090506@incenp.org>
References: <CANeMGR6VxStpo0b-wY5f62H11RiZyGnkoLjLt6VLRGVHfh-3fw@mail.gmail.com>
 <55E49D6D.9090506@incenp.org>
Message-ID: <CANeMGR7yL=bPNySsD9BA_YLA7iBJfe9vGQcAMy0-gitJ3CeCCg@mail.gmail.com>

On Mon, Aug 31, 2015 at 8:31 PM, Damien Goutte-Gattat
<dgouttegattat at incenp.org> wrote:
>
> It will depend on the specific implementation used.
>
> The implementation distributed by Kernel Concepts is based on the BasicCard
> ZC7.5 from ZeitControl [1], which has a 32K EEPROM [2].
>
>
> [1] http://lists.gnupg.org/pipermail/gnupg-users/2014-February/049059.html
>
> [2] http://www.zeitcontrol.de/en/products/chip-cards/processor-chip-cards/basiccard
>

Thank you, Damien! Very helpful links. Everything is clear.

Guan

On Mon, Aug 31, 2015 at 8:31 PM, Damien Goutte-Gattat
<dgouttegattat at incenp.org> wrote:
> On 08/31/2015 06:13 PM, Guan Xin wrote:
>>
>> I've read "http://www.g10code.de/docs/openpgp-card-2.1.pdf"
>> but didn't find any information about its EEPROM size.
>> Anyone knows how large it is?
>
>
> It will depend on the specific implementation used.
>
> The implementation distributed by Kernel Concepts is based on the BasicCard
> ZC7.5 from ZeitControl [1], which has a 32K EEPROM [2].
>
>
> [1] http://lists.gnupg.org/pipermail/gnupg-users/2014-February/049059.html
>
> [2]
> http://www.zeitcontrol.de/en/products/chip-cards/processor-chip-cards/basiccard
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>