Sorry. Version used was reported in the original report at:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1342807
but i didn't copy that here. I ran this on 14.10 Ubuntu with apt provided gpg.
version is: 1.4.16-1.2ubuntu1

GnuPG version you used for the test?

I won't call that leaking memory.

With your fix it no longer crashes. But you are leaking memory in case
default_homedir returns allocated memory from read_w32_registry_string or
standard_homedir with a successful call to w32_shgetfolderpath.

As the result should be cached in the static variable this is probably not an
issue..

I just pushed a fix.

The problem with gpgme is that we need to stop the Explorer if we want to update
or uninstall gpgme. Given tha we can't use gpgex with the portable version
anyway, I think it is better to keep the existing code and don't switch to gpgme.

What is the best way to switch the console to utf mode?
Should someone use the chcp command and how?

Anyway the default behaviour is surprising for users, so from my point of view,
it should be improved somehow. A good documentation how to switch would only
be a second grade solution. A better one would be if the .exes would switch the
code page themselfs, I assume.

Using gpgme would be nice of course to avoid duplicated functionality (this same
stuff is also implemented in gpgol although without the bug) but remember that
we would then also need a x64 version of gpgme.

The bug is pretty obvious. I consider to rewrite it by calling gpgconf
--list-dirs to get the home directory. This would be simliar to what we do in
gpgme. Or well, we could link to to gpgme to and make use of its higher level
interface.

No, the patch is a hack which works just for you and not for other environments.

As I already explained a proper solution will be quite complicated and it won't
be the Unix way.

I like to help with the proposed 2.1 solution. However, the fastest thing to do
is to change the system to sign a manifest file. That is more flexible and
makes it easier to add additional signatures.

Switch the console to utf-8 and things will work. There is no explict support
for this.

Thanks for looking at this. If you like I could test your fixes. I currently
have a build setup and a test setup where I can reproduce the crash.

Btw. Maybe I don't understand c++ enough but afaik this just makes no sense and
is broken:

  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}

should be rather something like:
if (dir)
name = string(dir) + "\\S.uiserver";

Any progress on this? Thank you.

I have some fixes sitting here in my local repo. I need to check them.

issue1530 and T1536 also describe this bug.
I've closed the other two as duplicates as this one was the first.

Closing this as a duplicate of T1516

Duplicate of T1516

This is a duplicate of T1516

Duplicate of T1516

Hi Werner,

I've reproduced this crash. Last trace before the crash is uiserver_connect.

I believe the crash (without having a backtrace) to be caused by the free in
default_socket_name or by that weird cast.

dir = default_homedir ();
if (dir)

{

	  try { name = ((string) dir) + "\\S.uiserver"; } catch (...) {}
	  free ((void *) dir);

}

    }

default_homedir can return a pointer to an environment variable or a static
string! So just calling free there is definitely a very bad idea.

standard_homedir (which might also be called from default_homedir) also returns
eiher a Heap allocated value or a static string.

I think we should ensure that default_homedir and standard_homedir always return
allocated memory so that it can be safely freed.

Well, on FreeBSD 10 "uname -p" works the same as "uname -m". It is not POSIX
though.

WTF happened to config.guess? Upstream's ChangeLog has these entries:

2011-08-20 Ben Elliston <bje@gnu.org>

• config.guess (*:FreeBSD:*:*): Switch on ${UNAME_PROCESSOR}.
• testsuite/config-guess.data: Remove hard to test FreeBSD cases.

2006-04-26 Bruno Haible <bruno@clisp.org>

	    Ben Elliston  <bje@gnu.org>

• config.guess (amd64:FreeBSD:*:*) Detect as x86_64.
• testsuite/config-guess.data: Add test case.

Thus in 2006 support form and64 was added and in 2011 the faulty
"uname -p" was implemented and test cases removed. I assume that
everyone patched similar to what you suggested. However, the correct
thing is to fix config.guess.

Unfortunately I do not have access to any FreeBSD box right now (the
FreeBSD in the gcc compile farm is offline). Can you do some tests on
several FreeBSD boxes or give me access to a test box?

