Re: having trouble checking the signature of a downloaded file

2018-02-22 Thread Kristian Fiskerstrand
On 02/22/2018 11:13 PM, Kristian Fiskerstrand wrote:
> On 02/22/2018 11:03 PM, Henry wrote:
>> 2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand
>> :
>>> On 02/21/2018 11:53 AM, Peter Lebbing wrote:
>>> Touché :) Indeed, didn't notice it was an old file/signature , then
>>> gnupg 1.4 is the recommended official suggestion presuming established
>>> validity of key material etc etc.
>> gpg (GnuPG) 1.4.22 does give more information, but no success; see
>> below.  May I assume that nothing
>> can be done other than to request the author to remedy the situation?
>> Thanks all.
>>
> --allow-weak-digest-algos
> Signatures made with known-weak digest algorithms are normally
> allows the verification of signatures made with such weak algorithms.
> MD5 is the only digest algorithm considered weak by default.
> 

That was truncated;

.B  --allow-weak-digest-algos
Signatures made with known-weak digest algorithms are normally
rejected with an ``invalid digest algorithm'' message.  This option
allows the verification of signatures made with such weak algorithms.
MD5 is the only digest algorithm considered weak by default.  See also
\fB--weak-digest\fR to reject other digest algorithms.


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Varitatio delectat
Change pleases



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


Re: having trouble checking the signature of a downloaded file

2018-02-22 Thread Kristian Fiskerstrand
On 02/22/2018 11:03 PM, Henry wrote:
> 2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand
> :
>> On 02/21/2018 11:53 AM, Peter Lebbing wrote:
>> Touché :) Indeed, didn't notice it was an old file/signature , then
>> gnupg 1.4 is the recommended official suggestion presuming established
>> validity of key material etc etc.
> 
> gpg (GnuPG) 1.4.22 does give more information, but no success; see
> below.  May I assume that nothing
> can be done other than to request the author to remedy the situation?
> Thanks all.
> 

--allow-weak-digest-algos
Signatures made with known-weak digest algorithms are normally
allows the verification of signatures made with such weak algorithms.
MD5 is the only digest algorithm considered weak by default.

> Henry
> 
> result of using gnupg 1.4:
> % gpg1 --import D5327CB9.key
> gpg: key D5327CB9: "author " not changed
> gpg: Note: signatures using the MD5 algorithm are rejected
> gpg: key D5327CB9: no valid user IDs
> gpg: this may be caused by a missing self-signature
> gpg: Total number processed: 2
> gpg:   w/o user IDs: 1
> gpg:  unchanged: 1
> 
> % gpg1 --verify ***6.4.tar.gz.sig ***6.4.tar.gz
> gpg: Signature made Tue May  4 23:03:11 2004 JST using RSA key ID D5327CB9
> gpg: Can't check signature: public key not found
> 


-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

"The laws of Australia prevail in Australia, I can assure you of that.
The laws of mathematics are very commendable, but the only laws that
applies in Australia is the law of Australia."
(Malcolm Turnbull, Prime Minister of Australia).



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


Re: having trouble checking the signature of a downloaded file

2018-02-22 Thread Henry
2018-02-21 20:56 GMT+09:00 Kristian Fiskerstrand
:
> On 02/21/2018 11:53 AM, Peter Lebbing wrote:
> Touché :) Indeed, didn't notice it was an old file/signature , then
> gnupg 1.4 is the recommended official suggestion presuming established
> validity of key material etc etc.

gpg (GnuPG) 1.4.22 does give more information, but no success; see
below.  May I assume that nothing
can be done other than to request the author to remedy the situation?
Thanks all.

Henry

result of using gnupg 1.4:
% gpg1 --import D5327CB9.key
gpg: key D5327CB9: "author " not changed
gpg: Note: signatures using the MD5 algorithm are rejected
gpg: key D5327CB9: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 2
gpg:   w/o user IDs: 1
gpg:  unchanged: 1

% gpg1 --verify ***6.4.tar.gz.sig ***6.4.tar.gz
gpg: Signature made Tue May  4 23:03:11 2004 JST using RSA key ID D5327CB9
gpg: Can't check signature: public key not found

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


