From immanuel.scholz at tu-dresden.de  Mon Sep  3 18:28:16 2007
From: immanuel.scholz at tu-dresden.de (Immanuel Scholz)
Date: Mon, 03 Sep 2007 18:28:16 +0200
Subject: Query the default key via command line?
In-Reply-To: <87lkbr4vrs.fsf@wheatstone.g10code.de>
References: <46D6B340.2020803@tu-dresden.de>	<871wdk6shw.fsf@wheatstone.g10code.de>	<46D7E032.5030309@tu-dresden.de>
	<87lkbr4vrs.fsf@wheatstone.g10code.de>
Message-ID: <46DC3620.1010902@tu-dresden.de>



Werner Koch schrieb:
> On Fri, 31 Aug 2007 11:32, immanuel.scholz at tu-dresden.de said:
> 
>> This triggers any password agent, doesn't it?
> 
> For encryption you don't need the secret key and ghus there won't be a
> passphrase prompt.

What are the command line options to encrypt to the default key?

~$ echo "" | gpg --batch -e
gpg: no valid addressees
gpg: [stdin]: encryption failed: no such user id
~$


>> Really ugly, though... (and of course, the greps and cuts have to be
>> done within the program to be usable under windows ;)
> 
> It is not that hard if you already have spawn and pipe functions ready.
> gpgconf-comp.c has some code you could reuse.

grep and cutting the USER_HINT status-fd output isn't the ugly part. It
is more the "signing with an invalid password-fd and then hope the gpg
spit out the key-id as a hint" - part. It feels naughty ;-)


>> ~$ cat .gnupg/gpg.conf | grep ^default
>> default-key 91723535
> 
> Ah right, my current gpg2 has this feature, whereas gpg 1.4.7 is missing
> it.  BTW, the supported options can be listed using
> 
>   gpg --gpgconf-list

Doesn't work either.

~$ gpg2 --gpgconf-list
gpgconf-gpg.conf:16:"/home/imi/.gnupg/gpg.conf
verbose:0:
quiet:0:
keyserver:0:
reader-port:0:
~$ gpg2 --version
gpg (GnuPG) 2.0.3
Copyright (C) 2007 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ELG
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
Hash: MD5, SHA1, RIPEMD160, TIGER192, SHA256, SHA384, SHA512
Compression: Uncompressed, ZIP, ZLIB, BZIP2
~$


At least I get the location of the config file somewhat platform
independent...

Ciao, Imi.

-- 
DF0E A04F 7063 69C5 A76B  7557 0A77 608F 9172 3535


From eric at debian.org  Sun Sep  9 04:37:55 2007
From: eric at debian.org (Eric Dorland)
Date: Sat, 8 Sep 2007 22:37:55 -0400
Subject: [PATCH] Add hostname to default env file
Message-ID: <20070909023755.GN19367@gambit>

Hello,

Jari Alto filed this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403833

And I've written this patch to appease him. Let me know what you
think. 



-- 
Eric Dorland <eric at kuroneko.ca>
ICQ: #61138586, Jabber: hooty at jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: agent-info.diff
Type: text/x-diff
Size: 1717 bytes
Desc: not available
Url : /pipermail/attachments/20070908/e136c0eb/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20070908/e136c0eb/attachment.pgp 

