Re: Help GnuPG install

[Mercury Rising]

What is the Best set up of GnuPG on Mac OS X Mavericks
?

On Tue, Apr 28, 2015 at 9:44 AM, Mercury Rising 
wrote:

> I had Gpg keys only on my Mac w/some old keys in the file. I downloaded
> the latest version OS GPG Tools. I have the Mavericks Flavor of OS X and I
> noticed too late it was for Mac Yosemity. Nothing works now. I did off load
> all the keys into a text file. So what works with Maverics that I can use?
> I need something easy to use as far as a front end for key management and
> encrypting and decrypting Gpg and PGP messages. Can GPG/GnuPG encrypt to
> PGP RSA public
> Keys?
>
>  Elwin
>
>
>
>
>
>
>
>>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Notes from the first OpenPGP Summit

[Neal H. Walfield]

At Tue, 28 Apr 2015 17:38:53 +0200,
Werner Koch wrote:
> On Tue, 28 Apr 2015 17:02, n...@walfield.org said:
> 
> > I've added a checkbox to pinentry that asks: "Cache password with GKR"
> > and it is only shown if GKR is present.  So it's opt-in.
> 
> Good.  While you are at it: Please also add a checkbox to not hide the
> passphrase in the entry field.  Being able to see what one types is very
> convenient for long passphrases if you are anyway below a sheet while
> typing

I can do this.  But, I'll do it as a separate patch.

Neal

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

Help GnuPG install

[Mercury Rising]

I had Gpg keys only on my Mac w/some old keys in the file. I downloaded the
latest version OS GPG Tools. I have the Mavericks Flavor of OS X and I
noticed too late it was for Mac Yosemity. Nothing works now. I did off load
all the keys into a text file. So what works with Maverics that I can use?
I need something easy to use as far as a front end for key management and
encrypting and decrypting Gpg and PGP messages. Can GPG/GnuPG encrypt to
PGP RSA public
Keys?

 Elwin







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

Re: Notes from the first OpenPGP Summit

[Werner Koch]

On Tue, 28 Apr 2015 18:17, d...@fifthhorseman.net said:

> :)  I'm assuming that Neal is adding this hook to pinentry-gtk2, and not
> to the others, but i haven't checked.

Yes, with a configure option so the user/distro can decide.  I do not
want that for my gtk version.

Originally I leaned against the idea of writing such a pinentry and
hoped that the GONE folks will do that.  But that was no way forward and
thus we have to bite the bullet and implement it for them.


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: Building libgpg-error for powerpc64-e5500-linux-gnu

[Werner Koch]

On Tue, 28 Apr 2015 17:55, gborow...@advaoptical.com said:

> And is there an architecture-independent and ABI-independent way of building 
> libgpg-error?

No.  I know that this change in libgpg-error is annoying but I decided
for it so to decouple libgpg-error's API from pthreads.  By not using
pthread mutexes directly using libgpg-error will be much easier.


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: Notes from the first OpenPGP Summit

[Robert J. Hansen]

> Well, gnupg currently distributes four different pinentries:

Point.  I still think if GKD wants to hook into a pinentry, they need to
distribute their own pinentry instead of modifying one that GnuPG maintains.

Given pinentry-gtk2 is FOSS, it shouldn't be too hard for them to fork
it, make their changes, and distribute it.  I just don't want to see
GNOME 3-specific code in a pinentry for GTK+2, as that seems pretty far
out of scope.



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

Re: Notes from the first OpenPGP Summit

[Daniel Kahn Gillmor]

On Tue 2015-04-28 11:36:34 -0400, Robert J. Hansen wrote:
> I'm not objecting to the idea of GKD providing its own pinentry:
> creating a gkd-pinentry sounds like a good idea.

OK, that's good!

> I'm objecting to what I read (and possibly misread) as placing GKD hooks
> into the *GnuPG-distributed* pinentry.
>
> I would suggest that in the future we talk about "pinentry" only for
> GnuPG's pinentry, and "foo-pinentry" to denote a pinentry provided by
> foo, so as to prevent future misunderstandings.  :)

