Re: Forward gpg-agent to container

[Phil Pennock]

On 2018-06-10 at 18:05 +0200, Benjamin Kircher wrote:
> This gives me
> 
>   gpg: can't connect to the agent: IPC connect call failed
> 
> from within the container.
> 
> Command lines that led to this output are:
> 
>   $ docker run --volume $(gpgconf --list-dirs 
> agent-extra-socket):/root/.gnupg/S.gpg-agent --entrypoint=sh -ti --rm 
> fedora:latest

Did you do something to start the agent in the parent Linux host before
trying to forward the socket?

I can run that Docker image just fine, using the same approach, and
things work for me.

But once you're isolating processes between different virtual operating
systems, none of GnuPG's facilities for auto-launching processes will
help you.

Run:

gpg-connect-agent /bye

in the non-Docker environment before starting the Docker commands.  That
command will ensure that the agent is running, then disconnect from the
running agent.

It might be that you have SELinux preventing the volume mount; if
tacking ':z' onto the end of the volume spec works, that would be the
cause.

  docker run -it --rm \
--volume $(gpgconf --list-dirs 
agent-extra-socket):/root/.gnupg/S.gpg-agent:z \
--entrypoint=sh fedora:latest



I am not using Linux with SELinux to run Docker anywhere, so can't be of
any further help in debugging if this is the cause; warning notes online
suggest extreme caution is warranted when using the `z` mount option,
you'll need to test carefully to make sure that GnuPG _outside_ of
Docker still works afterwards.  (If not ... `gpgconf --kill gpg-agent`
and continue on).

-Phil

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

Re: Hard to find alternate source of checksums

[Lee]

On 6/11/18, NdK   wrote:
> Il 09/06/2018 19:08, Jeff Martin ha scritto:
>> For a fresh install of GnuPG, I was following the integrity check
>> directions. I have no prior version for GnuPG.
> Why not fetch some (unrelated) live distributions, possibly some older
> ones and some newer ones?
>
> GPG is usually included and you can use it to check the signatures.

If you're not trusting the checksums listed on the website you're not
trusting the signing key fingerprints listed on the site either.  So
you still need to find a release announcement on 2 or 3 different
sites to check the signing key fingerprints.  And know enough to make
sure the auto key retrieval function in GPG is turned off in your live
distro

Lee

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

Re: v1.4.22: re--importing --export'ed key from --export-secret-subkeys dir cannot --encrypt

[Steffen Nurpmeso]

A nice Monday afternoon i wish, i have a post scriptum.

Steffen Nurpmeso wrote in <20180604134413.sljyg%stef...@sdaoden.eu>:
 |Last saturday i search/stumbled over an interesting Debian page
 |(Subkey.html) which describes how to generate a dedicated siging
 |subkeys, and how to create a new key pool via
 |--export-secret-subkeys which does not contain (all parts of) the
 |real private key, so that the secret key can be stored "somewhere
 |else" but the newly reimported secret (sub)key can still be used
 |for signing purposes.
 ...
 |(sorry), i cannot find a bug in the bug-db that corresponds to the
 |behaviour i see, and that is that i neither can --export the
 |public key from that mutilated private key and use that one for
 |--encrypt'ion, nor can use the key itself for that (the encryption
 |key seems "hidden", but if i "toggle" --edit-key then i can see it
 |still).  But i can use it for signing purposes.

So i ended up with two directories, pgp-backup.git without
secring.gpg and only the public key which can encrypt, and
pgp.git, which is ~/.gnupg, has the mutilated private key, and can
sign.

Just ten minutes ago however i have found out that if i --export
the key from pgp-backup.git and --import it into pgp.git, then the
latter gains encryption capabilities again!  I thought i had tried
that with the GNUPGHOME which has the full private key, and
failed, but maybe i was in a state of confusion by then (already).
Anyway, this new --import mysteriously said

  Reading passphrase from file descriptor 4
  gpg: key ... 2 new signatures
  gpg: key .. 1 new subkey
  gpg: Total number processed: 1
  gpg:new subkeys: 1
  gpg: new signatures: 2

and i now have the signature for the newly created signing subkey
two times, and encryption works.
~/.gnupg is now fully functional again!

Ciao from within the Greyness,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Expire a single UID

[Damien Goutte-Gattat via Gnupg-users]

Hi,