From wk at gnupg.org  Mon Sep 10 11:02:31 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Sep 2007 11:02:31 +0200
Subject: [PATCH] Add hostname to default env file
In-Reply-To: <20070909023755.GN19367@gambit> (Eric Dorland's message of "Sat, 
	8 Sep 2007 22:37:55 -0400")
References: <20070909023755.GN19367@gambit>
Message-ID: <871wd6x594.fsf@wheatstone.g10code.de>

On Sun,  9 Sep 2007 04:37, eric at debian.org said:

> And I've written this patch to appease him. Let me know what you
> think. 

This breaks existing installations.  What about using 

  gpg-agent --write-env-file ${HOME}/.gpg-agent-info-$(hostname) ...

in the startup script?  Eventually we might want to store the socket
files at a fixed location like /tmp/gnupg-$USER/foo-socket instead of
having them at a variable place.  What does the file system standard
says about this?


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From eric at kuroneko.ca  Sun Sep  9 04:37:55 2007
From: eric at kuroneko.ca (Eric Dorland)
Date: Sat, 8 Sep 2007 22:37:55 -0400
Subject: [PATCH] Add hostname to default env file
Message-ID: <20070909023755.GN19367@gambit>

Hello,

Jari Alto filed this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403833

And I've written this patch to appease him. Let me know what you
think. 



-- 
Eric Dorland <eric at kuroneko.ca>
ICQ: #61138586, Jabber: hooty at jabber.com
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-------------- next part --------------
A non-text attachment was scrubbed...
Name: agent-info.diff
Type: text/x-diff
Size: 1717 bytes
Desc: not available
Url : /pipermail/attachments/20070908/e136c0eb/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20070908/e136c0eb/attachment-0002.pgp 

From marcus.brinkmann at ruhr-uni-bochum.de  Mon Sep 10 18:26:04 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 10 Sep 2007 18:26:04 +0200
Subject: GPGME callback function problem
In-Reply-To: <12432859.post@talk.nabble.com>
References: <12428139.post@talk.nabble.com>
	<87d4x31vxc.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<12432859.post@talk.nabble.com>
Message-ID: <87bqcazdur.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Fri, 31 Aug 2007 12:44:47 -0700 (PDT),
alan_b <gtbui at yahoo.com> wrote:
> 
> 
> So, in that callback function, what W32 function call should I use to write
> the password to the fd ?
> The original code is write( ), which did not compile in Windows.  I replaced
> it with _write( ), which gave the assertion error on the fd.

WriteFile

Marcus



From marcus.brinkmann at ruhr-uni-bochum.de  Mon Sep 10 18:49:38 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Mon, 10 Sep 2007 18:49:38 +0200
Subject: GPGME callback function problem
In-Reply-To: <46E572E8.9090809@bynari.net>
References: <12428139.post@talk.nabble.com>
	<87d4x31vxc.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<12432859.post@talk.nabble.com>
	<87bqcazdur.wl%marcus.brinkmann@ruhr-uni-bochum.de>
	<46E572E8.9090809@bynari.net>
Message-ID: <87abruzcrh.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Mon, 10 Sep 2007 11:38:00 -0500,
Shawn Walker <swalker at bynari.net> wrote:
> 
> Marcus Brinkmann wrote:
> > At Fri, 31 Aug 2007 12:44:47 -0700 (PDT),
> > alan_b <gtbui at yahoo.com> wrote:
> >>
> >> So, in that callback function, what W32 function call should I use to write
> >> the password to the fd ?
> >> The original code is write( ), which did not compile in Windows.  I replaced
> >> it with _write( ), which gave the assertion error on the fd.
> > 
> > WriteFile
> > 
> > Marcus
> 
> Windows do support write(), you need to have the following inclues:

write() needs libc handles, while WriteFile uses windows handles,
which is what GPGME provides (and uses internally).

You can use write(), but then you have to convert the handles.  See
the MSDN documentation for details (_get_osfhandle, _open_osfhandle).

Marcus



From jari.aalto at cante.net  Mon Sep 10 17:51:04 2007
From: jari.aalto at cante.net (Jari Aalto)
Date: Mon, 10 Sep 2007 18:51:04 +0300
Subject: [PATCH] Add hostname to default env file
In-Reply-To: <871wd6x594.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Mon, 10 Sep 2007 11:02:31 +0200")
References: <20070909023755.GN19367@gambit>
	<871wd6x594.fsf@wheatstone.g10code.de>
Message-ID: <fy1mwmc7.fsf@blue.sea.net>

* Mon 2007-09-10 Werner Koch <wk AT gnupg.org> INBOX
> On Sun,  9 Sep 2007 04:37, eric AT debian.org said:
>
>> And I've written this patch to appease him. Let me know what you
>> think. 
>
> This breaks existing installations.  What about using 

Not many; and certianly not seriously.

1) The change si limited. It affects only installation that use 
   --write-env-file with no options.
2) Restat takes care of this.

Announcing changes in release notes can be used to notify upgrading
users.

>   gpg-agent --write-env-file ${HOME}/.gpg-agent-info-$(hostname) ...
>
> in the startup script?  

This was exactly the reason why bug was raised and Eric kindly submitted
a proposed. The current existing implementation was limited to a single
host only and the design did not foreseen other environments.

File with hostname (or FDQN) handles single host as well as NFS mounted
hosts.

