D118: 272_gpg.texi.patch

Implemented for dirmngr. That will go into dirmngr 1.1.0.

This patch fixes it for me. The problem is the order in that the home directory
is created. Usually it is done while creating a new keyring. Due to
--no-default-keyring no keyring is created and thus when we need to check the
trust the code there creates the directory and failed. I am not sure why I was
not able to replicate it yesterday.

• g10/tdbio.c (revision 5221)

+++ g10/tdbio.c (working copy)
@@ -521,7 +521,8 @@

*p = 0;
if( access( fname, F_OK ) ) {
    try_make_homedir( fname );

• log_fatal( _("%s: directory does not exist!\n"), fname );

+ if (access (fname, F_OK ))
+ log_fatal (_("%s: directory does not exist!\n"), fname);

}
*p = save_slash;

I don't understand the code either. I introduced it 10 years ago on Dec 4 when
I consolidated the make home directory logic. Obviously that code path was
never tested. The previous code called log_fatal only if the home directory
name did not end in ".gnupg". A simple fix would be to add another access test
after try_make_homedir.

And the difference is made by the --no-default-keyring switch. Removing it from
the command makes it work too.

In g10/tdbio.c the code is:

It is reproducible here. But the result depends. First what you asked for:

Tested with gpg 1.4.8 and the current SVN versions of 1.4.x and 2.1.x.
All yield the same output.

Sorry, I can't replicate this:

Sorry, we can't do anything about it. This is pureley an Outlook problem.
GpgOL does not know anything about IMAP; all what we do is to use the MAPI
interface.

Sorry, you already fixed this. Closing myself.

will be in 1.4.5 to be released in a few minutes.

According to the wrieshark tracker, this has been solved.
Fix will be in 1.4.5.

I assume you mean GnuPG 2.0.12. That version is no longer current. Please test
with the 2.0.13. I recall that we had a similar report on the mailing list
which was more detailed.

Applied (rev 1024). Thanks.

Okay, for the development version I implemented a configure option
--disable-O-flag-munging
This is in the SVN trunk, rev 1415.
I believe that is the least intrusive change. Is it important for you; thus
shall I backport it to 1.4.5 which will be released in a few days?

Sorry, this is not a help line.
Ask on the gcrypt-devel ML or get commercial support.

A bit more of context is required. OS, CPU, libc version, etc.

I have implemented the mentioned checks for CTR in libgcrypt trunk, rev 1414.

D117: 269_diff

Please find a minor patch attached. It fixes the formatting of the headline
(command should be all-uppercase). It further introduces a few formatting
requests (e.g. don't hyphenate the filename or the reference to gtk-options.

Commited to 2.0 and trunk, rev. 5224.
Now for dirmngr.

Okay, I implemented that for gpgsm:

That is a hard to fix problem. We don't have the infrastructure to merge
keyserver requests. Adding this to gpg will be quite some work. A tentative
plan to implement this would require a local daemon to cache requests (e.g.
enhancing dirmngr) and to rework gpg to allow for asynchronous updates.

As suggested I have excluded the ID 17 on W2000 systems. I never had this
problem on my W2000 system, so I can't test whether this is sufficient. Please
try the test dll at:

Dear Mr. Koch,

From my investigation the only workaround seems to be the no-honor-keyserver-url
option. What I could imagine is, to test, if the given keyserver pref of a key
is equal to the specified preferred keyserver and delay this key processing and
process it with all other keys without keyserver prefs. However this won't solve
the problem completely, as all other keys would still be processed one after the
other (which BTW sounds reasonable to me).

Thanks. Commited to the SVN -r 1023.

After talking to Arthur, the author of the manual page, the manual page is
provided under the GNU General Public license version 2 or (at your option) any
later version.

Well, it will be some work to parse the description of policyConstraints and
policyMappings and see who it fits into the GnuPG system.

I don't think this is a proper solution. --default-key has the same problem as
--local-user. What we can do is to fail if a key has been specified in a
non-unique way. Selecting one by chance is a Bad Thing.

These bug reports are sometimes mixing two different issues: The
debian-keyring and r/o keyrings for other purposes.

Thanks. Commited to branches/STABLE-BRANCH-2-0/.

Requested information has been sent by e-mail.

That is a funny bug. Well not really funny but hard to believe if you don't
consider some of the patches we apply in gpg4win. In gpg4win 2.0.1 is a patch
which adds 2 addtional status code macros. The patch obviously patches the
sources (common/status.h). The patch then triggers a make rule to rebuild
status-codes.h from status.h. Due to the vpath build and a bug in the makefile
we end up with two status-codes.h files. This explains why we have two ideas of
the STATUS_ATTRIBUTE macro's value, which are off by 2.

yes, it's the official binary release from ftp.gpg4win.org.

PLease do a gpg --version which gives teh exact version number of the binary you
are actually using. Is that the gpg4win downloaded from ftp.gpg4win.org?

Forget my previous comment. All checks should be there. Can you please send me
your config.log file by PM (wk at gnupg.org)?

estream-printf has been taken from gnupg 2.0 which includes the required macros
due to a side effect of using otehr gnulib functions. I missed to add the
required tests.

That's gpg2 2.0.12, installed as part of gpg4win 2.0.1 (binary version installed).

Aihhh. The failure mode depends on the malloc implementation. We are only
shrinking memory and thus some implementations simply return the same pointer.
Obviously not in BSD.