On 06/11/2018 09:30 AM, Max-Julian Pogner wrote:
> *) should i revoke the uid on the old key? => However, as far as i 
> know, the secret key is not / was never compromised.

This is probably the best option in my opinion, since you will no longer
use that key with this email address.

Revoking a UID is not the same as revoking a key, and does not imply
that the associated secret key has been compromised (if a key has
been compromised you should revoke the key itself, not the UID). Most
often it simply means "I no longer use that UID". Note that when
revoking the UID you will have the option of specifying a reason for the
revocation.


> *) Also, other persons have signed the UID 
> max-julian.pog...@openresearch.com at key 0x2D40BDB44401A8AA without 
> expiration date. What should they do?

With regard to your old key, they don't have anything to do. Your
revocation of the UID takes precedence over their signatures.

With regard to your new key, you might want to ask them if they could
sign it. One way to do that is to send them an email signed by both the
old key and the new key, so that they know you control both keys.


> Thanks for any hints!

Here's another possibility: Have you considered using an OpenPGP card?
This would allow you to keep your private keys under your control, even
when you use them on your employer-provided system.


Hope that helps,

Damien



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

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Werner Koch]

On Mon, 11 Jun 2018 10:06, marco.maggi-i...@poste.it said:

> I fixed  this by upgrading to  the latest libgpg-error.  This  means the
> gnupg  package  does  not  detect  the  installed  libgpg-error  version
> correctly?

Merge fault, sorry.  See https://dev.gnupg.org/T4012 for a fix.


Salam-Shalom,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpmHS3Suufhb.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Werner Koch]

On Mon, 11 Jun 2018 11:07, pe...@digitalbrains.com said:

> attempt to decrypt the block in the first message by Werner, as soon as
> it was part of a quote, starting with ">   ", Enigmail will try to
> process it. Type in the passphrase "abc" without quotes, and you'll

I'd call that a TB bug.  There was a reason why I indented that PGP
block.


Shalom-Salam,

   Werner


-- 
# Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken
sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpLUF75Nwu7s.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Juergen Bruckner]

I did NOT encrypt the Message, just signed it with my PGP-Key - This
message is now without sign or encrypt