> Eventually we might want to store the socket files at a fixed location
> like /tmp/gnupg-$USER/foo-socket instead of having them at a variable
> place. What does the file system standard says about this?

No directoried outside of $HOME can't be used for interoperability. The
/tmp is machine specific directory and won?t work on network mounted
disks.

PLease take a look at the picture again.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403833

Jari

-- 
Welcome to FOSS revolution: we fix and modify until it shines


From wk at gnupg.org  Mon Sep 10 18:46:14 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Sep 2007 18:46:14 +0200
Subject: [Announce] GnuPG 2.0.7 released
Message-ID: <87tzq2qxih.fsf@wheatstone.g10code.de>

Hello!
    
We are pleased to announce the availability of a new stable GnuPG-2
release:  Version 2.0.7

This is maintenance release with a few minor enhancements.

The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication
and data storage.  It can be used to encrypt data, create digital
signatures, help authenticating using Secure Shell and to provide a
framework for public key cryptography.  It includes an advanced key
management facility and is compliant with the OpenPGP and S/MIME
standards.

GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.6) in that
it splits up functionality into several modules.  However, both
versions may be installed alongside without any conflict.  In fact,
the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching.  The
advantage of GnuPG-1 is its smaller size and the lack of dependency on
other modules at run and build time.  We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support.

GnuPG is distributed under the terms of the GNU General Public License
(GPL version 3).  GnuPG-2 works best on GNU/Linux or *BSD systems.


What's New
===========

 * Fixed encryption problem if duplicate certificates are in the
   keybox.

 * Made it work on Windows Vista [1].  Note that the entire Windows port
   is still considered Beta.

 * Add new options min-passphrase-nonalpha, check-passphrase-pattern,
   enforce-passphrase-constraints and max-passphrase-days to
   gpg-agent.

 * Add command --check-components to gpgconf.  Gpgconf now uses the
   installed versions of the programs and does not anymore search via
   PATH for them.



Getting the Software
====================

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

GnuPG 2.0.7 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 http://www.gnupg.org/mirrors.html .  Note, that GnuPG
is not available at ftp.gnu.org.

On the FTP server and ist mirrors you should find the following files
in the gnupg/ directory:

  gnupg-2.0.7.tar.bz2 (3525k)
  gnupg-2.0.7.tar.bz2.sig

      GnuPG source compressed using BZIP2 and OpenPGP signature.

  gnupg-2.0.6-2.0.7.diff.bz2 (53k)

      A patch file to upgrade a 2.0.6 GnuPG source tree.  This patch
      does not include updates of the language files.

Note, that we don't distribute gzip compressed tarballs.  


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 trusted version of GnuPG installed, you
   can simply check the supplied signature.  For example to check the
   signature of the file gnupg-2.0.7.tar.bz2 you would use this command:

     gpg --verify gnupg-2.0.7.tar.bz2.sig

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by that signing key.  Make sure that you have the right key,
   either by checking the fingerprint of that key with other sources
   or by checking that the key has been signed by a trustworthy other
   key.  Note, that you can retrieve the signing key using the command

     finger wk ,at' g10code.com

   or using a keyserver like

     gpg --recv-key 1CE0C630

   The distribution key 1CE0C630 is signed by the well known key
   5B0358A2.  If you get an key expired message, you should retrieve a
   fresh copy as the expiration date might have been prolonged.

   NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE
   INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION!

 * If you are not able to use an old version of GnuPG, you have to verify
   the SHA-1 checksum.  Assuming you downloaded the file
   gnupg-2.0.7.tar.bz2, you would run the sha1sum command like this:

     sha1sum gnupg-2.0.7.tar.bz2

   and check that the output matches the first line from the
   following list:

f7d9ae7695bd9b849475b482bb7b027ec6fadbae  gnupg-2.0.7.tar.bz2
77ab84d4128dfc745f7e8d20b23a6842e84287fc  gnupg-2.0.6-2.0.7.diff.bz2


Internationalization
====================

GnuPG comes with support for 27 languages.  Due to a lot of new and
changed strings most translations are not entirely complete.  The
Swedish, Turkish, German and Russian translations close to be complete.


Documentation
=============