Re: enigmail with pgp 2.2.4

2018-02-22 Thread Dmitry Gudkov
Hi Peter,

thank for your attention to this smallest problem of mine which I
wouldn't even hope to have your attention for to begin with)

my bad, I should have started a new thread, well noted

on the other hand that's probably why I suddenly had all the big gnupg
minds helping me)

what a rewarding side effect of unwittingly breaking the housekeeping rules)

seriously now ...

it was a fresh ubuntu 16.04 install

it came with gnupg 1.4.20 and 2.1.11

i compiled gnupg 2.2.4

it worked just fine in terminal and after configuring Enigmail with the
new gpg location works there as well

do you think i still have a problem?


thank you

Dmitry



On 22.02.2018 23:17, Peter Lebbing wrote:
> On 22/02/18 18:10, Dmitry Gudkov wrote:
>> problem solved by configuring Enigmail to use the new gnupg location in
>> /usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
>> the default setting /usr/bin/gpg2)
> While my mind was idly mulling this over, I suddenly wondered if what
> you are doing is even supposed to work at all. I think perhaps you just
> haven't discovered the dire consequences of it yet.
>
> GnuPG 1.4 and 2.0 are co-installable, and will happily work installed on
> the same system.
>
> GnuPG 1.4 and 2.1+ are in the basis co-installable, but still can
> present you with issues like keyrings going out of sync or requiring
> careful crafting of configuration files, off the top of my head.
>
> But 2.0 and 2.1+ are definitely not co-installable. You can't have them
> both on the same system. Right now you put GnuPG 2.2 and its
> dependencies in /usr/local, but GnuPG 2.0 and its dependencies are still
> in /usr. Their dependencies might start to mingle.
>
> The only way in which this might work is if I misinterpreted "not
> co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
> an instance of "co-installation". But I don't think that's the case. It
> might also work by pure chance and break horribly on the next update.
>
> A solution, where GnuPG 2.1+ is statically linked against its
> dependencies, was discussed here:
> 
>
> Werner introduced the partial static linking in the just released 2.2.5.
>
>
> Oh, and by the way, a little housekeeping information... You started
> your thread on the mailing list by replying to a completely unrelated
> thread (wotmate: simple grapher for your keyring). Could you please
> start a new thread the next time? Just address a message to
>  instead of replying to an existing message.
> Those of us with a threading view of the mailing list now see it as
> somehow being a part of the "wotmate: simple grapher for your keyring"
> thread, but they bare no relation whatsoever.
>
> HTH,
>
> Peter.
>




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


Re: enigmail with pgp 2.2.4

2018-02-22 Thread Peter Lebbing
On 22/02/18 21:17, Peter Lebbing wrote:
> The only way in which this might work is if I misinterpreted "not
> co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
> an instance of "co-installation". But I don't think that's the case. It
> might also work by pure chance and break horribly on the next update.

I think I might be a bit dense, as this cropped up in the other thread
as well yet I again forgot to account for it.

See


Other programs on your system might pick up your /usr/local/bin/gpg and
start using it as if it were /usr/bin/gpg at version 1.4. This will
expose wrong assumptions in those programs, causing them to malfunction.
The thing about the partially statically linked version mentioned in

> 

is that it is in /opt, where your system will not use it unless very
explicitly configured to do so. In fact, I wouldn't even add it to your
own $PATH, because some other program you invoke might use it as well.

I notice that often when someone asks "I do this and it goes wrong, what
am I doing wrong", I will think "oh, this and that is what is going
wrong, do it like this" instead of "Wait, should you even be doing
that?" :-).

I don't think there is a fool-proof way to install GnuPG 2.1+ on a Linux
distribution that ships 1.4 and/or 2.0. It will always require being
cautious and knowing exactly what is using what. Luckily, if we as
end-users have a bit more patience, I think in the end all our
distributions will have done the hard work of fixing all of this for
you. I count myself lucky to be running Debian stable. For once, that
means I'm running a newer version than others! :-D

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: enigmail with pgp 2.2.4