What are the patches to configure I see in the build log? And why are
the M4 files are patched - they are not used after configure has been
created? I would also like to see the config.rpath to see how it has been
changed.

Feel free to continue by private mail.

No, FreeBSD has amd64 as uname -m value.

That should not be required. Did you explicitly specify host with
configure?

config.guess has this code:

*:FreeBSD:*:*)

UNAME_PROCESSOR=/usr/bin/uname -p
case ${UNAME_PROCESSOR} in

	    amd64)
		echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;

to map "amd64" to "x86_64" and config.sub called with "amd64" also
returns the canonical "x86_64". Thus everything should be fine.

(I think "amd64" would have been the better and easier to type name,
but the GCC developers settled for "x86_64").

I think my problem is like this issue

T1407

The error is not yet resolved.

Iam sorry because i didn't have access to the machine AIX, so here it is the
full debug informations of the error that i faced.

(gdb) bt
#0 0xd71c0a30 in int_vasprintf () from
/opt/freeware/lib/libassuan.a(libassuan.so.0)
#1 0xd71c09d8 in _assuan_vasprintf ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

#2 0xd71c0868 in _assuan_debug () from
/opt/freeware/lib/libassuan.a(libassuan.so.0)
#3 0xd71bf5b0 in assuan_new_ext ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

#4 0x1002e2f8 in start_new_gpg_agent (r_ctx=0x30007a5c <_callagent.bss_>,

errsource=GPG_ERR_SOURCE_GPG, homedir=0x100f2e90 <__dbsubn+23068> "~/.gnupg",
agent_program=0x0, opt_lc_ctype=0x0, opt_lc_messages=0x0,
session_env=0x3000aa38, verbose=0, debug=0, status_cb=0x0, status_cb_arg=0x0)
at asshelp.c:268

#5 0x10011280 in start_agent (for_card=0) at call-agent.c:126
#6 0x100153b4 in agent_get_s2k_count (r_count=0x2ff21bb4) at call-agent.c:1351
#7 0x10083f98 in encode_s2k_iterations (iterations=0) at passphrase.c:70
#8 0x100853e8 in passphrase_to_dek_ext (keyid=0x0, pubkey_algo=0, cipher_algo=3,

s2k=0xb0000558, mode=2, tryagain_text=0x0, custdesc=0x0, custprompt=0x0,
canceled=0x2ff21dc0) at passphrase.c:535

#9 0x100c1ca0 in do_ask_passphrase (ret_s2k=0x2ff21d88, mode=0,

r_canceled=0x2ff21dc0) at keygen.c:2280

#10 0x100c485c in generate_keypair (fname=0x0, card_serialno=0x0,

backup_encryption_dir=0x0) at keygen.c:3217

#11 0x10009058 in main (argc=0, argv=0x2ff220d8) at gpg.c:3699
(gdb) frame 0
#0 0xd71c0a30 in int_vasprintf () from
/opt/freeware/lib/libassuan.a(libassuan.so.0)
(gdb) list
1871 return configname;
1872 }
1873
1874
1875 int
1876 main (int argc, char **argv)
1877 {
1878 ARGPARSE_ARGS pargs;
1879 IOBUF a;
1880 int rc=0;

(gdb) frame 1
#1 0xd71c09d8 in _assuan_vasprintf ()

from /opt/freeware/lib/libassuan.a(libassuan.so.0)

(gdb) list
1881 int orig_argc;
1882 char **orig_argv;
1883 const char *fname;
1884 char *username;
1885 int may_coredump;
1886 strlist_t sl, remusr= NULL, locusr=NULL;
1887 strlist_t nrings=NULL, sec_nrings=NULL;
1888 armor_filter_context_t *afx = NULL;
1889 int detached_sig = 0;
1890 FILE *configfp = NULL;

(gdb) frame 2
#2 0xd71c0868 in _assuan_debug () from
/opt/freeware/lib/libassuan.a(libassuan.so.0)
(gdb) list
1891 char *configname = NULL;
1892 char *save_configname = NULL;
1893 char *default_configname = NULL;
1894 unsigned configlineno;
1895 int parse_debug = 0;
1896 int default_config = 1;
1897 int default_keyring = 1;
1898 int greeting = 0;
1899 int nogreeting = 0;
1900 char *logfile = NULL;

(gdb) list
1901 int use_random_seed = 1;
1902 enum cmd_and_opt_values cmd = 0;
1903 const char *debug_level = NULL;
1904 const char *trustdb_name = NULL;
1905 char *def_cipher_string = NULL;
1906 char *def_digest_string = NULL;
1907 char *compress_algo_string = NULL;
1908 char *cert_digest_string = NULL;
1909 char *s2k_cipher_string = NULL;
1910 char *s2k_digest_string = NULL;

(gdb) frame 4
#4 0x1002e2f8 in start_new_gpg_agent (r_ctx=0x30007a5c <_callagent.bss_>,

errsource=GPG_ERR_SOURCE_GPG, homedir=0x100f2e90 <__dbsubn+23068> "~/.gnupg",
agent_program=0x0, opt_lc_ctype=0x0, opt_lc_messages=0x0,
session_env=0x3000aa38, verbose=0, debug=0, status_cb=0x0, status_cb_arg=0x0)
at asshelp.c:268

