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 ! :)

You can do a

This does not require org-feed.el as far as I can tell, but it does require components of current Org Mode HTML export and publishing features which do not appear to be available in the current gnupg.org website build system.

A more recent request for this feature has been made via the devel mailing list:

Hi Werner. Did you by any chance already find the time to look into the changes?

I looked into it a bit. As bulk import is highly inefficient copying the keyring lots and lots of times the migration of a keyring with 1000keys takes around 6 Minutes.

The use case that @Valodim and @dkg are thinking of probably is using a setup-code that humans use to transfer from one device do another to decrypt a symmetrically encrypted setup-package, this issue is linked from:

https://autocrypt.org/level1.html#setup-message-import

There was a second person asking for a list-packets feature to verify if a file is encrypted correctly at gnupg-devel.

I'm not a fan of memoryhole. To say my criticism in one sentence: "Memoryhole is trying to sell the hide of the boar before it has been hunted."

Ok, I understand it. Project tag changed :)

I also struggled to get two cards running at the same time. Host system is Fedora 26 with gnupg 2.2.4.

Will go into 2.2.5

Note that there is no standard for this. In particular the encoding of filenames with special characters are different in almost all implementations. I tried to find a common ground for our implementation.

Just to be clear I think this issue is valid and we should add more checksum tools in the future. But I would want them to use libgcrypt and confirm to the standard *sum command line arguments like -c.

Hi Werner,

This is a MUA thing. Do you ask whether we plan to add it to GpgOL?

See T3796

Sorry, we won't do this any time soon. We may even shut the Bitcoin thing down. I was too troublesome from a bookkeeping POV.

I don't think that -R is a good way to implement BCC - it would be better to encrypt it separately. But people may have different ideas on this.

No clue what their problem is, I have a few projects scanned by Coverity. Most are forks that I took over, but one is not really. Not sure why they took such issues here.

Okay. Thanks for the report. I once looked at Coverty but decided not to use it because of their rules which would not allow me to document and fix a possible security vulnerability without following their process. If there is a security problem I will fix it according to my schedule and not allow anyone to delay it.

After fighting with Coverity over a fork of pinentry that has EFL. I setup to have Coverity scan. Which found some like 22 defects. Coverity unable to identify that I have any affiliation, after I spent/wasted hours getting a build to upload to Coverity to scan. Just to fight with some unhelpful person basically standing in the way of FOSS project, a wonderful Mel Llaguno. Decided for security reasons I be denied ability to use Coverity to scan pinentry for defects, even in the EFL interface I made and am the author of. Which also means I cannot fix other issues with pinentry or aide further in development....

Sorry, I don't understand. Can you describe your use case in more detail?

You have a token with one spare key which you want to use for encryption and certification. And being able to replace the encryption subkey eventually.

Originally dirmngr was designed to be a system service for the reason that CRLs are not user specific. However, the majority of systems today are used by a single user and thus we dropped that feature when integrating dirmngr into gnupg.

a key that is signed as its own subkey, in a construct where the key and subkey have the same fingerprint? what ever could be a valid use case for such a scenario?

I can't see why this should be out-of-spec. In fact I did this my self several times to create keys from other keys.

Your welcome, I can remake another unified patch if need be. I was starting to prepare things to be a stand alone fork. Did an initial .travis.yml file, and initial stuff for Coverity. Though never did get a build uploaded to Coverity. Not sure if you have ever run pinentry through Coverity or other GnuPG stuff, may be a good idea just to see if it catches anything.

Thanks for the long explanation. I think it should go into pinentry proper. I will have a closer look on it.

@werner no problem with re-opening. I closed as it seemed it was not of interest or wanted. I wasn't get any responses like asking why it was left out of 1.1.0 release. To my knowledge other than preferences of GnuPG devs, changes to suit your needs, grabbing, libsecret, etc. It should be good to go without any issues. Thus I was waiting next release, assuming it was already committed . May have confused it with some other PR that was committed. But there should not be any outstanding issues preventing it from inclusion. If there are it was never relayed to me. It should be ready for inclusion, less any requested changes.

@werner no clue, I thought it was merged in at some point. I could have sworn something happened there. I went on advising others like the TQT interface assuming EFL was already added. I was shocked it was not when release came out and no explanation as to why it was excluded.

Oh yes, I should re-open this because we should keep on tracking the status - either for an included EFL version or an external version.

I have not followed this bug for the last 6 months and meanwhile @justus and @neal moved on to the pEp company and are not any longer available to work on this. Although, I made the last pinentry release I do no closely follow the development. What I noticed is that we still don't have an EFL based pinentry despite that I explained them several times that I would like to see EFL in pinentry proper. I can't remember what the Mike Blumenkrantz version is or that there have been two pending versions at all. The thread is pretty long and I have note read it in its full length.

Proceeding with a fork, and likely will remove other interfaces and just maintain another version of pinentry for EFL. Maybe renamed to pinentry-efl, and only have that and tty and curses interfaces in addition to EFL.

'bit commit',

@gniibe just checking – any news for 2.2 support? Should I reopen this bug or report a new one against 2.2?

Thanks for having a look :)

Thanks for the patch. The "fixme" indicates that I probably was just too lazy to add and test support.

I have attached a small patch to show this two additional key flags with "--list-keys":