Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 14:22 schrieb Werner Koch :

> I do not think that it matters whether you pull using the git or the ssh
> protocol.  In both cases an active attacker can intercept the traffic
> easily.  Virtually nobody checks ssh host keys and how should they do it
> given that I can't find its fingerprint easily on github.  Thus you would only
> see the "host key changed" warning in case this is not the first time
> you connected to this github project (I assume they use different host
> keys per project). 

I do verify the fingerprint, and they are quite easy to find actually:

https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/

First Google match for "GitHub SSH fingerprint".

> After all it is not different from downloading tarballs - only 10 to 20%
> of all downloads also download the signature file and for most projects
> there is no signature file.

Well, I guess you have to take into account that a lot of downloads are from 
packaging software like pkgsrc, FreeBSD ports, Gentoo portage, ArchLinux's 
makepkg, etc. Usually, these do download the signature and tarball once, verify 
it and then write a checksum to the Makefile / PKGBUILD / however it is called 
that is then verified. So I guess you can't easily map that to "Only x% of 
users check the downloaded tarball". I guess it's a lot more, it's just not all 
check it using the .sig.

> For gnupg.org we assume that users of the repos closely watch out for
> conflicts and verify the latest release tag.  If there is a problem that
> should be reported to a mailing-list (after verification that it is
> really a conflict).
> 
> git meanwhile allows to sign commits.  If anyone knows a method to set a
> different key for tagging and commits, I would soon start to sign each
> commit.  I use a smartcard based key for tagging but won't use that for
> regular commits.

git commit -S 

You can just create an alias for that, I for example use git ci.

--
Jonathan


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 14:31 schrieb Werner Koch :

> GnuPG's speedo build system also downloads stuff via the Makefile but it
> verifies the checksums before proceeding. The checksums are taken from a
> public file which has a detached signature and the public key for that
> is one of the GnuPG release signing keys.

While this is much better from a security point of view, it still means that 
building needs an internet connection. It would be nice to be able to build it 
on an air-gapped machine, which I guess is quite a common use case for GnuPG.

To be fair, though, I never noticed that until you mentioned it :).

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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 14:58 schrieb Sandeep Murthy :

> FYI I think you haven’t really looked at the support forum.  This page
> 
> http://support.gpgtools.org/kb/faq/found-an-issue
> 
> clearly lists instructions for submitting a bug.  They are always interested
> in reproducible issues, and every week in the discussions such issues
> are reported.
> 
> Therefore it is not true that this support forum does not allow people to
> report bugs.

I looked for this a month ago and couldn't find anything besides a support 
forum (didn't sound right to me) and a Twitter handle, thus I decided to try 
Twitter.

--
Jonathan


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 17:00 schrieb Ville Määttä :

> Upstream still does have the issue which now seems to have been fixed in the 
> fork but in a binary removed from upstream…

I really can not confirm this. I am running vanilla GnuPG 2.1.2 (built from 
source) on Yosemite (10.10.2 to be exact) with a Gnuk without any problems.

In any case, I agree about the part that such fixes should be developed in the 
GnuPG repo and not in basically a fork that receives less reviewing.

> I think the GUI tooling of not only Mac but other *NIX systems to be quite an 
> important factor in getting wider use for encryption. Such tools must be from 
> a respectable source and properly implemented just as much as the underlying 
> engine. I would argue GnuPG should take the responsibility of such tooling 
> where there isn’t a good option. Other *NIX systems are doing fairly well 
> already so I suppose a Mac GUI would really be the urgent one.

I suppose it might be a good idea to have a Qt GUI. That looks native enough on 
Mac so that most users won't complain, works good on X11 or Wayland based 
systems and also works well on Windows. Ideally, this would be a project under 
the GnuPG umbrella, but ideally not taking away time from core developers and 
thus be done by others. It also is not that security critical if it's just a 
GUI using the command line tool.

--
Jonathan


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 20:16 schrieb Juergen Fenn :

> Enigmail has discussed recently to drop support for GnuPG1, making
> gpg-agent/pinentry a crucial issue on the Mac. The standard version of
> pinentry from MacPorts does not work properly out of the box.

For homebrew, there's a pinentry-mac formula, which unfortunately also does the 
remote code execution. I raised the issue with homebrew, however, most posts in 
that ticket were deleted because some people started questioning the review 
process of new formula and asked how this could even have gotten into homebrew.

The solution I chose is an ugly, but more secure one: I use pinentry-gtk with 
XDarwin. Sure it's ugly, even more so since it is upscaled on a retina display. 
But it's only for entering the PIN / passphrase, so I'd rather use that then 
pinentry-mac. I did not choose pinentry-curses because that didn't work well 
with signing Git commits.

> Anyway, alternatives should be mentioned on the GnuPG pages because—I
> agree to the OP—this is too important an issue, GnuPG also being used
> by  many people who seriously depend on its security.

I totally agree. There should at least be a big fat warning, saying to not use 
if it you really depend on security.

> The question is, can we use GnuPG on the Mac and rely on it?

I'd say yes. I'm using GnuPG 2.1.2 vanilla with a Gnuk token and don't see why 
it should be any less reliable than on Linux.

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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Samir Nassar]