2018-02-22 Thread Peter Lebbing
On 22/02/18 18:10, Dmitry Gudkov wrote:
> problem solved by configuring Enigmail to use the new gnupg location in
> /usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
> the default setting /usr/bin/gpg2)

While my mind was idly mulling this over, I suddenly wondered if what
you are doing is even supposed to work at all. I think perhaps you just
haven't discovered the dire consequences of it yet.

GnuPG 1.4 and 2.0 are co-installable, and will happily work installed on
the same system.

GnuPG 1.4 and 2.1+ are in the basis co-installable, but still can
present you with issues like keyrings going out of sync or requiring
careful crafting of configuration files, off the top of my head.

But 2.0 and 2.1+ are definitely not co-installable. You can't have them
both on the same system. Right now you put GnuPG 2.2 and its
dependencies in /usr/local, but GnuPG 2.0 and its dependencies are still
in /usr. Their dependencies might start to mingle.

The only way in which this might work is if I misinterpreted "not
co-installable", and 2.0 in /usr and 2.1+ in /usr/local is not actually
an instance of "co-installation". But I don't think that's the case. It
might also work by pure chance and break horribly on the next update.

A solution, where GnuPG 2.1+ is statically linked against its
dependencies, was discussed here:


Werner introduced the partial static linking in the just released 2.2.5.


Oh, and by the way, a little housekeeping information... You started
your thread on the mailing list by replying to a completely unrelated
thread (wotmate: simple grapher for your keyring). Could you please
start a new thread the next time? Just address a message to
 instead of replying to an existing message.
Those of us with a threading view of the mailing list now see it as
somehow being a part of the "wotmate: simple grapher for your keyring"
thread, but they bare no relation whatsoever.

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


[Announce] GnuPG 2.2.5 released

2018-02-22 Thread Werner Koch
Hello!

We are is pleased to announce the availability of a new GnuPG release:
version 2.2.5.  This is a maintenance release; see below for a list of
fixed bugs.


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.5
===

  * gpg: Allow the use of the "cv25519" and "ed25519" short names in
addition to the canonical curve names in --batch --gen-key.

  * gpg: Make sure to print all secret keys with option --list-only