We are currently working on an installation guide to explain in more
detail how to configure the new features.  As of now the chapters on
gpg-agent and gpgsm include brief information on how to set up the
whole thing.  Please watch the GnuPG website for updates of the
documentation.  In the meantime you may search the GnuPG mailing list
archives or ask on the gnupg-users mailing lists for advise on how to
solve problems.  Many of the new features are around for several years
and thus enough public knowledge is already available.  KDE's KMail is
the most prominent user of GnuPG.  In fact it has been developed along
with the Kmail folks.  Mutt users might want to use the configure
option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make
use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP
support.

The manual is also available online in HTML format at
  http://www.gnupg.org/documentation/manuals/gnupg/ 
and in Portable Document Format at
  http://www.gnupg.org/documentation/manuals/gnupg.pdf .


Support
=======

Improving GnuPG is costly, but you can help!  We are looking for
organizations that find GnuPG useful and wish to contribute back.  You
can contribute by reporting bugs, improve the software, or by donating
money.

Commercial support contracts for GnuPG are available, and they help
finance continued maintenance.  g10 Code GmbH, a Duesseldorf based
company owned and headed by GnuPG's principal author, is currently
funding GnuPG development.  We are always looking for interesting
development projects.

The GnuPG service directory is available at:

  http://www.gnupg.org/service.html


Thanks
======

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word or answering questions on the mailing
lists.  


Happy Hacking,

  The GnuPG Team (David, Marcus, Werner and all other contributors)



[1] Although Vista is a good improvement on the quite bad Microsoft
Windows' security in the past, there are a lot of problems with
proprietary software and in particular with that new version.  Please
see http://badvista.fsf.org/.

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : /pipermail/attachments/20070910/889178d5/attachment-0001.pgp 
-------------- next part --------------
_______________________________________________
Gnupg-announce mailing list
Gnupg-announce at gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce

From wk at gnupg.org  Mon Sep 10 19:03:24 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 10 Sep 2007 19:03:24 +0200
Subject: [PATCH] Add hostname to default env file
In-Reply-To: <fy1mwmc7.fsf@blue.sea.net> (Jari Aalto's message of "Mon, 10 Sep
	2007 18:51:04 +0300")
References: <20070909023755.GN19367@gambit>
	<871wd6x594.fsf@wheatstone.g10code.de> <fy1mwmc7.fsf@blue.sea.net>
Message-ID: <87lkbeqwpv.fsf@wheatstone.g10code.de>

On Mon, 10 Sep 2007 17:51, jari.aalto at cante.net said:

>> This breaks existing installations.  What about using 
>
> Not many; and certianly not seriously.

You know all installations of gpg-agent?  I doubt that.

> 1) The change si limited. It affects only installation that use 
>    --write-env-file with no options.
> 2) Restat takes care of this.

No, it does not.  The scripts making use of ~/.gpg-agent-info need to be
modified as well.  You may do this for a stock Debian installation but
there are many more users of that code, so this is not an option.

> Announcing changes in release notes can be used to notify upgrading
> users.

Breaking an API is a bad idea; it should only be done if it is really
really required.  This is definitely not the case here.

>>   gpg-agent --write-env-file ${HOME}/.gpg-agent-info-$(hostname) ...
>>
>> in the startup script?  
>
> This was exactly the reason why bug was raised and Eric kindly submitted
> a proposed. The current existing implementation was limited to a single
> host only and the design did not foreseen other environments.

Please read the above example again - it has the identical effect as the
supplied patch.

> No directoried outside of $HOME can't be used for interoperability. The
> /tmp is machine specific directory and won?t work on network mounted
> disks.

Maybe the manual is not clear enough.  The environment variable, and
thus the .gpg-agent-info trick, is only used to convey information about
the local machine, i.e. the Unix domain socket used to connect to the
agent.  You can't use a socket name on an NFS mounted partition.

The long term plan is to get rid of this environment variable
(GPG_AGENT_INFO) and replace it with a well known name for the socket.
This name needs to be at a location which is specific to the local
system.  /tmp/gnupg-foo seems to be a good place and my question was
merely what disadvantages such an approach might have.  Note that many
programs use such socket file below /tmp, identified by application- and
username.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From swalker at bynari.net  Mon Sep 10 18:38:00 2007
From: swalker at bynari.net (Shawn Walker)
Date: Mon, 10 Sep 2007 11:38:00 -0500
Subject: GPGME callback function problem
In-Reply-To: <87bqcazdur.wl%marcus.brinkmann@ruhr-uni-bochum.de>
References: <12428139.post@talk.nabble.com>	<87d4x31vxc.wl%marcus.brinkmann@ruhr-uni-bochum.de>	<12432859.post@talk.nabble.com>
	<87bqcazdur.wl%marcus.brinkmann@ruhr-uni-bochum.de>