On Wednesday, February 18, 2015 12:05:18 PM Jonathan Schleifer wrote:
> I suppose it might be a good idea to have a Qt GUI. That looks native enough
> on Mac so that most users won't complain, works good on X11 or Wayland
> based systems and also works well on Windows. Ideally, this would be a
> project under the GnuPG umbrella, but ideally not taking away time from
> core developers and thus be done by others. It also is not that security
> critical if it's just a GUI using the command line tool.

Hello,

If you are using MacPorts you could try KGPG. Rolf Eike Beer is the maintainer 
and is very active and responsive.

I don't know if all the features will work on OS X, but I really like KGPG's 
ability to take text and encrypt and sign plain text from an interface as well 
as decrypt and verify ASCII-armored text.

Samir

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: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 22:32 schrieb Lukas Pitschl :

> The best way to reach us is either our support platform at 
> https://gpgtools.tenderapp.com or t...@gpgtools.org.

When I tried contacting you guys a little more than a month ago, there was no 
e-mail to be found on the website. Only a support forum that sounded like 
"Users helping users" (so I didn't want to report the bug there) and a Twitter, 
which I then used. Can you please make sure it's easy to find that mail address?

> The code that checks out our GPGTools_Core repository is pretty old already 
> and it’s certainly a stupid way to do it.

It's not so much about age, but about what thought process came to the 
conclusion that this might be a good idea. This is a security project, so every 
change done should be done with thoroughly thinking about the security 
implications that change might have. This was clearly not done here, and IMHO 
downloading and executing remote code without any verification is unforgivable 
for a security project.

> At  the time we assumed that it was safe to check it out via ssl from github, 
> since curl would refuse to do so if there was a certificate error.

This entirely depends on the certification store curl has and the 
configuration. Granted, the defaults on OS X are sane. But still, this relies 
completely on GitHub not being compromised. And it was only quite recently that 
someone managed to get write access to repos due to a bug in GitHub. How can 
someone blindly trust and rely on a service they can neither control nor audit 
for the security of their users in a security project? This is just extremely 
irresponsible.

And even worse: Why did you decide to hide what is going on by prefixing it 
with a @? This really feels like you are trying to deceit users, hiding from 
them that they execute remote code that you could change at any moment. Worse 
yet, you could later on switch it back and nobody would notice. This feels a 
lot like a hidden backdoor to me.

> we will only charge a fee for GPGMail, the rest of GPG Suite will remain free.

Actually, I'm all for you charging a fee. That will create enough pressure for 
a fork that will then hopefully have better security practices.

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

Re: 2.1.2: keyserver route failure

[Werner Koch]

On Wed, 18 Feb 2015 06:24, r...@sixdemonbag.org said:

> I don't have IPv6 routing, period.  This raises the question of why
> GnuPG is trying to reach an IPv6 address at all.

Because the resolver tells that there is an  record.  It seems that
we need to figure out at runtime whether v6 is actually working.  Any
hints on how to do that?


Salam-Shalom,

   Werner

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


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Jonathan Schleifer]

Am 17.02.2015 um 15:14 schrieb Hugo Osvaldo Barrera :

> Actually, I've noticed that there was a very quick reply to this when it was
> brought to the dev's attention. I'll leave this here for anyone else 
> interested
> in following-up:
> 
>  
> https://github.com/GPGTools/GPGTools_Core/commit/5186bade36acedfdc0b76f9f5ddfcfc004ec698b
> 
> I'm not aware of any track record of writing bad software in the past either -
> I believe they're just human.

"A user complained, so we'd rather use something insecure."

This is not the correct mindset to develop security software!

Also, the new way they solve it ignores the proposal to use git submodules 
entirely, not even stating why they don't want to use git submodules. But that 
at least is not a security problem, so I don't have strong feeling about this 
:).

--
Jonathan


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

Re: 2.1.2: keyserver route failure

[Johan Wevers]

On 18-02-2015 12:40, Werner Koch wrote:

> Because the resolver tells that there is an  record.  It seems that
> we need to figure out at runtime whether v6 is actually working.  Any
> hints on how to do that?

The most easy solution in such cases is to try IPv4 first, if that
doesn't work or is unavailable, try IPv6 if available.

Non-working or misconfigured IPv6 setups are rather common, probably
done by default setups where the builder prefers IPv6 and a server owner
who isn't even aware the server supports IPv6. Combined with a "IPv6
first" approach of some software a recipe for problems.

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


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

Re: Compiled binaries execute but exit with "Abort"

[Errol Casey]

 gdb gpg2
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
(gdb) break abort
Breakpoint 1 at 0x1278fc
(gdb) run
Starting program: /syshome/gecasey/gpg/gnupg-2.0.26/g10/gpg2
warning: Temporarily disabling breakpoints for unloaded shared library
"/usr/lib/ld.so.1"
Breakpoint 1 at 0xfedc28a4
gpg: Go ahead and type your message ...
this is a test
.
gpg: no valid OpenPGP data found.
gpg: processing message failed: Unknown system error

