Re: gpg-agent PIN cache

[Werner Koch]

On Wed, 5 Oct 2005 20:10:22 +0200, Joerg Schmitz-Linneweber said:

> But the problem is: The second time and ever on, pinentry comes up and asks 
> for my PIN! Although I said "cache ttl for ssh should be some hours..."

> Does anyone know why gpg-agent/pinentry does so?

Yes.  We do a reset after each connection which requires entering a
new PIN.  That reset is actually not required however there is a some
other problem where the reset helps.  I really really need to look at
this.


Salam-Shalom,

   Werner


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

[Announce] GPGME 1.1.0 released

[Marcus Brinkmann]

We are pleased to announce version 1.0.1 of GnuPG Made Easy,
a library designed to make access to GnuPG easier for applications.
It may be found in the file (about 818 KB/630 KB compressed)
ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.0.tar.gz
ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.0.tar.bz2

The following files are also available:
ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.0.tar.gz.sig
ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.1.0.tar.bz2.sig
ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.0.3-1.1.0.diff.gz

It should soon appear on the mirrors listed at:
http://www.gnupg.org/mirrors.html

Bug reports and requests for assistance should be sent to:
[EMAIL PROTECTED]

The sha1sum checksums for this distibution are
2b4f6a8eb4bbc3bc8ad049840c8cbe695ad379f9  gpgme-1.1.0.tar.gz
be6a3ed597e21245f9132364ab5f7e6039069988  gpgme-1.1.0.tar.bz2
bdbeb96ba64c8c358c0885532b083659339b1258  gpgme-1.1.0.tar.gz.sig
9e074b64aa1755ae9e9dc4d4a2fd8da637711cc0  gpgme-1.1.0.tar.bz2.sig
d3b04ab5708d86156f586b8fc34d0958b367e552  gpgme-1.0.3-1.1.0.diff.gz


Noteworthy changes in version 1.1.0 (2005-10-01)


 * You can now configure the backend engine file name and home
   directory to be used, as default and per context.

 * Information about the recipients of an encrypted text is now
   available at decryption time.

 * New status GPGME_STATUS_PLAINTEXT.  This is analyzed by the decrypt
   and verify handlers, the information about the plaintext filename,
   if available is made available in the new field file_name of the
   respective result structure.

 * The code for "automagically detecting the thread library" has been
   removed from libgpgme.  It is deprecated since version 0.4.3.
   Since then, you had to link against libgpgme-pthread for
   applications using pthread and libgpgme-pth for applications using
   GNU Pth.

   The code was removed because it caused compilation problems on
   systems where the pthread.h header from GNU Pth is available in
   addition to the system header (FreeBSD 6 and later for example).

 * "./autogen.sh --build-w32" does now build gpgme.dll.

 * [W32] The environment variable GPGME_DEBUG now uses a semicolon as
   delimiter.  The standard install directory is used when locating
   gpg or gpgsm before finally falling back to the hardwired name.

 * There is a new flag for keys and subkeys, is_qualified, which
   indicates if a key can be used for qualified signatures according
   to local government regulations.

 * You can associate a filename with a data object using the new
   function gpgme_data_set_file_name().  This filename will be stored
   in the output when encrypting or signing the data and will be
   returned when decrypting or verifying the output data.

 * You can now set notation data at signature creation with the new
   function gpgme_sig_notation_add().

 * Interface changes relative to the 1.0.3 release:
~~
gpgme_set_engine_info   NEW
gpgme_ctx_get_engine_info   NEW
gpgme_ctx_set_engine_info   NEW
gpgme_recipient_t   NEW
gpgme_decrypt_result_t  EXTENDED: New field recipients.
gpgme_verify_result_t   EXTENDED: New fields pubkey_algo, hash_algo.
gpgme_decrypt_result_t  EXTENDED: New field plaintext_filename.
gpgme_verify_result_t   EXTENDED: New field plaintext_filename.
GPGME_STATUS_PLAINTEXT  NEW
gpgme_key_t EXTENDED: New field is_qualified.
gpgme_subkey_t  EXTENDED: New field is_qualified.
gpgme_data_get_file_nameNEW
gpgme_data_set_file_nameNEW
gpgme_sig_notation_flags_t  NEW
GPGME_SIG_NOTATION_HUMAN_READABLE NEW
GPGME_SIG_NOTATAION_CRITICALNEW
gpgme_sig_notation_clearNEW
gpgme_sig_notation_add  NEW
gpgme_sig_notation_get  NEW
~~


Marcus Brinkmann
[EMAIL PROTECTED]


___
Gnupg-announce mailing list
[EMAIL PROTECTED]
http://lists.gnupg.org/mailman/listinfo/gnupg-announce


___
Gnupg-devel mailing list
[EMAIL PROTECTED]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel



___
Gnupg-announce mailing list
[EMAIL PROTECTED]
http://lists.gnupg.org/mailman/listinfo/gnupg-announce


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

RFC - CVS Signed Commit & Replay Attacks

[Derek Price]

Hi all,

I mentioned on this list a few days ago that I am implementing
gpg-signed-commits for CVS.  This is somewhat of a new area for me, and
I was hoping to trust GPG to solve most of the security issues, but it
turns out this doesn't cover the possibility of replay attacks.  We've
been discussing this for a few days on bug-cvs@nongnu.org, but it feels
somewhat like we are stumbling around in the dark and I was hoping for
some comments from people more familiar with this sort of thing.  The
current end of the thread is here:
. 
Probably not more than two messages back in that thread are particularly
relevant, unless you want to laugh at our ignorance.

For background, the gpg-signed-commits design is Wikied here:
.  If
you would care to comment on any other shortcomings in this design, that
would be welcome too.

Thanks,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot 
v: +1 717.579.6168
f: +1 717.234.3125




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

Re: gpgme-1.1.0: make check: FAIL: t-sig-notation

[Marcus Brinkmann]

At Thu, 06 Oct 2005 20:29:04 +,
"William M. Perkins" <[EMAIL PROTECTED]> wrote:
>  GnuPG version: 1.4.2, min. 1.2.2

Ah, ok.  I only tested it with GnuPG 1.4.1, which worked fine.

> The failure happened at:
>  t-sig-notation.c:108: Missing or duplicate notation data
>  FAIL: t-sig-notation

GnuPG 1.4.2 has a stricter check for critical notation data.  Sigh.
The below patch is now in CVS Head, and will be part of 1.1.1.  If you
want, give it a try.  Otherwise just ignore the broken test, it has no
effect on how GPGME works.

2005-10-07  Marcus Brinkmann  <[EMAIL PROTECTED]>

* gpg/t-sig-notation.c: Change critical notation to something
GnuPG understands.

diff -ru gpgme/tests/gpg/t-sig-notation.c gpgme/tests/gpg/t-sig-notation.c
--- gpgme/tests/gpg/t-sig-notation.c2005-10-01 04:06:08.0 +0200
+++ gpgme/tests/gpg/t-sig-notation.c2005-10-07 01:00:02.0 +0200
@@ -42,8 +42,8 @@
   { "[EMAIL PROTECTED]",
 "Just Squeeze Me",
 GPGME_SIG_NOTATION_HUMAN_READABLE },
-  { "[EMAIL PROTECTED]",
-"Right Now",
+  { "[EMAIL PROTECTED]",
+"pgpmime",
 GPGME_SIG_NOTATION_HUMAN_READABLE | GPGME_SIG_NOTATION_CRITICAL },
   { NULL, 
 "http://www.gnu.org/policy/";,

Thanks,
Marcus


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

partition encryption?

[nidhog]

Hi,

Do you guys have any suggestion as to how to go about encrypting a
partition that can be available both to linux and win32?

Thanks.

--
/nh

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