Am 2018-06-10 um 22:50 schrieb Jean-David Beyer:
> On 06/10/2018 01:25 PM, Juergen Bruckner wrote:
>> Hello Werner,
>>
>> i Use Linux Mint 18.3 with GnuPG 2.1.11; which is the easiest way to
>> Update it to 2.2.8?
>>
>>
>> I'm pretty new to the Linux-World, but as far i know i have NOT included
>> a "own" GnuPG Repo in my Repo-List.
>>
>> best regards
>> Juergen
>>
>> Am 2018-06-08 um 15:40 schrieb Werner Koch:
>>> Hello!
>>>
>>> We are pleased to announce the availability of a new GnuPG release:
>>> version 2.2.8.  This version fixes a critical security bug and comes
>>> with some other minor changes.
>>>
>>>
>>> Impact
>>> ==
>>>
>>> All current GnuPG versions are affected on all platforms.
>>>
>>> All mail clients and other applications which make use of GPG but are
>>> not utilizing the GPGME library might be affected.
>>>
>>> The OpenPGP protocol allows to include the file name of the original
>>> input file into a signed or encrypted message.  During decryption and
>>> verification the GPG tool can display a notice with that file name.  The
>>> displayed file name is not sanitized and as such may include line feeds
>>> or other control characters.  This can be used inject terminal control
>>> sequences into the out and, worse, to fake the so-called status
>>> messages.  These status messages are parsed by programs to get
>>> information from gpg about the validity of a signature and an other
>>> parameters.  Status messages are created with the option "--status-fd N"
>>> where N is a file descriptor.  Now if N is 2 the status messages and the
>>> regular diagnostic messages share the stderr output channel.  By using a
>>> made up file name in the message it is possible to fake status messages.
>>> Using this technique it is for example possible to fake the verification
>>> status of a signed mail.
>>>
>>> Although GnuPG takes great care to sanitize all diagnostic and status
>>> output, the case at hand was missed but finally found and reported by
>>> Marcus Brinkmann.  CVE-2018-12020 was assigned to this bug; GnuPG tracks
>>> it at .
>>>
>>>
>>> Solution
>>> 
>>>
>>> If your application uses GPGME your application is safe.  Fortunately
>>> most modern mail readers use GPGME, including GpgOL and KMail.  Mutt
>>> users should make sure to use "set crypt_use_gpgme".
>>>
>>> If you are parsing GnuPG status output and you use a dedicated file
>>> descriptor with --status-fd you are safe.  A dedicated file descriptor
>>> is one that is not shared with the log output.  The log output defaults
>>> to stderr (2) but may be a different if the option --logger-fd is used.
>>>
>>> If you are not using --verbose you are safe.  But take care: --verbose
>>> might be specified in the config file.  As a short term mitigation or if
>>> you can't immediately upgrade to the latest versions, you can add
>>> --no-verbose to the invocation of gpg.
>>>
>>> Another short term mitigation is to redirect the log output to a
>>> different file: For example "--log-file /dev/null".
>>>
>>> The suggested solution is to update to GnuPG 2.2.8 or a vendor provided
>>> update of their GnuPG version.
>>>
>>> To check whether the bug has been fixed you may use the simple test at
>>> the end of this mail [1].
>>>
>>>
>>> About GnuPG
>>> ===
>>>
>>> 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.  As an Universal Crypto
>>> Engine 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.
>>>
>>>
>>> Noteworthy changes in version 2.2.8
>>> ===
>>>
>>>   * gpg: Decryption of messages not using the MDC mode will now lead
>>> to a hard failure even if a legacy cipher algorithm was used.  The
>>> option --ignore-mdc-error can be used to turn this failure into a
>>> warning.  Take care: Never use that option unconditionally or
>>> without a prior warning.
>>>
>>>   * gpg: The MDC encryption mode is now always used regardless of the
>>> cipher algorithm or any preferences.  For testing --rfc2440 can be
>>> used to create a message without an MDC.
>>>
>>>   * gpg: Sanitize the diagnostic output of the original file name in
>>> verbose mode.  [#4012,CVE-2018-12020]
>>>
>>>   * gpg: Detect suspicious mu

Expire a single UID

[Max-Julian Pogner]

Hello there!

I have quite a problem with properly bisecting a UID from my key. Maybe
someone can help me?

Here's the situation:

This is currently my GnuPG-Key, and will remain my primar key:
https://pgp.mit.edu/pks/lookup?op=get&search=0x2D40BDB44401A8AA
https://pogner.at/gnupg/0x2D40BDB44401A8AA.gpg

However, my contract with OpenResearch changes from freelancer to
hired-employee. As a consequence, i will stop using my own
Infrastructure but using their pc. Therefore, i will also read and write
emails from the new work-pc.
But i do not want to copy my secret key 0x2D40BDB44401A8AA to the new
work-pc (which is very much their property and not under my full
administrative control but under their company-it administrative control).

Therefore, my current plan is to simply generate a completely new secret
key with UID max-julian.pog...@openresearch.com. This also will not be a
problem with the customers where gnupg is actually in use (less than 5
persons to be honest).

Now there is a problem: Then there will be two keys published for
max-julian.pog...@openresearch.com! This surely will cause confusion.

*) should i revoke the uid on the old key? => However, as far as i know,
the secret key is not / was never compromised.
*) the UIDs were certified by me and by other persons without expiration
dates. => I can change the expiration date of the primary key and
subkeys using "gpg2 --edit-key" and "expire", but the UID remains valid
forever.
*) Also, other persons have signed the UID
max-julian.pog...@openresearch.com at key 0x2D40BDB44401A8AA without
expiration date. What should they do?


Thanks for any hints!

Max





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

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Juergen Bruckner]

> (Could you please trim your quotes? Incidentally, this would have
> prevented the problem in the first place, both on the first and on your
> reply).
> 
Thanks for the hint


> It would appear that at least Enigmail (mine is from Debian
> stable/stretch) ignores an inline encrypted block if it is indented, but
> interprets it if it is quoted *and* indented. So while there was no
> attempt to decrypt the block in the first message by Werner, as soon as
> it was part of a quote, starting with ">   ", Enigmail will try to
> process it. Type in the passphrase "abc" without quotes, and you'll
> decrypt the test message part of the announcement.
> 
and thanks again for the info

regards
Juergen

-- 
Juergen M. Bruckner
juer...@bruckner.tk



smime.p7s
Description: S/MIME Cryptographic Signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Peter Lebbing]

(Could you please trim your quotes? Incidentally, this would have
prevented the problem in the first place, both on the first and on your
reply).