Well, gnupg currently distributes four different pinentries:

 pinentry-gtk2
 pinentry-qt4
 pinentry-curses
 pinentry-tty

:)  I'm assuming that Neal is adding this hook to pinentry-gtk2, and not
to the others, but i haven't checked.

BTW: thanks, Neal!

 --dkg

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

Re: Generating GnuPG S/MINE key pair

[Dan Bryant]

OK... I'm apparently suffering from a bad gpgsm setup.  According to
the 2011 post 
(https://lists.gnupg.org/pipermail/gnupg-devel/2011-March/025989.html)
the following command, should just work:
   gpgsm --gen-key | gpgsm --import

Not for me... I get
  gpgsm: problem looking for existing certificate: Invalid argument
  gpgsm: error storing certificate

Moreover just trying to dump my keystore with "gpgsm -k" gives errors
  gpgsm: keydb_search failed: Invalid argument

Here's a dump of my failed import attempt.

C:\Program Files (x86)\GNU\GnuPG>gpgsm --gen-key | gpgsm --import
gpgsm (GnuPG) 2.1.3; Copyright (C) 2015 Free Software Foundation,
This is free software: you are free to change and redistribute it
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA
   (2) Existing key
   (3) Existing key from card
Your selection? 1
What keysize do you want? (2048)
Requested keysize is 2048 bits
Possible actions for a RSA key:
   (1) sign, encrypt
   (2) sign
   (3) encrypt
Your selection? 1
Enter the X.509 subject name: CN=test cert
Enter email addresses (end with an empty line):
>
Enter DNS names (optional; end with an empty line):
>
Enter URIs (optional; end with an empty line):
>
Create self-signed certificate? (y/N) y
These parameters are used:
Key-Type: RSA
Key-Length: 2048
Key-Usage: sign, encrypt
Serial: random
Name-DN: CN=test cert

Proceed with creation? (y/N) y
Now creating self-signed certificate.  This may take a while ...
gpgsm: about to sign the certificate for key: &77C68CE5AC362254D7
gpgsm: certificate created
Ready.
gpgsm: problem looking for existing certificate: Invalid argument
gpgsm: error storing certificate
gpgsm: total number processed: 1
gpgsm:   not imported: 1


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

Re: Building libgpg-error for powerpc64-e5500-linux-gnu

[Grzegorz Borowiak]

Thank you for so quick answer.
I will try how it works.
I'm almost sure the ABI is the same, but I must check. 

And is there an architecture-independent and ABI-independent way of building 
libgpg-error?


From: Werner Koch 
Sent: 28 April 2015 17:48
To: Grzegorz Borowiak
Cc: gnupg-users@gnupg.org
Subject: Re: Building libgpg-error for powerpc64-e5500-linux-gnu

On Tue, 28 Apr 2015 14:32, gborow...@advaoptical.com said:

> Can I somehow convince it to recognise powerpc64-e5500-linux-gnu as
> powerpc64-unknown-linux-gnu?

If both systems use the same ABI config.sub should have returned a
canonicalized versions.  If not we can use a new mechanism available in
1.19.  You need to change the code, though: In src/mkheader.c find the
function

--8<---cut here---start->8---
static char *
canon_host_triplet (const char *triplet)
{
  struct {
const char *name;
const char *alias;
  } tbl[] = {
{"i486-pc-linux-gnu", "i686-pc-linux-gnu" },
{"i586-pc-linux-gnu" },

{ NULL }
  };
--8<---cut here---end--->8---

and add a line

{"powerpc64-e5500-linux-gnu", "powerpc64-unknown-linux-gnu" },

before the {NULL} marker.  But do that only if you are sure both use the
same ABI.

Let me know if this works and I'll add it for 1.20.


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: Building libgpg-error for powerpc64-e5500-linux-gnu

[Werner Koch]

On Tue, 28 Apr 2015 14:32, gborow...@advaoptical.com said:

> Can I somehow convince it to recognise powerpc64-e5500-linux-gnu as
> powerpc64-unknown-linux-gnu?

If both systems use the same ABI config.sub should have returned a
canonicalized versions.  If not we can use a new mechanism available in
1.19.  You need to change the code, though: In src/mkheader.c find the
function

--8<---cut here---start->8---
static char *
canon_host_triplet (const char *triplet)
{
  struct {
const char *name;
const char *alias;
  } tbl[] = {
{"i486-pc-linux-gnu", "i686-pc-linux-gnu" },
{"i586-pc-linux-gnu" },

{ NULL }
  };
--8<---cut here---end--->8---

and add a line

{"powerpc64-e5500-linux-gnu", "powerpc64-unknown-linux-gnu" },

before the {NULL} marker.  But do that only if you are sure both use the
same ABI.

Let me know if this works and I'll add it for 1.20.


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: Notes from the first OpenPGP Summit

[Werner Koch]

On Tue, 28 Apr 2015 17:02, n...@walfield.org said:

> I've added a checkbox to pinentry that asks: "Cache password with GKR"
> and it is only shown if GKR is present.  So it's opt-in.

Good.  While you are at it: Please also add a checkbox to not hide the
passphrase in the entry field.  Being able to see what one types is very
convenient for long passphrases if you are anyway below a sheet while
typing

> I don't understand this "if".  GKR is implementing (a subset of) gpg
> agent's protocol.

[ Actually it implements what Robert Bihlmeyer's Quintuple-Agent did in
  1999.  It completely bypasses the design of gpg-agent where the
  passphrase caching is just an add-on. ]

> Also, the GPG Tools people (Mac OS) do something similar to GKR (but
> less invasive) so the modifications to the gpg core will help them as

Right, the OS X keychain seems to do the same what GKR does or vice
versa.


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: Notes from the first OpenPGP Summit

[Robert J. Hansen]

> Every environment is free to implement its own pinentry, and we've never
> discouraged that (indeed, gnupg upstream ships several pinentry
> variants).  If a pinentry variant chooses to implement its own
> passphrase cache, that is up to that pinentry variant, no?

I'm not objecting to the idea of GKD providing its own pinentry:
creating a gkd-pinentry sounds like a good idea.

I'm objecting to what I read (and possibly misread) as placing GKD hooks
into the *GnuPG-distributed* pinentry.

I would suggest that in the future we talk about "pinentry" only for
GnuPG's pinentry, and "foo-pinentry" to denote a pinentry provided by
foo, so as to prevent future misunderstandings.  :)




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

Re: Notes from the first OpenPGP Summit

[Hans-Christoph Steiner]

Werner Koch:
> On Mon, 27 Apr 2015 01:31, b...@pagekite.net said:
>> Thanks for the write-up, Werner! :-)
> 
> Actually you have been much faster with your report
> https://www.mailpile.is/blog/2015-04-20_OpenPGP_Email_Summit.html
> 
>>>   disappointed that many of the participants favored this closed
>>>   invitation-only style summit and want the next meeting to happen the
> 
>> On the one hand, I suspect it would be very hard to maintain the
>> excellent signal/noise ratio we had, in a completely open summit. On
> 
> Maybe.  We are used to work on mailing list and I would bet that in most
> cases it is easier to ask too noisy participants to behave well during a
> physical meeting than on mailing lists.  The IETF has quite some
> experience with that and requires physical meetings for important tasks.

In my 20 years of experience attending and organizing all sorts of tech
conferences, I find that open conferences tend to better than closed ones.
But mostly, the open- or closedness is not the biggest factor in the signal to
noise ratio. Instead, it is the level of organization.

The best conferences I've been to have been completely open and mostly
self-organized (aka Barcamp aka Unconference).  But that requires a specific
audience that is well practiced in self-organization.  I have been to very
good conferences that were semi-self-organized, i.e. barcamp-style with some
well practiced moderators really guiding the whole process (for example, a
"Gunner Event" run by Aspiration Tech). And as Werner says, it is much easier
to tell people in person to reduce the noise than it is on all of the various
open internet forums we operate on.

I really think it is quite important that these summits are open to anyone who
wants to attend.  I have run a number of barcamps with small groups, so I'm
happy to help moderate if I can attend.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

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

Re: Notes from the first OpenPGP Summit

[Neal H. Walfield]

At Tue, 28 Apr 2015 10:26:05 -0400,
Robert J. Hansen wrote:
> > The solution is to fix Gnome Keyring :).  I've spoken with Stef, the
> > main developer of GKR, and he confirmed that the only reason GKR 
> > MITMs GPG Agent is so that it can intercept prompts for the password 
> > to supply any cached value.
> 
> This doesn't seem like a good reason.  It never has.  If I configure
> gpg-agent to cache for 20 minutes, but forget to configure
> gnome-keyring-daemon, then it's possible that 25 minutes later I'll do
> something requiring a passphrase, gpg-agent will ask me for my
> passphrase, but gnome-keyring-daemon will silently intercept it and use
> the cached value, etc., etc., leaving me wondering why gpg-agent isn't
> respecting the timeout I've given it.