Breakpoint 1, 0xfedc28a4 in abort () from /lib/libc.so.1
(gdb) bt
#0  0xfedc28a4 in abort () from /lib/libc.so.1
#1  0xff15367c in get_lock_object (lockhd=0xff16e3b0) at posix-lock.c:111
#2  0xff1536f8 in _gpgrt_lock_lock (lockhd=0xff16e3b0) at posix-lock.c:155
#3  0xff156a74 in _gpgrt_fflush (stream=0x0) at estream.c:3590
#4  0xff156b0c in do_deinit () at estream.c:490
#5  0xfedc3180 in _exithandle () from /lib/libc.so.1
#6  0xfedb1140 in exit () from /lib/libc.so.1
#7  0x0002717c in g10_exit ()
#8  0x00025de0 in main ()
(gdb)


On Tue, Feb 17, 2015 at 10:53 PM, Werner Koch  wrote:

> On Tue, 17 Feb 2015 21:12, er...@askerrol.org said:
>
> > But it fails openpgp tests, and all executable exit with an "Abort"
> message.
>
> Please run such an executable under a debugger and privide a stack
> backtrace.  Using gdb you would use:
>
>   gdb g10/gpg
>
>   then enter "break abort", "run", and after it stops "bt".
>
>
> Shalom-Salam,
>
>Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>


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

Re: Compiled binaries execute but exit with "Abort"

[Werner Koch]

On Wed, 18 Feb 2015 14:18, er...@askerrol.org said:

> #0  0xfedc28a4 in abort () from /lib/libc.so.1
> #1  0xff15367c in get_lock_object (lockhd=0xff16e3b0) at posix-lock.c:111

That is an assert() checking that the used library matches the one used
for building.  This is all in libgpg-error - please build libgpg-error
and check that "make check" works.


Shalom-Salam,

   Werner

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


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Werner Koch]

On Wed, 18 Feb 2015 11:54, js-gnupg-us...@webkeks.org said:

> While this is much better from a security point of view, it still means that 
> building needs an internet connection. It would be nice to be able to build 
> it on an air-gapped machine, which I guess is quite a common use case for 
> GnuPG.
>
> To be fair, though, I never noticed that until you mentioned it :).

The speedo.mk Makefile is optional.  And of course it is possible to run
that offline (make -f speedo.mk native CUSTOM_SWDB=1) - I like to work
while on a train.


Shalom-Salam,

   Werner

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


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Werner Koch]

On Wed, 18 Feb 2015 12:05, js-gnupg-us...@webkeks.org said:

> I suppose it might be a good idea to have a Qt GUI. That looks native

Although Kleopatra is a KDE application there is not much of KDE in it
and, iirc, Andre once suggested to turn it into a plain Qt application.


Salam-Shalom,

   Werner

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


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Werner Koch]

On Wed, 18 Feb 2015 12:21, js-gnupg-us...@webkeks.org said:

> And even worse: Why did you decide to hide what is going on by
> prefixing it with a @? This really feels like you are trying to deceit

I also do this often to avoid cluttering the screen.  No need to assume
a backdoor.  It is for a Mac and Mac users want a clean tty ;-)


Shalom-Salam,

   Werner

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


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Werner Koch]

On Wed, 18 Feb 2015 11:52, js-gnupg-us...@webkeks.org said:

> I do verify the fingerprint, and they are quite easy to find actually:
>
> https://help.github.com/articles/what-are-github-s-ssh-key-fingerprints/
>
> First Google match for "GitHub SSH fingerprint".

Using a search engine to find important information is not very user
friendly.  The host keys should be linked from the root page.  But in
this regard this is not different than any root CA - most make it really
hard to find the fingerprint and the support lines sometimes don't even
known why one what to check this.

> Makefile / PKGBUILD / however it is called that is then verified. So I
> guess you can't easily map that to "Only x% of users check the
> downloaded tarball". I guess it's a lot more, it's just not all check
> it using the .sig.

Sure I can.  If there are 1000 downloads of the tarball and only 100 of
the corresponding sig it should be pretty clear that 90% of those who
download not even pretend to check the signature.

> git commit -S 
>
> You can just create an alias for that, I for example use git ci.

I know that but I would like to have a different key for tag and commit.
Requiring an option is just too cumbersome.


Salam-Shalom,

   Werner

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


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

[Announce] GnuPG 2.0.27 "stable" released

[Werner Koch]

Hello!

We are pleased to announce the availability of a new stable GnuPG-2
release: Version 2.0.27.  This is a maintenance release which fixes a
couple of bugs.  Update to this version is suggested.

The GNU Privacy Guard (GnuPG) is a complete and free implementation of
the OpenPGP standard as defined by RFC-4880 and better known as PGP.

GnuPG, also known as GPG, 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 versions of GnuPG are actively maintained:

- GnuPG "modern" (2.1) is the latest development with a lot of new
  features.  

- GnuPG "stable" (2.0) - which this is about - 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.


What's New in 2.0.27


 * gpg: Detect faulty use of --verify on detached signatures.

 * gpg: New import option "keep-ownertrust".

 * gpg: Uses SHA-256 for all signature types also on RSA keys.

 * gpg: Added support for algo names when generating keys using the
   --command-fd method.

 * gpg: Unless --allow-weak-digest-algos is used the insecure MD5
   based fingerprints are shown as all zeroe

 * gpg: Fixed DoS based on bogus and overlong key packets.

 * gpg: Better error reporting for keyserver problems.

 * Fixed several bugs related to bogus keyrings and improved some
   other code.


Getting the Software


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