268 in asshelp.c
(gdb) list
263 in asshelp.c
(gdb) info locals
err = 0
infostr = 0xb0000508
"\aöº²Ã\230\006=Ì:²Ä4\001=ZF\202gþëLÚñªN\"é»Ãѯ\n\230Ù>/Î\223#l\025\235Ì
lÙz4v0g,\a\025¤dT°¸\227%à`"
p = 0xb00004f4 ""
ctx = 0x0
sockname = 0x0
argv = {0x0, 0x0, 0x0}
pid = 0
excode = 0

(gdb) frame 5
#5 0x10011280 in start_agent (for_card=0) at call-agent.c:126
126 rc = start_new_gpg_agent (&agent_ctx,
(gdb) list
121 to the agent. */
122 if (agent_ctx)
123 rc = 0;
124 else
125 {
126 rc = start_new_gpg_agent (&agent_ctx,
127 GPG_ERR_SOURCE_DEFAULT,
128 opt.homedir,
129 opt.agent_program,
130 opt.lc_ctype, opt.lc_messages,
(gdb) info locals
rc = -971823094
info = {error = 547959831,

  apptype = 0x8ae2be5a <error: Cannot access memory at address 0x8ae2be5a>,
  serialno = 0x4bd8d52f <error: Cannot access memory at address 0x4bd8d52f>,
  disp_name = 0x669992ce <error: Cannot access memory at address 0x669992ce>,
  disp_lang = 0x53cbeb7b <error: Cannot access memory at address 0x53cbeb7b>,
  disp_sex = 0,
  pubkey_url = 0x53cbeb7b <error: Cannot access memory at address 0x53cbeb7b>,
  login_data = 0x3af86 "\aä`\177", private_do = {
    0x2ff21a50 "/ò\032à$\210\202$×\006¢ÄñQà\230/ò\032 ñQÛü×\006\230¸", 0x0, 0x0,
    0x0}, cafpr1valid = 47 '/', cafpr2valid = -14 'ò', cafpr3valid = 26 '\032',
  cafpr1 = "P", '\000' <repeats 16 times>, "ðBü",
  cafpr2 = "xñP·\214\000\000\000\000ñPµ¼ñP¶<\000\000",
  cafpr3 = "\000\000\000\000\001ñQà\230\000\000\000\bñPµX°\000\005",
  fpr1valid = 93 ']', fpr2valid = 47 '/', fpr3valid = -14 'ò',
  fpr1 = "\032à$\210\202$×\006¢ÄñQà\230/ò\032 ñQ",
  fpr2 = "Ûü×\006\230¸\000\000\000\000\060\000¶ÈðBüx\000",
  fpr3 = "\000\006\000\000\000\000/ò\032Ð\000\000\000 \000\000\000\000\000",
  fpr1time = 876758, fpr2time = 4030921848, fpr3time = 0, sig_counter = 2952791397,
  chv1_cached = 804395744, is_v2 = -559038737, chvmaxlen = {-687433544, -264047608,
    -559038737}, chvretry = {-559038737, -559038737, -559038737}, key_attr = {{
      algo = -559038737, nbits = 3735928559}, {algo = -559038737, nbits = 138}, {
      algo = 1, nbits = 8}}, extcap = {ki = 0, aac = 0}}