I've added a checkbox to pinentry that asks: "Cache password with GKR"
and it is only shown if GKR is present.  So it's opt-in.

> This also means passphrases are cached in two places, not one -- in
> gpg-agent and in gnome-keyring-daemon.  In my day job I work in digital
> forensics, with a good bit of memory forensics work in my past.
> Speaking as a forensicist, if you keep two copies of a sensitive
> passphrase in memory you're making things much easier for me.

There are so many attack vectors that providing this opt-in hardly
seems to make a difference to me.  If we actually had process
isolation, I might agree with you.  But, as things stand, we don't.  I
wouldn't allow GKR to cache my passphrase either, but other people
disagree.  In particular, the maintainer of GKR, which is widely used
and practically a hard requirement even on Xfce.

> I don't understand GKD's choices here.  I never have.  They've always
> seemed foolish.  If GKD wants to implement gpg-agent's protocol and run
> as a replacement gpg-agent, that's one thing... but the current setup
> just does not strike me as wise.

I don't understand this "if".  GKR is implementing (a subset of) gpg
agent's protocol.

> I'm sorry, but I don't think this is a good solution.  GNOME is asking
> for privileges other desktop environments haven't asked for and don't
> get. KDE doesn't get KDE-specific functionality added to pinentry.  Nor
> does XFCE, nor does Enlightenment.  If GNOME gets to have GNOME-specific
> enhancements folded into GnuPG, then what's to prevent KDE, XFCE,
> Enlightenment, Windows, OS X, and all other desktop environments from
> demanding the same?