Message-ID: <46E572E8.9090809@bynari.net>

Marcus Brinkmann wrote:
> At Fri, 31 Aug 2007 12:44:47 -0700 (PDT),
> alan_b <gtbui at yahoo.com> wrote:
>>
>> So, in that callback function, what W32 function call should I use to write
>> the password to the fd ?
>> The original code is write( ), which did not compile in Windows.  I replaced
>> it with _write( ), which gave the assertion error on the fd.
> 
> WriteFile
> 
> Marcus

Windows do support write(), you need to have the following inclues:

#include <fcntl.h>      /* Needed only for _O_RDWR definition */
#include <io.h>
#include <stdlib.h>
#include <stdio.h>
#include <share.h>
"include <stdio.h>"

and link with one of the fullowing C run-time libraries (CRT).

libcmt.lib Multithreaded, static link
msvcrt.lib Multithreaded, dynamic link
libcmtd.lib Multithreaded, static link (debug)
msvcrtd.lib Multithreaded, dynamic link (debug)
msvcmrt.lib C Runtime import library.
msvcurt.lib C Runtime import library compiled as 100% pure MSIL code




From hira at atlas-is.co.jp  Tue Sep 11 02:24:24 2007
From: hira at atlas-is.co.jp (HIRA, Shuichi)
Date: Tue, 11 Sep 2007 09:24:24 +0900
Subject: GPGME callback function problem
In-Reply-To: <12432859.post@talk.nabble.com>
References: <12432859.post@talk.nabble.com>
Message-ID: <200709110024.AA01517@VELA.sun.atlas-is.co.jp>

Hi.

>The original code is write( ), which did not compile in Windows.  I replaced
>it with _write( ), which gave the assertion error on the fd.
I failed using _write(),(infinit loop?) so I replace it to _gpgme_io_write().
I think the reason is _gpgme_io_write() can handle CriticalSection in sema.h.

-- 
HIRA, Shuichi
Atlas Information Service Inc. 
IT Development Room
hira at atlas-is.co.jp



From wk at gnupg.org  Tue Sep 11 09:27:02 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 11 Sep 2007 09:27:02 +0200
Subject: GPGME callback function problem
In-Reply-To: <200709110024.AA01517@VELA.sun.atlas-is.co.jp> (Shuichi HIRA's
	message of "Tue, 11 Sep 2007 09:24:24 +0900")
References: <12432859.post@talk.nabble.com>
	<200709110024.AA01517@VELA.sun.atlas-is.co.jp>
Message-ID: <87hcm1oe61.fsf@wheatstone.g10code.de>

On Tue, 11 Sep 2007 02:24, hira at atlas-is.co.jp said:

> I failed using _write(),(infinit loop?) so I replace it to _gpgme_io_write().
> I think the reason is _gpgme_io_write() can handle CriticalSection in sema.h.

You may not use any function prefixed with "_gpgme"!  These are internal
functions and may change without notice.

Under Windows you need to use WriteFile and ReadFile and not write (or
_write which is identical to write).  Marcus already mentioned this.

Translation between the libc and system handles can be done with code
like this:

  /* This function is a NOP for POSIX systems but required under Windows
     as the file handles as returned by OS calls (like CreateFile) are
     different from the libc file descriptors (like open). This function
     translates system file handles to libc file handles.  FOR_WRITE
     gives the direction of the handle.  */
  int
  translate_sys2libc_fd (gnupg_fd_t fd, int for_write)
  {
  #ifdef HAVE_W32_SYSTEM
    int x;
  
    if (fd == GNUPG_INVALID_FD)
      return -1;
    
    /* Note that _open_osfhandle is currently defined to take and return
       a long.  */
    x = _open_osfhandle ((long)fd, for_write ? 1 : 0);
    if (x == -1)
      log_error ("failed to translate osfhandle %p\n", (void *) fd);
    return x;
  #else /*!HAVE_W32_SYSTEM */
    return fd;
  #endif
  }
  
  