and --decrypt.  [#3718]

  * gpg: Fix the use of future-default with --quick-add-key for
signing keys.  [#3747]

  * gpg: Select a secret key by checking availability under gpg-agent.
[#1967]

  * gpg: Fix reversed prompt texts for --only-sign-text-ids.  [#3787]

  * gpg,gpgsm: Fix detection of bogus keybox blobs on 32 bit systems.
[#3770]

  * gpgsm: Fix regression since 2.1 in --export-secret-key-raw which
got $d mod (q-1)$ wrong.  Note that most tools automatically fixup
that parameter anyway.

  * ssh: Fix a regression in getting the client'd PID on *BSD and
macOS.

  * scd: Support the KDF Data Object of the OpenPGP card 3.3.  [#3152]

  * scd: Fix a regression in the internal CCID driver for certain card
readers.  [#3508]

  * scd: Fix a problem on NetBSD killing scdaemon on gpg-agent
shutdown.  [#3778]

  * dirmngr: Improve returned error description on failure of DNS
resolving.  [#3756]

  * wks: Implement command --install-key for gpg-wks-server.

  * Add option STATIC=1 to the Speedo build system to allow a build
with statically linked versions of the core GnuPG libraries.  Also
use --enable-wks-tools by default by Speedo builds for Unix.


Getting the Software


Please follow the instructions found at  or
read on:

GnuPG 2.2.5 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
.  Note that GnuPG is not
available at ftp.gnu.org.

The GnuPG source code compressed using BZIP2 and its OpenPGP signature
are available here:

 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.5.tar.bz2 (6430k)
 https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.5.tar.bz2.sig

An installer for Windows without any graphical frontend except for a
very minimal Pinentry tool is available here:

 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.5_20180222.exe (3819k)
 https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.5_20180222.exe.sig

The source used to build the Windows installer can be found in the same
directory with a ".tar.xz" suffix.  A new Gpg4win 3.0 installer
featuring this version of GnuPG will be available soon.


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.2.5.tar.bz2 you would use this command:

 gpg --verify gnupg-2.2.5.tar.bz2.sig gnupg-2.2.5.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 the end of this mail 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.2.5.tar.bz2, you run the command like this:

 sha1sum gnupg-2.2.5.tar.bz2

   and check that the output matches the next line:

9dec110397e460b3950943e18f5873a4f277f216  gnupg-2.2.5.tar.bz2
080f801e833c7a9e0441d55cd19d4bdb5bb261f9  gnupg-w32-2.2.5_20180222.exe
0ff74deb747531663b5876788c271c94c20dd605  gnupg-w32-2.2.5_20180222.tar.xz


Internationalization



Re: enigmail with pgp 2.2.4

2018-02-22 Thread Dmitry Gudkov
dear all,

thank you for your time and help

problem solved by configuring Enigmail to use the new gnupg location in
/usr/local/bin/gpg (in the "Preferences" dialog, "Basic" tab, override
the default setting /usr/bin/gpg2)

 Dmitry

On 22.02.2018 19:14, Damien Goutte-Gattat wrote:
> Hi,
>
> On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:
>> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
>> [...]
>> *and all works fine in terminal*
>>
>> however after installing Enigmail I get this error
>
> You installed GnuPG 2.2.4 in /usr/local, but you still have an older
> version in /usr.
>
> Everything works fine in the terminal because your shell finds the
> newer /usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2
> (as you can see in the error message, which includes the exact command
> used to invoke gpg).
>
> You must configure Enigmail to use /usr/local/bin/gpg (in the
> "Preferences" dialog, "Basic" tab, override the default setting).
>




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


Re: enigmail with pgp 2.2.4

2018-02-22 Thread Damien Goutte-Gattat

Hi,

On 02/22/2018 02:21 PM, Dmitry Gudkov wrote:

sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
[...]
*and all works fine in terminal*

however after installing Enigmail I get this error


You installed GnuPG 2.2.4 in /usr/local, but you still have an older 
version in /usr.


Everything works fine in the terminal because your shell finds the newer 
/usr/local/bin/gpg, but Enigmail is still using /usr/bin/gpg2 (as you 
can see in the error message, which includes the exact command used to 
invoke gpg).


You must configure Enigmail to use /usr/local/bin/gpg (in the 
"Preferences" dialog, "Basic" tab, override the default setting).




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


Re: enigmail with pgp 2.2.4

2018-02-22 Thread Peter Lebbing
On 22/02/18 15:21, Dmitry Gudkov wrote:
> sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local

That would mean that GnuPG is in /usr/local/bin/gpg

Yet:

On 22/02/18 11:04, Dmitry Gudkov wrote:
> Error - key extraction command failed
> /usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent --batch
> --no-tty --status-fd 2 -a --export 0xFB417E72

So probably /usr/bin/gpg2 is the distribution-provided older version, hence your
issues.

You should probably configure all your GnuPG-using software to use
/usr/local/bin/gpg. Also, it might make sense to explicitly configure all those
tools to use a non-default GNUPGHOME. That way, should one of your tools
accidentally pick /usr/bin/gpg2, it will hopefully also pick the default
homedir, and not interfere with all your correctly-configured tools. This is
just an idea that occured to me and is completely untested. Then again, mixing
these versions with identical homedirs is tested and has failed the test, so I'm
hoping for a net improvement ;-).

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: How can we utilize latest GPG from RPM repository?

2018-02-22 Thread Dan Kegel
On Wed, Feb 21, 2018 at 10:22 PM, Ben McGinnes  wrote:
>> And when you're on those certified, curated systems, you have
>> access to tools like
>> https://www.open-scap.org/resources/documentation/make-a-rhel7-server-compliant-with-pci-dss/
>> to help make sure you're in compliance, I think.
>
> open-scap.org is a RedHat service
> and most likely only supplied to RHEL customers seeking PCI-DSS
> compliance along with direct support via their service contract.

https://www.open-scap.org/download/ shows they provide an
open source tool which is in repositories for four redhat-ish distros and
two debian-ish distros; on Ubuntu, I was able to walk down the
path of using it a bit, looks a bit rusty, but see
https://github.com/OpenSCAP/scap-security-guide
So it doesn't seem to be RHEL-only.  (They have a value-added tool
that is, of course.)
- Dan

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


Re: enigmail with pgp 2.2.4

2018-02-22 Thread Dmitry Gudkov
Hi Werner,

yes, i am.

*I just manually compiled it on the fresh install of ubuntu 16.04 per
the below script:*

cd ~/Downloads
version=gnupg-2.2.4
wget https://gnupg.org/ftp/gcrypt/gnupg/$version.tar.bz2
wget https://gnupg.org/ftp/gcrypt/gnupg/$version.tar.bz2.sig
tar xf $version.tar.bz2
cd $version
sudo apt-get update
sudo apt-get install -y libldap2-dev
sudo apt-get install -y gtk+-2
sudo apt-get install -y rng-tools
sudo apt-get install -y libbz2-dev
sudo apt-get install -y zlib1g-dev
sudo apt-get install -y libgmp-dev
sudo apt-get install -y nettle-dev
sudo apt-get install -y libgnutls28-dev
sudo apt-get install -y libsqlite3-dev
sudo apt-get install -y adns-tools
sudo apt-get install -y libreadline-dev
sudo apt-get install -y qtbase5-dev
sudo apt-get install -y pinentry-gtk2
sudo apt-get install -y pcscd scdaemon
sudo make -f build-aux/speedo.mk INSTALL_PREFIX=/usr/local
speedo_pkg_gnupg_configure='--enable-g13 --enable-wks-tools' native
sudo ldconfig

# use nano to create a configuration file: nano ~/.gnupg/gpg-agent.conf
# add the line: pinentry-program /usr/bin/pinentry-gtk-2
# chmod 600 ~/.gnupg/gpg-agent.conf

*the result is the following:*

bereska@bereska-VPCZ21AGX:~/.gnupg$ gpg --version
gpg (GnuPG) 2.2.4
libgcrypt 1.8.2
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/bereska/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
    CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

*then I imported my existing keys for the other machine*

*and all works fine in terminal*

however after installing Enigmail I get this error when I try to attach
my public key to the message

thank you for your time to this matter

Dmitry




On 22.02.2018 16:19, Werner Koch wrote:
> Hi!
>
> On Thu, 22 Feb 2018 11:04, bere...@hotmail.com said:
>
>> gpg: skipped packet of type 12 in keybox
> Are you sure this if gpg 2.2.4 ?  The error looks more like this is a
> gpg version < 2.1.20.
>
> Type 12 are ring trust packets which are used internally by gpg.  The
> code which shows this error is 
>
>   /* Filter allowed packets.  */
>   switch (pkt->pkttype)
> {
> case PKT_PUBLIC_KEY:
> case PKT_PUBLIC_SUBKEY:
> case PKT_SECRET_KEY:
> case PKT_SECRET_SUBKEY:
> case PKT_USER_ID:
> case PKT_ATTRIBUTE:
> case PKT_SIGNATURE:
> ===>case PKT_RING_TRUST:
>   break; /* Allowed per RFC.  */
>
> default:
>   /* Note that can't allow ring trust packets here and some of
>  the other GPG specific packets don't make sense either.  */
>   log_error ("skipped packet of type %d in keybox\n",
>  (int)pkt->pkttype);
>   free_packet(pkt, );
>   init_packet(pkt);
>   continue;
> }
>
> Thus a ring trust packet can't show this error.  Note that the comment
> in the default case is misleading.
>
>
> Shalom-Salam,
>
>Werner
>



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


Being civil costs you nothing (was: How can we utilize latest GPG from RPM repository?)

2018-02-22 Thread Peter Lebbing
On 22/02/18 15:18, helices wrote:
> Let's cut through these ill-informed suppositions once and for all
You are rapidly squandering good will here. Your hostile tone will not
motivate anyone to help you any further. You are asking people to spend
their spare time on your issues, you should not deride them. None of the
posters here spent their spare time on your questions without the intent
to help you. You are insulting them.

> Defending processes and systems to egregiously non-technical auditors is
> a challenge that grows year by year. If you have not qualified for PCI
> DSS Level 1, then you probably have only a cursory understanding of this
> situation. Based on previous questions I've posted here in last several
> years, it's clear to me that none of the experts here have such experience.

I almost get the impression half of the mails don't come through,
because I just read Ben McGinnes state the complete opposite.

Also, and more importantly, if you're so worried about the competences
of the people you ask questions, you should hire experts, not post on a
community mailing list.

> Sometimes, a question is just a question.

And sometimes it is an insult thinly disguised as one.

> Our new environment will continue with gnupg v2.0.22, because that is
> the security level supported by stable and secure Linux operating
> systems. Please, do not debate me on this.

I agree: I don't wish to debate you on this. I /will/ state my dissent
with the statement before. I consider Debian stretch/stable a "stable
and secure Linux operating system", and that carries GnuPG v2.1.18 (with
backported fixes of course).

Goodbye,

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: How can we utilize latest GPG from RPM repository?

2018-02-22 Thread helices
Let's cut through these ill-informed suppositions once and for all: If host
compliance was our problem, I would not have posted here at all.

Also, nowhere in this thread have I stated any inability to compile myself.
Having been doing such for 40+ years, that is not our problem either.

Defending processes and systems to egregiously non-technical auditors is a
challenge that grows year by year. If you have not qualified for PCI DSS
Level 1, then you probably have only a cursory understanding of this
situation. Based on previous questions I've posted here in last several
years, it's clear to me that none of the experts here have such experience.

Sometimes, a question is just a question. Overthinking the environment in
which that question was asked adds nothing to the discussion. Now that my
question has been directly answered - thank you, Ben - and indirectly
answered - thank you, to those who did not answer directly - we can move
forward in my enterprise architecture endeavor.

Thank you, Daniel, for describing the complexity of the gnupg problem.

Our new environment will continue with gnupg v2.0.22, because that is the
security level supported by stable and secure Linux operating systems.
Please, do not debate me on this. Yes, we could do otherwise, but that will
incur PCI DSS v3.2 challenges unnecessary to us.

Thank you.

~ helices




On Thu, Feb 22, 2018 at 12:22 AM, Ben McGinnes  wrote:

> On Wed, Feb 21, 2018 at 07:36:08AM -0800, Dan Kegel wrote:
> > On Tue, Feb 20, 2018 at 10:16 PM, Ben McGinnes 
> wrote:
> >>
> >> Because these two lines explain *precisely* why you need something
> >> like RHEL or CentOS (certified systems to go with the auditing)
> >> *and* updated crypto.
> >
> > And when you're on those certified, curated systems, you have
> > access to tools like
> > https://www.open-scap.org/resources/documentation/make-
> a-rhel7-server-compliant-with-pci-dss/
> > to help make sure you're in compliance, I think.
> >
> > I suspect that kind of approach would make passing audits a lot
> > easier than building the latest gnupg release yourself...
> > and is less likely to break things.
>
> In all likelihood, yes ... however open-scap.org is a RedHat service
> and most likely only supplied to RHEL customers seeking PCI-DSS
> compliance along with direct support via their service contract.
>
> If, however, this particular case actually deals with CentOS systems
> and not RHEL, then the OP has elected to forego that type of
> professional service contract from the vendor in order to do it
> themselves.
>
> Which brings us either back to this thread, or a business decision at
> their end regarding whether or not bring their systems back to RHEL
> (it requires changing two files, IIRC, assuming they haven't massively
> modified things) and paying RedHat whatever it takes to get the job
> done.  I cannot predict which they will choose, nor am I willing to
> make a recommendation solely on what's been presented here.
>
> Still, the OP wanted options and now they've been provided.  :)
>
>
> Regards,
> Ben
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: enigmail with pgp 2.2.4

2018-02-22 Thread Werner Koch
Hi!

On Thu, 22 Feb 2018 11:04, bere...@hotmail.com said:

> gpg: skipped packet of type 12 in keybox

Are you sure this if gpg 2.2.4 ?  The error looks more like this is a
gpg version < 2.1.20.

Type 12 are ring trust packets which are used internally by gpg.  The
code which shows this error is 

  /* Filter allowed packets.  */
  switch (pkt->pkttype)
{
case PKT_PUBLIC_KEY:
case PKT_PUBLIC_SUBKEY:
case PKT_SECRET_KEY:
case PKT_SECRET_SUBKEY:
case PKT_USER_ID:
case PKT_ATTRIBUTE:
case PKT_SIGNATURE:
===>case PKT_RING_TRUST:
  break; /* Allowed per RFC.  */

default:
  /* Note that can't allow ring trust packets here and some of
 the other GPG specific packets don't make sense either.  */
  log_error ("skipped packet of type %d in keybox\n",
 (int)pkt->pkttype);
  free_packet(pkt, );
  init_packet(pkt);
  continue;
}

Thus a ring trust packet can't show this error.  Note that the comment
in the default case is misleading.


Shalom-Salam,

   Werner

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


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


enigmail with pgp 2.2.4

2018-02-22 Thread Dmitry Gudkov
dear all,

when trying to use enigmail with latest gpg 2.2.4 I get the following error:

Error - key extraction command failed
/usr/bin/gpg2 --charset utf-8 --display-charset utf-8 --use-agent
--batch --no-tty --status-fd 2 -a --export 0xFB417E72
gpg: skipped packet of type 12 in keybox
gpg: skipped packet of type 12 in keybox
gpg: skipped packet of type 12 in keybox
gpg: skipped packet of type 12 in keybox

any help is appreciated

thank you


On 22.02.2018 07:33, Fraser Tweedale wrote:
> u wot m8
>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fknowyourmeme.com%2Fmemes%2Fu-wot-m8=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435%7C1%7C0%7C636548765303114275=%2FHaCzuQYPCD3rYFtY4Yf7%2FQYf9zVDwMnvecHLMQjS20%3D=0
>
> Nice tool; thanks for sharing!
>
> Cheers,
> Fraser
>
> On Wed, Feb 21, 2018 at 09:59:01AM -0500, Konstantin Ryabitsev wrote:
>> Hi, all:
>>
>> I've been maintaining the kernel.org web of trust for the past 5+ years,
>> and I wrote a number of tools to help me visualize trust paths between
>> fully trusted keys and those belonging to newer developers.
>>
>> I finally got a chance to clean up the code, and I hope it's useful to
>> others:
>>
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmricon%2Fwotmate=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435%7C1%7C0%7C636548765303114275=tWao8vfy5bJfoB40KWD3js4pJnprbIANN4mtimfuEz4%3D=0
>>
>> If you think this is very similar to the PGP Pathfinder tool on
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpgp.cs.uu.nl=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435%7C1%7C0%7C636548765303114275=S1AnXI5SbhU9HJOr2g4bgfSM8XY%2BazoDX2DkY7gnCRo%3D=0,
>>  then you are right, but there is an important
>> distinction. Wotmate does not require that a key is in the "strong set"
>> before you can track paths to it, and you also don't have to wait for
>> days before new signatures are reflected in the wotsap file.
>>
>> Example usage (assuming you have Linus Torvalds' key in your keyring):
>>
>> ./make-sqlitedb.py
>> ./graph-paths.py torvalds
>> eog graph.png
>>
>> Best,
>> -- 
>> Konstantin Ryabitsev
>> Director, IT Infrastructure Security
>> The Linux Foundation
>>
>
>
>
>> ___
>> Gnupg-users mailing list
>> Gnupg-users@gnupg.org
>> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435%7C1%7C0%7C636548765303114275=DrCK2mXWv4ME77UQava0%2BKM%2BEPVKm1KUUMx1WmwFtwI%3D=0
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users=02%7C01%7C%7C6e6006dedf1d43931dcb08d579babd99%7C84df9e7fe9f640afb435%7C1%7C0%7C636548765303114275=DrCK2mXWv4ME77UQava0%2BKM%2BEPVKm1KUUMx1WmwFtwI%3D=0



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