Actually, the secrets API is a desktop standard and I was told KWallet
speaks it.  So, this enhancement will work with KWallet as well.
Also, the GPG Tools people (Mac OS) do something similar to GKR (but
less invasive) so the modifications to the gpg core will help them as
well.

Neal





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

Re: Notes from the first OpenPGP Summit

[Daniel Kahn Gillmor]

On Tue 2015-04-28 10:26:05 -0400, Robert J. Hansen wrote:
> This doesn't seem like a good reason.  It never has.  If I configure
> gpg-agent to cache for 20 minutes, but forget to configure
> gnome-keyring-daemon, then it's possible that 25 minutes later I'll do
> something requiring a passphrase, gpg-agent will ask me for my
> passphrase, but gnome-keyring-daemon will silently intercept it and use
> the cached value, etc., etc., leaving me wondering why gpg-agent isn't
> respecting the timeout I've given it.

agreed, this does seem suboptimal, but it's better than the current
case, where things simply don't work at all.

> I don't understand GKD's choices here.  I never have.  They've always
> seemed foolish.  If GKD wants to implement gpg-agent's protocol and run
> as a replacement gpg-agent, that's one thing... but the current setup
> just does not strike me as wise.

GKD's goal is to provide a smooth user experience, where all the user's
passwords are handled as silently as possible, behind the scenes.