GnuPG 2.0.27 may be downloaded from one of the GnuPG mirror sites or
direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ .  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 and on its mirrors you should find the following new
files in the gnupg/ directory:

  - The GnuPG source code compressed using BZIP2 and its OpenPGP
signature:

gnupg-2.0.27.tar.bz2 (4321k)
gnupg-2.0.27.tar.bz2.sig

Note, that we don't distribute gzip compressed tarballs for GnuPG-2.
A Windows version will eventually be released at https://gpg4win.org .

If you are new to GnuPG please consider to use the "modern" version
2.1.2.


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

 gpg --verify gnupg-2.0.27.tar.bz2.sig gnupg-2.0.27.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.1.tar.bz2, you would run the command like this:

 sha1sum gnupg-2.0.27.tar.bz2

   and check that the output matches the next line:

d065be185f5bac8ea07b210ab7756e79b83b63d4  gnupg-2.0.27.tar.bz2


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) 

  rsa2048/33BD3F06 2014-10-29 

Re: [Announce] GnuPG 2.1.2 released

[Werner Koch]

On Mon, 16 Feb 2015 11:03, bernh...@intevation.de said:

> * What the items in section "What's New in GnuPG-2.1" actually meant,

I should have read "What's New in GnuPG 2.1.2", sorry.

> * "This version fixes a lot of bugs found after the release of 2.1.0"
>   which probably should have been "2.1.1". 

Actually I meant 2.1.0 as the first release of the 2.1 branch.  Might be
a bit unclear, indeed.

> Overall I believe the announcement as too much text that stays the same
> for each release. It would benefit from being focussed on the key differences

That is how I expect an announcement.

> ps.: Congrats on the taz article (in German) I've added the link to the wiki.

[I don't understand why the all pretend that I am working in a cellar.  I
 even have to walk another 12 steps down to the garden.]


Shalom-Salam,

   Werner


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


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

Re: 2.1.2: keyserver route failure

[Doug Barton]

On 2/18/15 3:59 AM, Johan Wevers wrote:

On 18-02-2015 12:40, Werner Koch wrote:


Because the resolver tells that there is an  record.  It seems that
we need to figure out at runtime whether v6 is actually working.  Any
hints on how to do that?


The most easy solution in such cases is to try IPv4 first, if that
doesn't work or is unavailable, try IPv6 if available.


Yeah, please DO NOT do that. The more traffic we can push to IPv6 the 
better for everyone, both now and in the future.


I'll get some refs on testing IPv6 capability, give me a couple hours.

Doug



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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Doug Barton]

On 2/18/15 2:52 AM, Jonathan Schleifer wrote:

Well, I guess you have to take into account that a lot of downloads are from packaging 
software like pkgsrc, FreeBSD ports, Gentoo portage, ArchLinux's makepkg, etc. Usually, 
these do download the signature and tarball once, verify it and then write a checksum to 
the Makefile / PKGBUILD / however it is called that is then verified. So I guess you 
can't easily map that to "Only x% of users check the downloaded tarball". I 
guess it's a lot more, it's just not all check it using the .sig.


Back when I was involved with the FreeBSD project I included code in the 
Makefile to verify the PGP signature for all of my ports that had one, 
as did a few other maintainers. However there was not only not a 
consensus to do this more generally, there was active opposition to 
doing it at all.


If you are a FreeBSD user and believe that this would be something 
beneficial to the ports system, please send them e-mail at 
freebsd-po...@freebsd.org and let them know. :)


Doug


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Robert J. Hansen]

> "A user complained, so we'd rather use something insecure."

That's not what the GPGTools folks did.  Your caricature of their
response is unfair and ungentlemanly.


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

Re: 2.1.2: keyserver route failure

[Johan Wevers]

On 18-02-2015 17:31, Doug Barton wrote:

>> The most easy solution in such cases is to try IPv4 first, if that
>> doesn't work or is unavailable, try IPv6 if available.

> Yeah, please DO NOT do that. The more traffic we can push to IPv6 the
> better for everyone, both now and in the future.

I've seen that before: proponents of IPv6 try to fore an "IPv6 first"
doctrine to get at least _some_ traffic over IPv6 because IPv4 first
would mean that IPv6 would nearly nover been used. Admit it, IPv6 has
failed. It may get some uses, but the widespread adaptation of carrier
NAT has made it largely obsolete.

Removing the  record would be the quickest solution I guess.

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


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

Re: 2.1.2: keyserver route failure

[Werner Koch]

On Wed, 18 Feb 2015 12:59, joh...@vulcan.xs4all.nl said:

> The most easy solution in such cases is to try IPv4 first, if that
> doesn't work or is unavailable, try IPv6 if available.

That server has no v4 address.  For obvious reasons we use the standard
version first and only then fallback to a legacy IP version .-).

> Non-working or misconfigured IPv6 setups are rather common, probably

The problem is more that the all machines now have v6 enabled but no
address configured.  It is a bug in GnuPG's server selection code not to
check whether a real v6 interface is up.


Shalom-Salam,

   Werner

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


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

Re: 2.1.2: keyserver route failure

[Peter Lebbing]

On 18/02/15 18:07, Johan Wevers wrote:
> Admit it, IPv6 has failed. It may get some uses, but the widespread
> adaptation of carrier NAT has made it largely obsolete.