#6 0x100153b4 in agent_get_s2k_count (r_count=0x2ff21bb4) at call-agent.c:1351
1351 err = start_agent (0);
(gdb) list
1346 membuf_t data;
1347 char *buf;
1348
1349 *r_count = 0;
1350
1351 err = start_agent (0);
1352 if (err)
1353 return err;
1354
1355 init_membuf (&data, 32);
(gdb) info locals
err = 3607370940
data = {len = 804395904, size = 2139062143,

buf = 0xd703e1dc <_gcry_global_is_operational+56> "`", out_of_core = 1852138852}

buf = 0x2ff21bd0 "/ò\034À"

(gdb) frame 7
#7 0x10083f98 in encode_s2k_iterations (iterations=0) at passphrase.c:70
70 err = agent_get_s2k_count (&mycnt);
(gdb) list
65 if (!iterations)
66 {
67 unsigned long mycnt;
68
69 /* Ask the gpg-agent for a useful iteration count. */
70 err = agent_get_s2k_count (&mycnt);
71 if (err || mycnt < 65536)
72 {
73 /* Don't print an error if an older agent is used. */
74 if (err && gpg_err_code (err) != GPG_ERR_ASS_PARAMETER)
(gdb) info locals
err = 3735928559
c = 0 '\000'
result = 173 '­'
count = 4030919688
mycnt = 0

(gdb) frame 8
#8 0x100853e8 in passphrase_to_dek_ext (keyid=0x0, pubkey_algo=0, cipher_algo=3,

s2k=0xb0000558, mode=2, tryagain_text=0x0, custdesc=0x0, custprompt=0x0,
canceled=0x2ff21dc0) at passphrase.c:535

535 opt.s2k_count = encode_s2k_iterations (0);
(gdb) list
530 /* We delay the encoding until it is really needed. This is
531 if we are going to dynamically calibrate it, we need to
532 call out to gpg-agent and that should not be done during
533 option processing in main(). */
534 if (!opt.s2k_count)
535 opt.s2k_count = encode_s2k_iterations (0);
536 s2k->count = opt.s2k_count;
537 }
538 }
539
(gdb) info locals
pw = 0x0
dek = 0xd703e514 <_gcry_xmalloc_secure+24>
help_s2k = {mode = 5, hash_algo = 47 '/', salt = "ò\034p0\000\071ô",

count = 804396096}

dummy_canceled = 804396160
s2k_cacheidbuf = "\020\020\036t/ò\034Ü\000\000\000\000/ò\034 \000"
s2k_cacheid = 0x0
buf =
"/ò\034À\000\000\000\024\020\001~\000/ò\034p/ò\034Ð\020\016í\220\020\016í\234/ò\034À/ò\034À\000\000\000\020×\003\204
\000\000\000\000\000"

(gdb) frame 9
#9 0x100c1ca0 in do_ask_passphrase (ret_s2k=0x2ff21d88, mode=0,

r_canceled=0x2ff21dc0) at keygen.c:2280