However, they do not appear to have the resources to track the full
functionality of gpg-agent, so they're falling down on that front.

tracking the functionality of pinentry should be a simpler task.

>> The solution is to enhance pinentry so that if GKR is available it 
>> caches the password with GKR.
>
> I'm sorry, but I don't think this is a good solution.  GNOME is asking
> for privileges other desktop environments haven't asked for and don't
> get. KDE doesn't get KDE-specific functionality added to pinentry.  Nor
> does XFCE, nor does Enlightenment.  If GNOME gets to have GNOME-specific
> enhancements folded into GnuPG, then what's to prevent KDE, XFCE,
> Enlightenment, Windows, OS X, and all other desktop environments from
> demanding the same?

Every environment is free to implement its own pinentry, and we've never
discouraged that (indeed, gnupg upstream ships several pinentry
variants).  If a pinentry variant chooses to implement its own
passphrase cache, that is up to that pinentry variant, no?

   --dkg

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

Re: Notes from the first OpenPGP Summit

[Robert J. Hansen]

> The solution is to fix Gnome Keyring :).  I've spoken with Stef, the
> main developer of GKR, and he confirmed that the only reason GKR 
> MITMs GPG Agent is so that it can intercept prompts for the password 
> to supply any cached value.

This doesn't seem like a good reason.  It never has.  If I configure
gpg-agent to cache for 20 minutes, but forget to configure
gnome-keyring-daemon, then it's possible that 25 minutes later I'll do
something requiring a passphrase, gpg-agent will ask me for my
passphrase, but gnome-keyring-daemon will silently intercept it and use
the cached value, etc., etc., leaving me wondering why gpg-agent isn't
respecting the timeout I've given it.

This also means passphrases are cached in two places, not one -- in
gpg-agent and in gnome-keyring-daemon.  In my day job I work in digital
forensics, with a good bit of memory forensics work in my past.
Speaking as a forensicist, if you keep two copies of a sensitive
passphrase in memory you're making things much easier for me.

I don't understand GKD's choices here.  I never have.  They've always
seemed foolish.  If GKD wants to implement gpg-agent's protocol and run
as a replacement gpg-agent, that's one thing... but the current setup
just does not strike me as wise.

> The solution is to enhance pinentry so that if GKR is available it 
> caches the password with GKR.

I'm sorry, but I don't think this is a good solution.  GNOME is asking
for privileges other desktop environments haven't asked for and don't
get. KDE doesn't get KDE-specific functionality added to pinentry.  Nor
does XFCE, nor does Enlightenment.  If GNOME gets to have GNOME-specific
enhancements folded into GnuPG, then what's to prevent KDE, XFCE,
Enlightenment, Windows, OS X, and all other desktop environments from
demanding the same?



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

Re: Notes from the first OpenPGP Summit

[Simon Josefsson]

"Neal H. Walfield"  writes:

> Hi Simon,
>
> We've documented the problem at http://wiki.gnupg.org/GnomeKeyring .

Thanks -- another workaround, alas.

> The solution is to fix Gnome Keyring :).  I've spoken with Stef, the
> main developer of GKR, and he confirmed that the only reason GKR MITMs
> GPG Agent is so that it can intercept prompts for the password to
> supply any cached value.  The solution is to enhance pinentry so that
> if GKR is available it caches the password with GKR.  This requires a
> few modifications to GnuPG proper as well as enhancements to pinentry.
> I'm working on this and it should be done shortly.  The GPG Tools
> people also need this functionality in GPG 2.0 so it will also be
> backported.  We hope to coordinate with Debian to get the fixed
> versions of GPG and GKR in the next point release of Jessie.

Great, I'm really looking forward to a proper fix to this problem.

/Simon


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

Re: Notes from the first OpenPGP Summit

[Neal H. Walfield]