Tired as I may be of this discussion (what's your next argument, NAT provides
beneficial firewalling behaviour?), I still wish to say that I will not "admit"
IPv6 has failed or that IPv4 advancements[1] made it obsolete. Get off your 
soapbox.

Peter.

[1] I shudder to call NAT an advancement, but that's apparently how you present 
it.

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

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

Re: Talking about Cryptodevices... which one?

[Werner Koch]

On Sat, 24 Jan 2015 05:05, gni...@fsij.org said:

>   DINSIG (DIN V 66291-1) card
>   German Geldkarte
>   Telesec NKS card
>   pkcs#15 card
>   SmartCard-HSM card
>
> ... but I think that most are outdated, except the last one.

DINSIG is still German standard (actually a pre-standard) but I doubt
that you can find any card.  Vendors have all moved to their own
standard.  The Geldkarte ("Money-card") is a gadget which only allows
you to check the amount of money left on the card.  The telesec card
still works, although I don't known about the availability.  p15 cards
also work as long as they fully comply to the pkcs#15 standard (only few
do).

> And when you use those devices, you should know that each application
> has tendency to grab smartcard/token access exclusively.  At least,

Which makes the use of the card much faster.  The PC/SC system is broken
so that even Microsoft replaced it by a system similar to scdaemon
(minidrivers).  But don't let me start to rant about it again.

> I don't use X.509 much.  I think that it's easily possible for us to

Neither me.  That has all been done as part of a contract; now with the
secured funding it would be possible to revive the X.509 support - iff
there is a need for it.

> OpenPGPcard (and its compatible) usually doesn't have any public keys
> of higher layer, because of its limited storage.

... and because of the I/O speed - it would take long to read out keys
with many key signatures.  Those who need to use the German eHealth card
know what I mean by slow.

> purpose MCU.  In my theory, using general purpose small MCU would be
> superior to avoid malicious/fake hardware features by semiconductor
> vendor.  If it's very expensive hardware, specific for "crypto", there

I agree.


Salam-Shalom,

   Werner

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


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

Unattended signing

[Daniele Nicolodi]

Hello,

I have a quite simple question on best practice for the use of GPG. I
haven't found an answer searching online. I hope this mailing list is
the right place for asking.

I have an automated process that collects some data and unattended sends
it via email. I want that data to be encrypted and signed. The
encryption part is easy as it requires only public keys of the
recipients. Signing, however, requires to make the private key used
available to the process.

I have a sufficient trust in the security of the server where the
automated process runs, but I would like to reduce to a minimum the risks.

What is the best practices in such cases?  I can imagine several
possible options: using a subkey of my key (is it possible to remove
passphrase protection from a subkey?), using a dedicated key, using a
subkey of a dedicated key and periodically rotate such subkey.

Ideas? Comments?

Thanks. Cheers,
Daniele

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

Re: 2.1.2: keyserver route failure

[Daniel Kahn Gillmor]

On Wed 2015-02-18 06:40:12 -0500, Werner Koch wrote:
> On Wed, 18 Feb 2015 06:24, r...@sixdemonbag.org said:
>
>> I don't have IPv6 routing, period.  This raises the question of why
>> GnuPG is trying to reach an IPv6 address at all.
>
> Because the resolver tells that there is an  record.  It seems that
> we need to figure out at runtime whether v6 is actually working.  Any
> hints on how to do that?

Reasonable IPv6 stacks should return an ENETUNREACH (Network is
unreachable) error message when trying to connect() to an address for
which there is no route, which should already cause dirmngr to failover
immediately.

I'm not convinced that it's gnupg's job to compensate for
unreasonably-configured IPv6 stacks that think they have a route but
actually don't.

Should gnupg also try to detect whether the IPv4 networking
configuration is actually correct?  That seems like an operating system
level task.  I certainly don't want all of my client software to always
try to second-guess my netwoking stack, that sounds like a recipe for
trouble.

 --dkg

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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Daniel Kahn Gillmor]

On Wed 2015-02-18 11:46:23 -0500, Doug Barton wrote:
> On 2/18/15 2:52 AM, Jonathan Schleifer wrote:
>> Well, I guess you have to take into account that a lot of downloads
>> are from packaging software like pkgsrc, FreeBSD ports, Gentoo
>> portage, ArchLinux's makepkg, etc. Usually, these do download the
>> signature and tarball once, verify it and then write a checksum to
>> the Makefile / PKGBUILD / however it is called that is then
>> verified. So I guess you can't easily map that to "Only x% of users
>> check the downloaded tarball". I guess it's a lot more, it's just not
>> all check it using the .sig.
>
> Back when I was involved with the FreeBSD project I included code in the 
> Makefile to verify the PGP signature for all of my ports that had one, 
> as did a few other maintainers. However there was not only not a 
> consensus to do this more generally, there was active opposition to 
> doing it at all.

that's a bummer :( 

> If you are a FreeBSD user and believe that this would be something 
> beneficial to the ports system, please send them e-mail at 
> freebsd-po...@freebsd.org and let them know. :)

In the Debian Project, we now have a simple framework for including
upstream signing keys and automatically checking them when fetching new
downloads:

  https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

If you see a debian package that could make use of this but isn't
currently configured to do so, please file a bug report in the debian
BTS (or drop me an e-mail).

