Sounds good! I give it to me for testing / documenting this.

With master we can now do:

@werner Be my guest.

Why not using PowerShell? Because --with-colons does not output the required hash? But that can't be the reason because Python has the very same problem. Using Python for scripts is anyway a bit of overkill.

Precondition: A list of pubkeys, as keyring or as keyring file with list of fingerprints.
Goal: a flat file structure that can be uploaded on my webserver.
Platform: Windows, a better solution does require less additional dependencies apart from Gpg4win.

... that would be useful in many ways. I'd say we should support anyone who wants to use pythong-gnupg on windows.

@werner it is like @aheinecke writes:

As I see it Bernhard is just asking for the flat strucuture so basically some export script that creates the needed files on windows.

If they really want to do that for Windows, they can use some database approach like Protonmail does it. This does not require any file structure.

Sorry, we won't implement a server for WIndows. No sane provider uses Windows for a large mail setup.

Marking this as resolved as it was forgotten in the testing state.

I'm also seeing the same behaviour on a freshly installed Windows 10 1809 with Gpg4win v3.1.4. Have to kill dirmngr from task manager to be able to get into Kleopatra.

Hi, Has anyone found a reason why that happens. I run into the same behavior on my Windows 10 1803 computer. I have Gpg4win version 3.1.3 freshly installed and dirmngr hangs. Thanks and best regards, Peter

I need to know which of the processes segv: mkdefsinc, cat or the subshell. And a backtrace would also be very helpful.

Was anyone successful in debugging dirmngr? I'm having the same issue. The dirmngr process gets stuck, no output at all, and this causes Kleopatra to get stuck waiting for it. I can only run Kleopatra after I have killed the dirmngr process. If I understand correctly I still need this process for network-related functionality, so I would need to fix it if I want to use all functions.

IMO this can be closed. At least the problem for which I intended this ticket is fixed.

Printing "(null)" is just coincidence because NULL is stored at the respective stack address on one platform.

Well I'm pretty sure the reason is that valuetable_buffer is not inialized in _gpgrt_estream_format. But the resulting behavior confused me. It would not crash. But it would also not print "gpg: Entschlüsselung als fehlgeschlagen angesehen: (null)" It would just print nothing instead of that string.

Not really. off_t is a real portability problem and this why we moved that problem out of the GPGME ABI to the application. Thus the application needs to care about mapping gpgme_off_t to whatever off_t it uses. Without that we can't provide a stable _and_ toolchain independent ABI.

Thank you for pointing this out.

Following patch fixes the issue.

@tinkerwolf This is weird... I've reinstalled my PC from scratch with an initial account set as local, and was able to set up GPG4Win perfectly fine for the first time on my PC (as I did in the VM). So, set up a VM with an initial account set up from an online account. GPG4Win started up fine... I am now really confused!! Somewhere within the getting set up with an online account, something has to be happening that interferes with dirmngr..
Will investigate further.

@RAmbidge are you able to further test this by using a VM with a MS account? I don't have the means right now, or I'd do it myself.

That actually makes sense, because it works fine on my laptop, where it's been a local account from the start, but it's broken on my desktop where it was originally a MS account, but is now local.

I'm having the same issue. I read somewhere that it's likely caused by using an online Windows account to login with. So I converted to local log in. Issue persists. As a test, I've just set up a VM with a local account set up at install, and GPG4Win works perfectly fine. So I'm guessing that there may be an issue which stays in the files system caused by online account users. I'm not a programmer and have no idea how or where to look to see what's causing it and how to fix it though.

Maybe the off_t mess comes from following line

The gpgme c api already had a convenience function gpgme_data_rewind to do data.seek (0, SEEK_SET); As this is by far the most common seek operation. KMymoney also only uses such seeks.

In T3996#114721, @aheinecke wrote:

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

So what the error tells us is that "off_t" is defined as long in the declaration but as something else in the definition.

But how can that be? data.cpp includes the data.h header so they both should have the same definition of off_t.

The only thing I could imagine is that something which is included in the cpp but not in the header undef's off_t and defines it to something else.

Or more likely that the archive was compiled with a different definition of off_t then what is included in the headers when kmymoney is built.

Are you using the same mingw version as the buildchain which compiles the gpgme binary?

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

You are not cross-compiling. This is not suggested and I don't have the environment to replicate this. Maybe @aheinecke can help.

@werner I was hoping to make a modified gpg-agent build that would let me walk through what's going on after the nonce is sent but it looks like the gpg4win process only takes in a package of pre-built gpg binaries which rules that out. As far as I can figure out, after the nonce is read and accepted, libassuan creates a stream object out of the socket and then finding nothing in the stream terminates the ssh handler. We send the actual client request immediately after the nonce but in a separate call to send() so I now wonder if by not having anything read in at the same time as the nonce gpg-agent or libassuan thinks that it's a 0-length stream.

No longer happens when the good old ldapwrapper is used.

Still happens. There are also "BER" errors that seem random.

I just took a look through assuan-socket.c and it appears that we just need to send the nonce and don't need to read anything back. We also found a bug on our side that was preventing the nonce from being sent, which has been fixed. The error message logged above no longer happens.

The nonce is a string of octets thus it needs to be passed verbatim. I would need to study the code in libassun/src/assuan-socket.c to tell more.

@werner After sending the nonce value from the socket file, does anything need to be read back before ssh-agent commands can be sent? Are there any byte ordering requirements for sending the nonce or can they be sent in the same order as they are in the file?

Got the question about this note from a user (in a internal email) and I see the problem that users do not have enough information to decide this. They do not know what the consequences of this note are (and suspect it to be the cause of error of they see it together with other problems). So to me it is more than a 'wish' as it will generate questions and leaves users in a situation where they cannot progress by their own in most of the situations.