2280 dek = passphrase_to_dek_ext (NULL, 0, opt.s2k_cipher_algo, s2k, 2,
(gdb) list
2275
2276 s2k = xmalloc_secure( sizeof *s2k );
2277 for(;;) {
2278 s2k->mode = opt.s2k_mode;
2279 s2k->hash_algo = S2K_DIGEST_ALGO;
2280 dek = passphrase_to_dek_ext (NULL, 0, opt.s2k_cipher_algo, s2k, 2,
2281 errtext, custdesc, NULL, r_canceled);
2282 if (!dek && *r_canceled) {
2283 xfree(dek); dek = NULL;
2284 xfree(s2k); s2k = NULL;
(gdb) info locals
dek = 0x0
s2k = 0xb0000558
errtext = 0x0
custdesc = 0x0

GnuPG-2x always uses Unix domain sockets or its emulation under Windows. There
is no way around it.

Sorry, I don't know what a Basket Note Pad is. Please report there first.

Or let me know if it is no more possible then I will stick with 2.0.* versions

D204: 442_keyserver_keyids.patch

D202: 441_patch-gnupg-common_mischelp.h-include-guard.diff

Also apply this cherry-picked commit against master, please.

D203: 440_patch-gnupg-jnlib_mischelp.h-include-guard.diff

Thanks for your ideas. Nonetheless, this patch is used by OBS project for years
in production so we would like to use this solution we know works fine rather
then creating something else. If you would like to see more how it works
internally, look at sign.c[0] and sign daemon[1].

Can we please get to some resolution? Please tell me whether:
1, you will accept such a patch
2, you would accept with changes
3, you don't want anything alike in gnupg for the moment

For the maintainer of gnupg in Fedora is important that we don't include
something that you would include as well, but differently. Thank you!

[0]https://github.com/openSUSE/obs-sign/blob/master/signc
[1]https://github.com/openSUSE/obs-sign/blob/master/signd

D201: 439_patch-configure.diff

By patching configure it's possible to connect the cipher/*-amd64.S to the build.

See attached.

You should have said this directly ;-) IIRC, we have a similar request
in the bug tracker. The problem here is that you need to save the
internal state of the hash computation, then restore the hash on the
server and continue the hashing, and finally return the state of the
hashing to the signing box which will then finalize it. There are all
kind of complication with that (e.g. marshaling and unmarshaling the
state) so most people turned to the simple and easier to understand
solution of signing a MANIFEST file.

However, with 2.1 it is possible to implement a more elegant solution:
You run gpg on the server and gpg-agent on the client. gpg-agent
takes care of the secret key operations while gpg does the bulk data
and public key stuff. To implement that the gpg<->gpg-agent IPC needs
to be changed from local sockets to TCP over some encrypted tunnel. I
have not checked whether ssh is already able to proxy a local socket -
but if it can do so, you have an instant solution.

My bad. Sorry. Got confused with the RSA Coeff and u value. Case closed.

On 07/03/2014 11:30 AM, Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

That is OpenSSL and not GnuPG.

---

category: -> trash
status: unread -> resolved
topic: +mistaken

---

g10 Code's BTS <gnupg@bugs.g10code.com>
<T1663>

---

Given the hex MPIs for RSA

N:9773838E13FDC32F398AD92747DD7DDBC28DD114092E7CCC5008E360D78AE1F44509EA41C26C4B70513B4EFB1B93102DFD361AD41185F37DF48375899096EC6B0AF6E5D1B20D59D353FD9566EFE2C34B43DA27FE0E304C7F5895F02A49A0490D451761EF1D74E5DC606529D021296691A10D82416FDA66C02C787CD52A713E353A9466BDF8DA4E5E49D5B8791CA9AAF1DD8E3A5E4F5C810F1A2302CE004304EFABA97F8BDDD97D8C8E32505D78829ABDF05D80CB4DFE2806994BCEB625F796480D2753641B281E8F2568FBCF0F5F371676176A3DF4A0515B208B3F5D091536E5415D4B95E9718FD02D2E6D072FDB1688998EEACF0F061F0424BBBB906FED4BE9
E:10001
D:90443CE0AE326027300D0F65D793293C994B360A7BE48884A708906FC3624C72BF00FEE0BD2F237D4E23CCCC6E2BDC91B24E43A817391E04B15238385E3F25DDA18826CB656C4A50800562B7B772AECD9748CC27B9A4507A4E0C25C6627408A2575A3AB3E7BF5EE659FC83A3FAB2D13D8FC8AA7762F10C47AB14EAF4B38543D73EE8CD3DF2A6DBE9F8C4155ED022D5B0EE5D30ED94BCEE492848D1D33661E8FBCE200F63C9B113CD0BBA91E83CC90C906C884725A95E1985865B1B44302AD1401442D033BBAFFA3F553836B41D1FF7F2B9C7CA63D26B8A2CE310DDD19EBBF0599EC27FE80FAE90917BAB20F52FEC99ECF1D25ECED67FF9B9D12F3F9258F8F671
P:DCCEB325CA9ACD948ABC02BBCBD94E5E6E55CDBF65E9382A4C46C7AD225B18DC4E19CCF42C09DDBE403BAC9CC4237E2A1E93553AF53980123285D764F055C58865A6A7552C02852507AD33A2409098E59F32067147A680453A96AAD3F530BA34C13ADB2C6E7C31C0BD587350E924C70A66849F42434EC9213D071477AD706133
Q:AF96F814E8A17FF6EAD276A02D8EAD4BA7B83D12E3D48AA0C5529A1E0FA28A5F7A8352D9773B94FCD76BD919907E3D21919E646455EE74887CC0271E3F7E8B1B421EF11672783AA8666EDA4850F284FC213D74CF97929B7674FF73A330585C62C12382C1A19396B7389AD2F35F9687D06D99F2F829EC40145D42C7DCF80BD673
U:4B068919706F1C9DE8852EE75AB66AB7030D2C19951646516658CB8A0227E13527412646EB43EC09830B6830D3E3439D079AB8B44F991738A29238E040120A0A8BC3C13DB4D028B9BFD1BCD9D944A85E2F07565C840C5D6DD3AD1B7B0F88A11FC8D760C6ACC297411B7E8B90A68EC0AB81AE543049FE07E3DCF1ACA18A8ADC7E

.. decryption fails in cipher/rsa.c when using the default #if 1 branch.
Decrytion works without a problem when using standard mpi_powm(output, input,
skey->d, skey->n ) with the #if 0 branch.

Keys have been generated independently from gnupg. But seems to exist in 2.0.18
as well (decryption fails), but I haven't verified it in the source.

yes - I
I'll repoet this to OpenSSL - pls close this as PEBKAC.
sry.

Hi,
I see no progress on this RFE report, therefore I want to clarify it more verbosely.
In T1646 (wk on Jun 16 2014, 08:29 AM / Roundup) you asked, why we could not use:

ssh REMOTE 'cd DIR && sha256sum *dat' | gpg -s >files.sig

We could not use this because this will create sign the checksum - not the
payload of this checksum. In other words:
sha256sum create digest, then gpg2 internally create digest of this digest and
will create signature.
What we want to achieve is to bypass creating of digest in gpg2 and accept it as
parameter.

We have 'package build server' and normal signing process means:

1. copy data to signing server
2. gpg2 -sb
3. copy signature back
4. pass signature to rpmsign

But if the data is some iso/docker image or rpm package several gigabytes big,
then we have bottleneck problem. So we
changed the work-flow to:

1. make digest of the data
2. copy digest to signing server
3. gpg2 -sb --digest-algo <algo> --file-is-digest <digest>
4. copy signature back
5. pass signature to rpmsign

If we would do in step 3:

echo <signature> |gpg2 -bs

it would not be signature of header+payload which we want to sign and the
signature would not match.

To sum it up - we want to bypass computation of digest inside of gpg2. As digest
computation is in fact not secret and
it can be delegated somewhere else. Of course you have to trust those
environment which compute that digest. Which we do.
It allows separation of signing server apart from building server and allows us
to secure private keys even more, while
it allows no degradation of performance.

I hope that this clarify it little bit.

That is OpenSSL and not GnuPG.

I don't know this file.

This does not look like any GnuPG related code. Did you want to report this to
OpenSSL?

GKD hijacks the gpg <-> gpg-agent IPC. It does this for a long time now but
most users don't care about this and the mainainer keeps this as the default.
Everone using gpgsm has always run into this problem.

Yes, this is hijacking.

The gpg--agent emulation of GKD is indeed dangerous. GnuPG consists of several
closely connected components. Arbitrary replacing an compenent breaks the whole
thing. On proprietary systems such a behaviour would be called malware.

PKIX is entirely broken. Even the most expensive SSL certificate does not get
you any assurance. To avoid man-in-the-middle threats, please check the OpenPGP
signature with an existing version of gpg4win or compare the published
SHA-1checksums with those from the announcement mails.