If it would help with arguing the case within FreeBSD to see how debian
does it, i'm happy to talk with any FreeBSDers about it too.

Regards,

--dkg


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

Re: Double sign a document

[Xavier Maillard]

Hi Jesper,

Jesper Hess Nielsen  writes:

>> gpg -u  -u  --clearsign keytransition.txt >
>> keytransition.signed2
>>
>
> woops, forget about the '> keytransition.signed2' part. Just running
> with --clearsign will give you a keytransition.txt.asc file
> automatically.

Thnaks for that Jesper.

Just a quick question: do I need to have both keypairs in my keyring
? I mean both my old secret key and my new secret key.

Regards
--
Sent with my mu4e


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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Sandeep Murthy]

Hi

I do think your key fingerprint should be made more visible on gpgtools.org
and it would be a good idea to have instructions for users to do the checksum 
and
verify the signature of the dmg (there are probably lots of people who don’t 
even
know how to do checksums).

Sandeep Murthy
s.mur...@mykolab.com

> On 17 Feb 2015, at 21:32, Lukas Pitschl  wrote:
> 
> Hi all,
> 
> since we’ve only now subscribed to the gnupg-users list, unfortunately we 
> can’t reply to the correct message in the thread.
> 
> First off we’d like to apologize for not reacting sooner to this issue. We 
> only today became aware of it, when we received a message on our support 
> platform (thanks Sandeep), and later a comment on Github (thanks Hugo) 
> regarding the affected line of code.
> 
> While we’re responding to all mail and discussions opened on our support 
> platform, we don’t keep track of Twitter regularly. Some  days we see 
> everything going on there and respond immediately and other days we don't 
> check Twitter at all, so unfortunately it's possible that important messages 
> remain unseen.
> 
> The best way to reach us is either our support platform at 
> https://gpgtools.tenderapp.com or t...@gpgtools.org.
> 
> The code that checks out our GPGTools_Core repository is pretty old already 
> and it’s certainly a stupid way to do it.
> At  the time we assumed that it was safe to check it out via ssl from github, 
> since curl would refuse to do so if there was a certificate error. Passing it 
> directly to bash is definitely a bad idea.
> We’ve discussed this internally and decided on removing the automated 
> checkout completely.
> By making it a manual task, everyone can checkout the code and verify that 
> it’s in fact the code they wanted to checkout.
> We will also look through our build system and check for similar code if 
> there is.
> 
> To  address the "Modify source code to allow non-sensical 8192 bit keys" 
> mentioned by Villa: in the past we were too quick to give in to user requests 
> without first researching the side-effects that could be caused by this.
> The „non-sensical 8192 bit keys“ is one instance. It was requested by a few 
> users and a quick „fix“. We’ve seen that homebrew did the same and decided to 
> add this option. We believed if some users wanted this option, we should not 
> hinder them.
> Unfortunately to this day, there still seems to be a lot of disagreement (not 
> on the gnupg list, but other blogs / places on the internet) on whether such 
> a key size makes sense or not. We’ve recently been accused again of 
> "knowlingly lowering the overall security“ [1] by not allowing such a key 
> size.
> We’re still not sure what to do about it exactly.
> 
> In  regards to the fix of PCSC on Yosemite, this is a quick workaround which 
> currently works „well enough“, but we’re still waiting to hear from more 
> users if it’s really fixed. Once it is, we’ll be certain to discuss it on 
> gnupg-devel.
> 
> We’ve been wanting for a while now to discuss our few patches with the 
> gnupg-devel list in order to push them upstream or find a different solution, 
> but unfortunately have been struggling to find time to do that. We also 
> believe that providing gnupg as is on OS X would be the way to go.
> 
> To clarify some info posted on this thread about "GPGTools going commercial“: 
> we will only charge a fee for GPGMail, the rest of GPG Suite will remain 
> free. The source code will also remain open and on Github.
> It's true we sometimes failed to keep it up to date in the past, but we're 
> committed to make sure that it stays current with new releases.
> 
> We really appreciate any feedback and try to address any concerns as quickly 
> as possible. As already mentioned above, it's not always possible for us to 
> keep track of Twitter, so the best way to reach us is via email or our 
> support platform.
> 
> Best,
> 
> Lukas, Steve, Mento
> GPGTools
> 
> [1] 
> http://support.gpgtools.org/discussions/feedback/1132-8k-key-generation-via-keychain-access#comment_35220287
> 
> Am 17.02.2015 um 20:58 schrieb Sandeep Murthy :
> 
>> I would also add that if you agree that more people should
>> be using encryption in more forms then the way to go is
>> to make it more more usable and user friendly (and at the
>> moment the standard GnuPG version can’t exactly be described as
>> that) then this is not an aspiration that should be described
>> as dumb.  What is probably dumb is the kind of purist attitude
>> about the perfect Linux platform and how great it is to have
>> the perfect GnuPG set up.
>> 
>> I would bet that more people who’ve used tools like GPG Suite
>> have taken up encryption than those exposed to the command
>> line subtleties of GnuPG.  Both can be used at the same time,
>> as I do, you don’t have to choose between them.
>> 
>> Sandeep Murthy
>> s.mur...@mykolab.com
>> 
>>> Begin forwarded message:
>>> 
>>> Subject: Re: Please remove MacGPG from gnupg.org due to serious secu