Hi Simon,

We've documented the problem at http://wiki.gnupg.org/GnomeKeyring .

At Tue, 28 Apr 2015 14:45:22 +0200,
Simon Josefsson wrote:
> Werner Koch  writes:
> 
> >   I appreciated the opportunity to meet the GPG Tools developers, who
> >   are very dedicated to make GnuPG working well on OS X.  I stressed the
> >   importance to actively participate on the GnuPG mailing list to keep
> >   information in sync.  One example may illustrate this: For years the
> >   adaption of GnuPG-2 on GNOME based systems has been hampered by the
> >   fact that the gnome-keyring-manager (GKR) tries to emulate gpg-agent
> >   and thus inhibits proper working of any advanced function of GnuPG
> >   (e.g. smartcards and gpgsm).  With Debian’s release of Jessie that
> >   problem will even be worse due to other desktop environments now also
> >   using GKR.  Given that the GKR developers are not willing to change
> >   their defaults, Neal, dkg, and me came up with a pragmatic solution
> >   for this problem on Saturday morning.
> 
> What is this solution?
> 
> I am working around the bug in Jessie [1], but GKR's bug/design is a
> real pain if you want to convince others to start to use GnuPG with
> smartcards.  I recently noticed that my fix doesn't even work on Ubuntu,
> so each OS need their own fix... :-(

The solution is to fix Gnome Keyring :).  I've spoken with Stef, the
main developer of GKR, and he confirmed that the only reason GKR MITMs
GPG Agent is so that it can intercept prompts for the password to
supply any cached value.  The solution is to enhance pinentry so that
if GKR is available it caches the password with GKR.  This requires a
few modifications to GnuPG proper as well as enhancements to pinentry.
I'm working on this and it should be done shortly.  The GPG Tools
people also need this functionality in GPG 2.0 so it will also be
backported.  We hope to coordinate with Debian to get the fixed
versions of GPG and GKR in the next point release of Jessie.

Neal

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

Re: Notes from the first OpenPGP Summit

[Simon Josefsson]

Werner Koch  writes:

>   I appreciated the opportunity to meet the GPG Tools developers, who
>   are very dedicated to make GnuPG working well on OS X.  I stressed the
>   importance to actively participate on the GnuPG mailing list to keep
>   information in sync.  One example may illustrate this: For years the
>   adaption of GnuPG-2 on GNOME based systems has been hampered by the
>   fact that the gnome-keyring-manager (GKR) tries to emulate gpg-agent
>   and thus inhibits proper working of any advanced function of GnuPG
>   (e.g. smartcards and gpgsm).  With Debian’s release of Jessie that
>   problem will even be worse due to other desktop environments now also
>   using GKR.  Given that the GKR developers are not willing to change
>   their defaults, Neal, dkg, and me came up with a pragmatic solution
>   for this problem on Saturday morning.

What is this solution?

