Hard to find alternate source of checksums

[Jeff Martin]

For a fresh install of GnuPG, I was following the integrity check
directions. I have no prior version for GnuPG.

https://gnupg.org/download/integrity_check.html

They read "...find the announcement on several other websites and make
sure the checksum is consistent." This task is difficult to accomplish
using search engines such a DuckDuckGo or Google. The search terms
that yielded the best results were merely the full file name enclosed
in double quotes.

I eventually found an alternate source of the checksums solely from
search results for all files except "ntbtls-0.1.2.tar.bz2", oddly. I'm
not sure what makes that one special. Also, I felt I was relying too
much on www.linuxfromscratch.org as my alternate source.

Do you have any specific tips for how to find alternate checksum sources?

Thanks.



--
Jeff Martin

___
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)

[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 multiple plaintext packets in a more
>> reliable way.  [#4000]
>>
>>   * gpg: Fix the duplicate key signature detection code.  [#3994]
>>
>>   * gpg: The options --no-mdc-warn, --force-mdc, --no-force-mdc,
>> --disable-mdc and --no-disable-mdc have no more 

Re: Forward gpg-agent to container

[Benjamin Kircher]

> On 10. Jun 2018, at 18:05, Benjamin Kircher  
> wrote:
> 
> 
> 
>> On 6. Jun 2018, at 02:27, Phil Pennock  wrote:
>> 
>> On 2018-06-05 at 17:17 -0400, Phil Pennock wrote:
>>> Shell 2:
>>> $ docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent.ssh 
>>> alpine
>>> / # chmod 0700 /root/.gnupg && chown root:root /root/.gnupg/S.gpg-agent
>>> / # apk update && apk add --no-cache gnupg
>> 
>> I apologise, I missed fixing one glitch in review before sending.
>> 
>> The correct command to invoke Docker here is:
>> 
>> docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent alpine
>> 
>> Don't use the `.ssh` name, that speaks an entirely different protocol
>> and was a mental glitch when I first wrote the above, fixed in testing
>> but not repaired in the email.
>> 
>> The command-line if you're running on Linux should thus be (untested):
>> 
>> docker run -it --rm -v 
>> $HOME/.gnupg/S.gpg-agent.extra:/root/.gnupg/S.gpg-agent alpine
>> 
>> Adjust as appropriate for other images.
> 
> 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
> 
> And the inside the container:
> 
>  # chmod 700 ~/.gnupg
>  # gpg2 --keyserver pgp.uni-mainz.de --recv-keys 
>  # gpg2 --list-secret-keys

To amend last message, reported errors and logs are:

# gpg-connect-agent "keyinfo --list" /bye
gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: waiting for the agent to come up ... (4s)
gpg-connect-agent: waiting for the agent to come up ... (3s)
gpg-connect-agent: waiting for the agent to come up ... (1s)
gpg-connect-agent: can't connect to the agent: IPC connect call failed
gpg-connect-agent: error sending standard options: No agent running
sh-4.4# cat /tmp/gpg-agent.log 
2018-06-10 16:21:15 gpg-agent[10] error binding socket to 
'/root/.gnupg/S.gpg-agent': Address already in use
2018-06-10 16:21:15 gpg-agent[10] random usage: poolsize=600 mixed=0 polls=0/0 
added=0/0
  outmix=0 getlvl1=0/0 getlvl2=0/0
2018-06-10 16:21:15 gpg-agent[10] rndjent stat: collector=0x 
calls=0 bytes=0
2018-06-10 16:21:15 gpg-agent[10] secmem usage: 0/65536 bytes in 0 blocks

BK


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

Re: Forward gpg-agent to container

[Benjamin Kircher]

> On 6. Jun 2018, at 02:27, Phil Pennock  wrote:
> 
> On 2018-06-05 at 17:17 -0400, Phil Pennock wrote:
>> Shell 2:
>> $ docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent.ssh 
>> alpine
>> / # chmod 0700 /root/.gnupg && chown root:root /root/.gnupg/S.gpg-agent
>> / # apk update && apk add --no-cache gnupg
> 
> I apologise, I missed fixing one glitch in review before sending.
> 
> The correct command to invoke Docker here is:
> 
>  docker run -it --rm -v /var/run/pdp.gnupg:/root/.gnupg/S.gpg-agent alpine
> 
> Don't use the `.ssh` name, that speaks an entirely different protocol
> and was a mental glitch when I first wrote the above, fixed in testing
> but not repaired in the email.
> 
> The command-line if you're running on Linux should thus be (untested):
> 
>  docker run -it --rm -v 
> $HOME/.gnupg/S.gpg-agent.extra:/root/.gnupg/S.gpg-agent alpine
> 
> Adjust as appropriate for other images.

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

And the inside the container:

  # chmod 700 ~/.gnupg
  # gpg2 --keyserver pgp.uni-mainz.de --recv-keys 
  # gpg2 --list-secret-keys

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