Re: GNUPG 2.* and AIX - questions

[Neal H. Walfield]

At Sun, 15 Feb 2015 12:16:58 +0100,
Michael Felt wrote:
> My key question is about the difference between v1.X and v2.X - are there
> security elements in v2 that are missing/weaker in v1 - or are the
> differences mainly that v2 supports/is always GUI while v1 is always CLI.

gpg2 is a more extensible rewrite of gpg classic.  gpg2 supports some
crypto algorithms that gpg does not support (e.g., ECC starting with
version 2.1).  gpg2 is still for the CLI and makes some CLI operations
easier than gpg.

> The first wall I run into with gnupg-2.0.26 is that it wants gnu threads -
> so, the question is: is there something inherently wrong with POSIX
> threads, or even specifically with AIX pthreads that configure does not
> attempt to use them (by default).

npth uses cooperative threading rather than preemptive threading.
This has the advantage of simplifying code: if you don't explicitly
yield (or use a function that yields), then you can't be preempted.
This can significantly reduce synchronization bugs.

Neal

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

Re: Double sign a document

[Hauke Laging]

Am Mi 18.02.2015, 21:29:40 schrieb Xavier Maillard:

> Jesper Hess Nielsen  writes:
> >> gpg -u  -u  --clearsign keytransition.txt >
> >> keytransition.signed2
> > 
> > woops, forget about the '> keytransition.signed2' part. Just running
> > with --clearsign will give you a keytransition.txt.asc file
> > automatically.
> 
> Thnaks for that Jesper.
> 
> Just a quick question: do I need to have both keypairs in my keyring
> ? I mean both my old secret key and my new secret key.

Of course. Would be strange if you could make a signature without the 
respective secret key.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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: 2.1.2: keyserver route failure

[Ville Määttä]

> On 18 Feb 2015, at 21:13, Daniel Kahn Gillmor  wrote:
> 
> I'm not convinced that it's gnupg's job to compensate for
> unreasonably-configured IPv6 stacks that think they have a route but
> actually don’t.

I agree. I think the actual problem should be addressed at the networking level 
instead of adding logic to GnuPG.

-- 
Ville


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

Re: 2.1.2: keyserver route failure

[Ville Määttä]

> On 18 Feb 2015, at 19:07, Johan Wevers  wrote:
> 
> Admit it, IPv6 has
> failed. It may get some uses, but the widespread adaptation of carrier
> NAT has made it largely obsolete.

Utter, complete, nonsense.

-- 
Ville


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

Re: 2.1.2: keyserver route failure

[Johan Wevers]

On 18-02-2015 19:56, Peter Lebbing wrote:

>> Admit it, IPv6 has failed. It may get some uses, but the widespread
>> adaptation of carrier NAT has made it largely obsolete.

> Tired as I may be of this discussion (what's your next argument, NAT provides
> beneficial firewalling behaviour?), I still wish to say that I will not 
> "admit"
> IPv6 has failed or that IPv4 advancements[1] made it obsolete. Get off your 
> soapbox.

I didn't claim that one version was better than another version, I said
it will probably never become widespread. Just like Linux on the desktop
is only a small niche player, and windows phone on the smartphone
market. Wether I like that or not and which system is best doesn't
change anything.

-- 
Met vriendelijke groet,

Johan Wevers

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

Re: MIME or inline signature ? [OT]

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Tuesday 17 February 2015 at 11:13:18 AM, in
, Jerry wrote:


> That is the reason I detest INLINE as opposed to
> PGP/MIME.

You detest pgp-inline for the main reason I prefer it. Wouldn't life
be boring if we all liked the same things?



> The insertion of superfluous garbage in the
> message body is annoying to say the least.

Given all the corporate non-sense footers "requiring" us to
telepathically know whether or not the sender meant to include us in
the circulation list and to delete it without reading if the answer is
"No", most email users are well-practised at ignoring anything that
seems irrelevant.



> Worse, since
> most users have no concept of "trimming" a message
> before replying to it,

I tend to find those poor unfortunates usually top-post, so all the
extraneous content is off-screen below their message. But so is
anything that could give context to their pearls of wisdom.



> even more useless garbage is
> transmitted when replied to, thus killing more innocent
> electrons

Presumably this virtual massacre adds to the virtual problem of global
warming.



> and wasting bandwidth

Those of us on a metered connection would be with you all the way.
Except that HTML emails are a far bigger bandwidth-hog.



> not to mention the
> consumption of screen territory.

I find that my screen territory all comes back when I delete the
email.




- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

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

iQF8BAEBCgBmBQJU5TlQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwnLoH/3CJk6q9XrgNeam+izDL0tvH
ZdOvUuNjj9qsu1qP5BDTYBWiKE9mMxN4b5RwRFKvPJYrwwd+Q4Bp8zLbskZzUJi6
bsP/XC2loU/7cpFUdMECRglxbKZtC0vYD2L0pabolBehkHXFKiK5ppHN3TOo0RKI
x6fd3d9T8iFhtkWY1cs6vva/AGZIBuwyovQYwdjBuNoaxMTiz/c2Wc11wMjnmhQQ
6I4/Pt+wgl2e6VUphm/6fVgbFmV6OxJb1hIsBHpPdW74MiK2IY42MlsHdURjGrsk
a8Q12DYE2IVO4Nad4S7l2lHDi1S8sikp0OXu5ApFzKAtMtGPFSWV3DYCBKq1zBaI
vgQBFgoAZgUCVOU5Xl8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45A0mAQAarb8UhID55PQN+Xa9t1aA+q5o
Cd8mL9gQmt7A3hDEDQEAsqfT2P7Qe5XnOifp+PS8k4LnOpbn1Z1iJWNmXgabzgg=
=xgmS
-END PGP SIGNATURE-


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