If you are interested in the Windows API design, you should get Johnson
M. Hart's "Windows System Programming".  Actually this book a must have
for all Unix hackers who need to work for Windows.



Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From hira at atlas-is.co.jp  Tue Sep 11 10:22:23 2007
From: hira at atlas-is.co.jp (HIRA, Shuichi)
Date: Tue, 11 Sep 2007 17:22:23 +0900
Subject: GPGME callback function problem
In-Reply-To: <87hcm1oe61.fsf@wheatstone.g10code.de>
References: <87hcm1oe61.fsf@wheatstone.g10code.de>
Message-ID: <200709110822.AA01523@VELA.sun.atlas-is.co.jp>

Hi.

>> I failed using _write(),(infinit loop?) so I replace it to _gpgme_io_write().
>> I think the reason is _gpgme_io_write() can handle CriticalSection in sema.h.
>You may not use any function prefixed with "_gpgme"!  These are internal
>functions and may change without notice.
Mmm...
I think so, but using WriteFile causes loop too.

>  int
>  translate_sys2libc_fd (gnupg_fd_t fd, int for_write)
OK, succeed.
I built dll with function above by Borland BCC,
and called it from another dll by Delphi.

Thx.

-- 
HIRA, Shuichi
Atlas Information Service Inc. 
IT Development Room
hira at atlas-is.co.jp



From bernhard at intevation.de  Wed Sep 12 11:41:52 2007
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed, 12 Sep 2007 11:41:52 +0200
Subject: Getting rid of GPG_AGENT_INFO variable (was: [PATCH] Add hostname to
	default env file)
In-Reply-To: <87lkbeqwpv.fsf@wheatstone.g10code.de>
References: <20070909023755.GN19367@gambit> <fy1mwmc7.fsf@blue.sea.net>
	<87lkbeqwpv.fsf@wheatstone.g10code.de>
Message-ID: <200709121141.55954.bernhard@intevation.de>

On Monday 10 September 2007 19:03, Werner Koch wrote:
> The long term plan is to get rid of this environment variable
> (GPG_AGENT_INFO) and replace it with a well known name for the socket.
> This name needs to be at a location which is specific to the local
> system. ?/tmp/gnupg-foo seems to be a good place and my question was
> merely what disadvantages such an approach might have.

The variable is a good way to communicate to subprocesses.
Having several agents might be interesting for testing purposes
and the variable makes this easier. This should be considered,
but I guess who would make the precise location configurable anyway.

> Note that many programs use such socket file below /tmp, 
> identified by application- and username.

It might be easier to see for other user (but I did not check).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1571 bytes
Desc: not available
Url : /pipermail/attachments/20070912/196b1cb7/attachment.bin 

From simon at josefsson.org  Thu Sep 13 13:30:20 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 13 Sep 2007 13:30:20 +0200
Subject: Getting rid of GPG_AGENT_INFO variable
In-Reply-To: <200709121141.55954.bernhard@intevation.de> (Bernhard Reiter's
	message of "Wed, 12 Sep 2007 11:41:52 +0200")
References: <20070909023755.GN19367@gambit> <fy1mwmc7.fsf@blue.sea.net>
	<87lkbeqwpv.fsf@wheatstone.g10code.de>
	<200709121141.55954.bernhard@intevation.de>
Message-ID: <87ir6e950z.fsf@mocca.josefsson.org>

Bernhard Reiter <bernhard at intevation.de> writes:

> On Monday 10 September 2007 19:03, Werner Koch wrote:
>> The long term plan is to get rid of this environment variable
>> (GPG_AGENT_INFO) and replace it with a well known name for the socket.
>> This name needs to be at a location which is specific to the local
>> system. ?/tmp/gnupg-foo seems to be a good place and my question was
>> merely what disadvantages such an approach might have.
>
> The variable is a good way to communicate to subprocesses.
> Having several agents might be interesting for testing purposes
> and the variable makes this easier. This should be considered,
> but I guess who would make the precise location configurable anyway.

How about a compromise between the two positions, and make the
GPG_AGENT_INFO variable optional: if the variable is not set, the
default is to use /tmp/gnupg-<user> or something.

Although perhaps a directory is more flexible, thus for example
/tmp/gnupg-<user>/agent-socket.

/Simon


