My bad this already exists.

On 06/17/2018 02:10 AM, BenM (Ben McGinnes) wrote:

The two subsequent commits are the one I mentioned above (nested try/except
statements) and followed by a major PEP8 compliance overhaul of core.py.

Thanks for the patch and welcome to the weird and wonderful world of FOSS. :)

This is still true even after the latest changes to GpgOL not to require Kleopatra or GPA through the UIServer protocol. The details dialog / search still uses Kleopatra or GPA as a fallback.

Patch committed to master in commit 5a80e755008bbb3f4c7f91ffccd38f26cd8b3960

Not to worry, we've all been pretty busy of late.

test after system upgrades

Thanks. Pushed to master. I think it should also go into 2.2.

I've just pushed e037657edaf0b3ee9d2e30f6fe3edf6879976472 on the fix-T4019 branch

I was not aware that you could do this at all. You are right in that to start supporting this we first need to update libksba.

Apologies for the delay, been working on GSoC stuff.
Here's what I've got as of right now:

Not for export, there's a few traps in there, but if you want to take a second swing at import, I'd probably accept that instead.

That makes sense. If you don't have any other patches floating around for this, would you mind if I took a crack at rewriting export?

Okay, the import is pretty much a match for what I have tucked away elsewhere, to that will probably get merged as is, more or less.

Actually op_import and op_export do work, but they're the underlying SWIG bindings, not the more pythonic layer Justus added a couple of years ago. I'd been planning on fixing that this month (part of the work is in one of the ben/howto-update branches), but not merged with master until it could be documented since there's something potentially hazardous in there (exporting secret keys).

Yes, this is actually pretty high on the wishlist but AFAIK there was not yet a task for this.

@gouttegd Thank you very much!

Following in-person discussion with @werner last week, I have now added this EFL pinentry to the master branch of pinentry (commit 948105b).

@werner, what protocol design rule do you think is not being followed specifically?

From the autocrypt page:

Let me state it again: Using symmetric encryption for authentication is Bad Thing™.

Please discuss this at gnupg-devel. A bug tracker is not a useful here.

@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.

Yes, this is on purpose, we display only the most important commands, similar to --help

A smartcard may do several dozen operations per second and thus spawning a tool each time is not the best option. A generic notification scheme would be better. OTOH, notifications about secret key operations may accidentally create an oracle - which is not good.

cross-sign is also missing.

Great! I did not notice this feature!
Is it on purpose that this is not shown by hitting TAB in the --edit-key command prompt (and auto-completion)?

The fingerprint is required because that is the unique identifier for a key. Without that we would need to presetn a menu to select between keys. This would make scripting complicated again. On the command line c+p is easy enough to hget the fingerprint. c+P is also the reason why we print the fingerprint by default without spaces.

You are lucky. This has been possible for quite some time and since 2.2.6 it is an official part of the API. See T3816

Ok, so I guess that you can close this ticket.

By standard I mean "behaves" somewhat like coreutils. Filename encoding,.. meh I see that this could be a problem.

Clearly getting SWIG and Windows to play together nicely is a bit of a big ask, but it may be possible to leverage GPGME's compiled libraries with something like CFFI's ABI calling method (yeah, I know, ABI is never ideal, but it's better than what Windows has now).

You need to give the --with-foo options for each package.

No, we won't cripple GnuPG for testing purposes. You intended to test something else than the provided GnuPG.

SYSROOT support is not yet fully implemented. You need to give the --with-foo options for each package.
I will retitle this bug to indicates tha tit is a feature request.

I now have all three fuzz targets stable now, and not finding more bugs besides the reported memory leaks
https://github.com/gpg/gnupg/compare/master...catenacyber:7651c60
What do you think of it ? Do you want to use it for continuous integration ?

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?

My experience is that using a string is much easier and less error prone that to build up and allocate an error obj objects. A string leads to less code and bugs are easier to detect. There are enough patter on to handle strings in a safe way and key specs are in most cases already available in string form (e.g. hex fingerprints), be it from a mail interface, as a result of a database query or from the command line.

I think i can understand why this decision was made, but i'm not convinced it's a great solution. In particular, string-based arguments for C libraries are asking for trouble, and compound string arguments of the type described above are even more risky.

The use of --textmode is in general not a good idea. The GPA on Windows will work just fine regardless of line endings. Notepad.exe also does not care about line endings as does other proper text handling software. If there is a problem c+p from the GPA "clipboard" do the system clipboard we can fix that.

Work is in progress, but you can already see :

• some independent changes to the build system https://github.com/gpg/gnupg/compare/master...catenacyber:fdf1ec2
• adding the code for fuzz targets and build them https://github.com/gpg/gnupg/compare/fdf1ec2...catenacyber:fd62943
• changes to gnupg code to go beyond first bugs detected https://github.com/gpg/gnupg/compare/fd62943...catenacyber:3c14d0d

You may want to check with Hanno Böck

The semantics of --list-only are not well defined. Needs some overhaul.

An option to ignore SRV records would also be good for debugging. Thus I raised the priority and truned this into a feature request.

Then please set DISPLAY ;-)

Thanks for the description and the patch. I know what fuzzing is and GnuPG underwent quite some public and non-public fuzzing already. You may want to check with Hanno Böck to see how fuzzing can be done with gpg.

Sorry myself.
I will try to be clearer :

Sorry, I do not understand your request. Please describe what you want; linking to some arbitrary external sites is not sufficient.

Implemented in gpgme 1.11.0 if gpg >= 2.1.23 is used.

1.11 features a set of extended encryption functions which may optionally take a string as key specifications. In contrast to the array of key objects this string is a linefeed delimited list of key specifications which are passed verbatim to gpg. For OpenPGP a keyword feature is supported. For example the string

I've been working with one of Microsoft's developers on a temporary tool that should bridge the connection between named pipes and the Unix sockets emulation used by gpg-agent but things appear to trip up with sending the nonce. From the position of the tool, the nonce value is successfully sent (send returns 16), but never seems to be picked up by gpg-agent. Instead both gpg-agent and the bridge sit there until whatever tool is using them (I test using ssh-add -l) is terminated, at which point gpg-agent immediately spits up the message

The following post assumes that we want gpg --search to try to search; meaning that we don't want gpg to exit immediately because of the dead marks, without having sent a single network request to anyone.
The post is a bit long; sorry about that.

A work-around is now available for this in Python in the GPGME source. The relative path from the top of the GPGME source directory is here lang/python/examples/howto/groups.py. Like all the other scripts in the same directory, it also appears in the GPGME Python Bindings HOWTO, under the Miscellaneous heading near the end.

Rhat's for the client, right. I never used it. We used to run a Windows 8 instance in a VM to run tests via ssh on it. That worked most not really stable. For obvious reasons I am more interested in the server part ;-)

I would argue that the Windows port of OpenSSH is not unstable at this point, especially given that Microsoft is even providing it as an installable feature in the next regular Windows 10 release. The fact that the port is now using actual OpenSSH version numbers instead of their own 0.x versions lends credence to this as well.

Will be in 2.2.6.

Thanks for the pointer. But as long as the Windows ssh server is that instable I see no urgent need to add this to GnuPG.

I doubt that I will be able to fix this. The problem is that for Outlook we build the signed mail structure, which is a multipart MIME message. If you receive such a mail with a non crypto client you see the plain text and a pgp-signature attachment. That is why Outlook shows it as "attachment".

Thank you for your answer ! :)