Re: Double sign a document

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Wednesday 18 February 2015 at 8:29:40 PM, in
, Xavier Maillard wrote:




> Just a quick question: do I need to have both keypairs
> in my keyring ? I mean both my old secret key and my
> new secret key.

To sign, yes. To check the signatures you would just need both public
keys.



- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

During an eruption - move away from the volcano - not towards it
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJU5TzyXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwhMoIAL3XmuF4NiiDC3Cpt9AwZOy1
NSl/Hblwq0Syv36jZkiqxvFK8etQPm/v2oKjdvQ7pqlBccxmtl15pYWBQgJ/KmK6
K9ALUyPqEyuxeW+b6vl1/6ZoSV+XJJZl3alg4FFI1RN0ZkixXaPL0dnZgX2j40Q0
pce4ss/ZlBxQOL7qzAkoobPr2OfZo72l0cuJdltwTbKAQnUMyFBedRX2aqIiDXHV
E33Ip7BixMKNMrL3QGPiWRqCM4AJX4/GUxD3RS+wnNWVVmhT2QfA0HLZayTUjt1N
tisL1F54C6TDlIjTfjPUSx1EOUGZIA0InxEZZN546G/IIj2PLr53q3/Vc6inDNuI
vgQBFgoAZgUCVOU8+F8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45FuoAQBAizU7Cwj8FN94YWowNY5a1TIZ
ox/OWzaq35fGigWwTwEADCz3Nj4XopZeNYF26E+qh0xJOmUpeMgFLQI+4YNmqgE=
=24p4
-END PGP SIGNATURE-


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

Re: 2.1.2: keyserver route failure

[Robert J. Hansen]

> I didn't claim that one version was better than another version, I
> said it will probably never become widespread.

It already *is* widespread.  China and Japan have signed onto it in a
big way.  In the US, the largest wireless carrier -- Verizon -- has
migrated over a third of its smartphones to IPv6, and plans to migrate
the rest in the next few years.

The largest Aussie telecom firm, Telstra, is 100% dual-stacked.

22% of Deutsche Telekom DSL customers are on IPv6 and they're migrating
mobile devices to IPv6 this summer.

IPv6 adoption is largely invisible, but it's picking up worldwide.

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

Re: 2.1.2: keyserver route failure

[Robert J. Hansen]

> I'm not convinced that it's gnupg's job to compensate for 
> unreasonably-configured IPv6 stacks that think they have a route but 
> actually don't.

Nor am I, but the world has never much cared whether something was my
job: it concerns itself more with ensuring there are consequences for
the job going undone.

At the very least, if we're not going to address the problem we should
(a) reach out to Apple about the problem and (b) document for OS X users
that GnuPG's keyserver functionality may be broken on that platform.

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

Re: 2.1.2: keyserver route failure

[Doug Barton]

It was not my intention to start an IPv6 advocacy thread, but in case 
anyone is interested in facts about the current state of things, this is 
a good summary:


http://www.slideshare.net/AkamaiTechnologies/edge-2014-ipv6-is-here-what-you-need-to-know

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

Help need to use truecryt + openpgp applet.

[Ranjini H.K]

Hi all,

Am trying to implement disk encryption/decryption using truecrypt with
security token support. I have a java card with openPGP applet loaded on to
it. Inspite of configuring truecrypt to use the security token, its not
finding it and notififng me with an error saying : security token error
"FUNCTION NOT SUPPORTED ".

Please help me with this.

Regards,

Ranjini HK

Software Engineer - Tyfone, Inc.

Bangalore
www.tyfone.com

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

Re: Help need to use truecryt + openpgp applet.

[Robert J. Hansen]

> Please help me with this.

Unfortunately, we really can't.  GnuPG is written in C, not Java, so
it's unlikely your OpenPGP applet uses GnuPG.  You might have better
luck on a mailing list for the applet you're using.

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

Re: Please remove MacGPG from gnupg.org due to serious security concerns

[Peter Lebbing]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/02/15 22:32, Lukas Pitschl wrote:
> We’ve recently been accused again of "knowlingly lowering the overall 
> security“ [1] by not allowing such a key size. We’re still not sure what
> to do about it exactly.

There will always be people who think they know better and be very... vocal
about it on the internet. I'm sure it has been mentioned how they'll switch to
another program if you don't comply with their demands instantly... :(

I think you should just ignore them and not second-guess the security related
decisions taken by your upstream, the GnuPG project. I don't see any reason
why a version for Mac would need different RSA key size limits than a version
for Linux or Windows.[1]

In fact, the second-guessing might actually unintentionally lower the overall
security...

My 2 cents,

Peter.

[1] Unless of course all Macs are much more powerful and Mac users only
communicate with Mac users... just kidding :P

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

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