From wk at gnupg.org  Thu Sep 13 21:40:07 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Sep 2007 21:40:07 +0200
Subject: Getting rid of GPG_AGENT_INFO variable
In-Reply-To: <87ir6e950z.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 13 Sep 2007 13:30:20 +0200")
References: <20070909023755.GN19367@gambit> <fy1mwmc7.fsf@blue.sea.net>
	<87lkbeqwpv.fsf@wheatstone.g10code.de>
	<200709121141.55954.bernhard@intevation.de>
	<87ir6e950z.fsf@mocca.josefsson.org>
Message-ID: <87myvq1hig.fsf@wheatstone.g10code.de>

On Thu, 13 Sep 2007 13:30, simon at josefsson.org said:

> How about a compromise between the two positions, and make the
> GPG_AGENT_INFO variable optional: if the variable is not set, the
> default is to use /tmp/gnupg-<user> or something.

Yes this is a good migration path.

> Although perhaps a directory is more flexible, thus for example
> /tmp/gnupg-<user>/agent-socket.

Sure, we need a directory for setting proper permissions.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From gtbui at yahoo.com  Thu Sep 20 16:41:24 2007
From: gtbui at yahoo.com (alan_b)
Date: Thu, 20 Sep 2007 07:41:24 -0700 (PDT)
Subject: GPGME support for PGP2 option?
Message-ID: <12798612.post@talk.nabble.com>


GPG command line has the --pgp2 option to provide compatibilty with PGP 2.x.
When I use GPGME API, is there a flag for that PGP2 option?

Thanks in advance.
-- 
View this message in context: http://www.nabble.com/GPGME-support-for-PGP2-option--tf4487972.html#a12798612
Sent from the GnuPG - Dev mailing list archive at Nabble.com.



From gtbui at yahoo.com  Fri Sep 28 20:00:28 2007
From: gtbui at yahoo.com (alan_b)
Date: Fri, 28 Sep 2007 11:00:28 -0700 (PDT)
Subject: GPGME support for PGP2 option?
In-Reply-To: <12798612.post@talk.nabble.com>
References: <12798612.post@talk.nabble.com>
Message-ID: <12945575.post@talk.nabble.com>


I would like to explain my question more clearly.

I have GPG 1.4.7, and I installed the extension module that support IDEA key
for PGP 2.6.x compatibility.
When I receive an encrypted message from PGP 2.6, the GPG can decrypt it
correctly.
When I use GPG command line to create a message to send to PGP 2.6 users, I
can use the option --pgp2 to encrypt a message that PGP can decrypt.

However, if I write a program using GPGME API and want to encrypt a message
to send to PGP 2.6, what is the parameter that is equivalent to the --pgp2
option ?



alan_b wrote:
> 
> GPG command line has the --pgp2 option to provide compatibilty with PGP
> 2.x.
> When I use GPGME API, is there a flag for that PGP2 option?
> 
> Thanks in advance.
> 

-- 
View this message in context: http://www.nabble.com/GPGME-support-for-PGP2-option--tf4487972.html#a12945575
Sent from the GnuPG - Dev mailing list archive at Nabble.com.



From marcus.brinkmann at ruhr-uni-bochum.de  Sat Sep 29 11:22:08 2007
From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann)
Date: Sat, 29 Sep 2007 11:22:08 +0200
Subject: GPGME support for PGP2 option?
In-Reply-To: <12945575.post@talk.nabble.com>
References: <12798612.post@talk.nabble.com>
	<12945575.post@talk.nabble.com>
Message-ID: <87ejghomgv.wl%marcus.brinkmann@ruhr-uni-bochum.de>

At Fri, 28 Sep 2007 11:00:28 -0700 (PDT),
alan_b <gtbui at yahoo.com> wrote:
> I would like to explain my question more clearly.
> 
> I have GPG 1.4.7, and I installed the extension module that support IDEA key
> for PGP 2.6.x compatibility.
> When I receive an encrypted message from PGP 2.6, the GPG can decrypt it
> correctly.
> When I use GPG command line to create a message to send to PGP 2.6 users, I
> can use the option --pgp2 to encrypt a message that PGP can decrypt.
> 
> However, if I write a program using GPGME API and want to encrypt a message
> to send to PGP 2.6, what is the parameter that is equivalent to the --pgp2
> option ?

GPGME does not support this option.

Thanks,
Marcus