I am working around the bug in Jessie [1], but GKR's bug/design is a
real pain if you want to convince others to start to use GnuPG with
smartcards.  I recently noticed that my fix doesn't even work on Ubuntu,
so each OS need their own fix... :-(

/Simon

[1] http://blog.josefsson.org/2015/01/02/openpgp-smartcards-and-gnome/


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

Building libgpg-error for powerpc64-e5500-linux-gnu

[Grzegorz Borowiak]

I'm trying to cross-compile libgpg-error for powerpc64-e5500-linux-gnu and I 
fail:




make[1]: Entering directory 
'/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18-.default'
Making all in m4
make[2]: Entering directory 
'/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18-.default/m4'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory 
'/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18-.default/m4'
Making all in src
make[2]: Entering directory 
'/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18-.default/src'
gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkerrnos.awk
 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/errnos.in
 >code-to-errno.h
gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkerrcodes1.awk
 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/errnos.in
 >_mkerrcodes.h
gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkstrtable.awk
 -v textidx=2 -v nogettext=1 \

/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/err-sources.h.in
 >err-sources-sym.h
gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkstrtable.awk
 -v textidx=2 -v nogettext=1 \

/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/err-codes.h.in
 >err-codes-sym.h
powerpc64-e5500-linux-gnu-gcc -E   _mkerrcodes.h | grep GPG_ERR_ | \
   gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkerrcodes.awk
 >mkerrcodes.h
gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkstrtable.awk
 -v textidx=2 -v nogettext=1 \
-v prefix=GPG_ERR_ -v namespace=errnos_ \

/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/errnos.in
 >errnos-sym.h
x86_64-pc-linux-gnu-gcc -g -O0 -I. 
-I/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src
 -o mkheader 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkheader.c
cat 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/gpg-error.def.in
 >_gpg-error.def.h
echo "/*dummy*/" > mkw32errmap.map.c
powerpc64-e5500-linux-gnu-gcc -E -I. 
-I/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src
 -I..   _gpg-error.def.h | \
  grep -v '^#' >gpg-error.def
rm _mkerrcodes.h
x86_64-pc-linux-gnu-gcc -I. 
-I/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src
 -o mkerrcodes 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkerrcodes.c
rm _gpg-error.def.h
rm lock-obj-pub.native.h 2>/dev/null
./mkerrcodes | gawk -f 
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/mkerrcodes2.awk
 >code-from-errno.h
Makefile:1282: recipe for target 'gpg-error.h' failed
make[2]: [gpg-error.h] Error 1 (ignored)
./mkheader linux-gnu powerpc64-e5500-linux-gnu  
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/gpg-error.h.in
 \
   ../config.h 1.18 0x011200 >gpg-error.h
/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/gpg-error.h.in:320:
 error including 
`/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18/src/syscfg/lock-obj-pub.linux-gnu.h':
 No such file or directory
Makefile:1282: recipe for target 'gpg-error.h' failed
make[2]: *** [gpg-error.h] Error 1
make[2]: Leaving directory 
'/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18-.default/src'
Makefile:470: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
'/targ/arch/powerpc64-e5500-linux-gnu/modes/eos/tmp/portage/dev-libs/libgpg-error-1.18/work/libgpg-error-1.18-.default'
Makefile:401: recipe for target 'all' failed
make: *** [all] Error 2


I al

Re: Generating GnuPG S/MINE key pair

[Werner Koch]

On Mon, 27 Apr 2015 22:07, dkbry...@gmail.com said:

> gpgsm: no issuer found in certificate
> gpgsm: basic certificate checks failed - not imported

Your root certificate is not valid.  An Issuer is required and that
issuer must match the Subject.  Also certain other fields are required
for a root certificate. I suggest to use a tool like tinyca2 to create
your own CA or use one of the scripts which come with OpenSSL to setup a
CA (you need a Unix shell on Windows, though).

gpgsm 2.1 has a much improve certifciate generation.  You may create a
self-signed certificate directly:

--8<---cut here---start->8---
$ gpgsm --gen-key
Please select what kind of key you want:
   (1) RSA
   (2) Existing key
   (3) Existing key from card
Your selection? 1
What keysize do you want? (2048) 
Requested keysize is 2048 bits
Possible actions for a RSA key:
   (1) sign, encrypt
   (2) sign
   (3) encrypt
Your selection? 1
Enter the X.509 subject name: CN=test cert
Enter email addresses (end with an empty line):
> 
Enter DNS names (optional; end with an empty line):
> 
Enter URIs (optional; end with an empty line):
> 
Create self-signed certificate? (y/N) y
These parameters are used:
Key-Type: RSA
Key-Length: 2048
Key-Usage: sign, encrypt
Serial: random
Name-DN: CN=test cert

Proceed with creation? (y/N) 
--8<---cut here---end--->8---

This works well on Windows - however the installer for 2.1.3 is a bit
experimental.

  gpgsm --export-secret-key-p8 -a KEYID

may then be used to export the private key in PKCS#8 format (what Apache
etc requires.



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