On 10/06/18 22:50, Jean-David Beyer wrote:
> It says part of your message to me was encrypted and prompted me for my
> passphrase, but it must not have been encrypted with my public key.

It would appear that at least Enigmail (mine is from Debian
stable/stretch) ignores an inline encrypted block if it is indented, but
interprets it if it is quoted *and* indented. So while there was no
attempt to decrypt the block in the first message by Werner, as soon as
it was part of a quote, starting with ">   ", Enigmail will try to
process it. Type in the passphrase "abc" without quotes, and you'll
decrypt the test message part of the announcement.

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 



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

Re: Hard to find alternate source of checksums

[NdK]

Il 09/06/2018 19:08, Jeff Martin ha scritto:
> For a fresh install of GnuPG, I was following the integrity check
> directions. I have no prior version for GnuPG.
Why not fetch some (unrelated) live distributions, possibly some older
ones and some newer ones?

GPG is usually included and you can use it to check the signatures.

BYtE,
 Diego

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

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Marco Maggi]

"Marco Maggi" wrote:
>mainproc.c:686:14: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this 
>function); did you mean 'GPGRT_LOG_INFO'?

I fixed  this by upgrading to  the latest libgpg-error.  This  means the
gnupg  package  does  not  detect  the  installed  libgpg-error  version
correctly?
-- 
Marco Maggi

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

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Bernhard Reiter]

Hello,
two fixes for the anouncement:

>CVE-2018-12020 was assigned to this bug; GnuPG tracks
> it at .

  https://dev.gnupg.org/T4012

> and pass to this pipeline
>
>   gpg --no-options -vd 2>&1 | grep '^\[GNUPG:] INJECTED'

enter the needed passphrase 'abc' in your pinentry.

Regards,
Bernhard


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: [Announce] [security fix] GnuPG 2.2.8 released (CVE-2018-12020)

[Marco Maggi]

Ciao,

  running"make"   failswithundeclaredsymbol.Onmy
x86_64-pc-linux-gnu (Slackware) I downloaded:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.8.tar.bz2

configured with:

   configure --prefix=/usr/local --libdir=/usr/local/lib64 CFLAGS=-O3

I get this report:

GnuPG v2.2.8 has been configured as follows:

Revision:  cd9aaa786  (52634)
Platform:  GNU/Linux (x86_64-pc-linux-gnu)

OpenPGP:   yes
S/MIME:yes
Agent: yes
Smartcard: yes 
G13:   no
Dirmngr:   yes
Gpgtar:yes
WKS tools: no

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

Dirmngr auto start:  yes
Readline support:yes
LDAP support:yes
TLS support: gnutls
TOFU support:yes
Tor support: yes

when running make I get:

gcc -DHAVE_CONFIG_H -I. -I..  -DLOCALEDIR=\"/usr/local/share/locale\" 
-DGNUPG_BINDIR="\"/usr/local/bin\"" -DGNUPG_LIBEXECDIR="\"/usr/local/libexec\"" 
-DGNUPG_LIBDIR="\"/usr/local/lib64/gnupg\"" 
-DGNUPG_DATADIR="\"/usr/local/share/gnupg\"" 
-DGNUPG_SYSCONFDIR="\"/usr/local/etc/gnupg\"" 
-DGNUPG_LOCALSTATEDIR="\"/usr/local/var\""-I/usr/local/include 
-I/usr/local/include -I/usr/local/include -I/usr/local/include -Wall 
-Wno-pointer-sign -Wpointer-arith -O3 -MT mainproc.o -MD -MP -MF 
.deps/mainproc.Tpo -c -o mainproc.o mainproc.c
mainproc.c: In function 'proc_encrypted':
mainproc.c:686:14: error: 'GPGRT_LOGLVL_INFO' undeclared (first use in this 
function); did you mean 'GPGRT_LOG_INFO'?
 (GPGRT_LOGLVL_INFO,
  ^
  GPGRT_LOG_INFO
mainproc.c:686:14: note: each undeclared identifier is reported only once for 
each function it appears in
Makefile:875: recipe for target 'mainproc.o' failed

and:

   $ grep GPGRT_LOGLVL_INFO * --recursive
   g10/mainproc.c:(GPGRT_LOGLVL_INFO,

  I cannot believe that I am the only one getting this error.

TIA
-- 
Marco Maggi

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