Thanks for testing. I recall that I wanted to update the checking but a phonecall disturbed my hacking sequence; should have used DND.

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.

What kind of hardware token?

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.

Come on, it is in daily use for 15 years. MUA which can't handle MIME at all but PGP are still able to decrypt PGP/MIME. That is why ME specified PGP/MIME this way.

--use-tor does not avoid it because the CRL-DP can be made unique for each certificate. Depending on the verification model a CRL or OCSP lookup is necessary for correct evalution of a signature (shell model as used for qualified signature). This is why we in gpg honor-keyserver-url is not enabled by default; the keyserver URL take from the key is the OpenPGP counterpart of the CRL-DP.

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.

The implemented X.509 profiles require that the status of a certificate is to be checked. CRLs are also not looked up for each verification but only once during their lifetime. Some CA have unreasonable short lifetimes for their CRL but it is the decision of the user to use such a certificate.

I disabled your account but the I won't delete any comments of yours. They are considered to be in the public domain (see welcome page) and are parts of other bug reports. Thanks for those comments.

dirmngr looks into /.etc/resolv.conf and does not know anything about systemd specific things (nor do I). Thus having a symlink seems to be an appropriate solution.

I close this bug - if you can provide the log files please feel free to reopen.

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

That might be the case. I suggest to use

Are you sure that you are runtime linking to the same libgpg-error version you used for the build?

This would then be a 1024 bit DSA key according to the DSA-2 specification. Back when DSA was introduced to PGP the specs did not specify a truncation. Maybe because there were no hash algorithms larger than 160 bits at that time.

If you look at the specs of DSA you will see that using SHA-256 truncated to 160 bits is not defined. DSA 1024 uses a 160 bit subgroup and thus SHA-256 would need to be truncated to 160 bits. If you want to look closer at that key the command

You can't use the curve Ed25519 with ECDSA; you need to use EdDSA, The error checking when using the parameter file does not catch all errors. It should do this of course.

Sorry, I don't understand your request. I might missing some context related to the neomutt bug, though. What I can see tehre is that gpg options are used after the option/command to arg delimtyer "--" . That is of course wrong. It might be that mutt uses a special syntax here but I can't remeber that because it is 15 years since I implemented the new crypto layer in mutt. And you should really prefer to use the use_gpgme than the >20 year direct call of gpg.

@aa: this is not a platform to share arbitrary data or fun stuff. Please use some other service for this.

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.

One of these TOFU bugs. Thanks for the good bug report.

There can't be an MDC warning if MDC is not used ;-)

Well, that was a bit tricky to fix but it has been done and will go into 2.2.5.

Depends: Not everything you see has been protected by the signature. Thus such a description would need to go into more detail.

BTW, using a long passphrase for public key encryption is in almost all cases useless. The passphrase is there to protect the private key, the passphrase is never sent to another site and will only be seen by gpg-agent, pinentry and the tty I/O software of the OS.

FWIW, Running gpg from the commandline with option -v shows the pinentry flavor.

I can't replicate it here. With my key it takes
real 0m0.346s
user 0m0.080s
sys 0m0.004s
and for your key it takes a few 10ms longer (more hops). Is one of your DNS responder failing? Can you please run dirmngr with --debug dns ?

I already talked with the upstream author and we figured a possible problem due to an non-locked use of the core function. The cause of this is

unsigned char *tmpval = ec->mem + ec->memlocation;
*tmpval = (*tmpval + 1) & 0xff;
ec->memlocation = ec->memlocation + ec->memblocksize - 1;
ec->memlocation = ec->memlocation % wrap;

which is non-atomic and will thus leads to the out-of-bounds deref. The EC object may only be used by one thread at a time.

The actual problem is that justus quit his job to work for pEp. Thus we have no maintainer for the python port. There is one candidate for this job but don't expect any fast fixes because one of the near term goals will be to replace swig so that we can provide the bindings also for WIndows. Maybe that will also solve the problem with different Python versions.

I would also suggest to discuss this at the gcrypt-devel list so that you can get get comments from others as well.

Your are looking at the libgcrypt code. Unfortunately that does not help us. What I would like to see are two protocol implementations, using sccryptone with libgcrypt and one with anoter scruypt implementation. Do they both work? If so, there is no bug in libgcrypt's code - at best the parameter have been given different names and we can point other name use in the docs.

tests/t-kdf uses test vectors from an I-D and obviously works fine. Maybe that I-D has a different parameter naming than what is used in your examples. I simply can't say without researching the whole thing. Please let t me know a concrete bug where that KDF is not compatible with other implementations. As an example here is one of our test vectors:

Let me comment this

Oh dear what an evening and morning. I reversed the facts I reported. Sure 2.1 is borken - that is the whole point. ( I realized that only after install 2.2.4 and generating fresh keys). To avoid confusion I will delete my last comments.

I can't tell you from your input what is wrong with your key. Please run

Okay, so on Suse we have the same problem w/o the somewhat intrusive changes of Fedora. The inetresting thing is that segv code part is the same as used in Linux.

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

Thanks for the report. I have a few questions, though
Which version of libgpg-error are you using?
What are the changes Fedora made to libgcrypt (and libgpg-error)?
Which CPU, what compile options and which compiler version?
Can you repeat this with a stock libgcrypt and libgpg-error?

Why do you need this for a keyserver? Keys are public and in-house keyservers should be at a local address and there need to be strict provisions not to upload to a public keyserver. Maybe LDAP or the kDNS thing (which is currently disabled) would be better for such use cases.

Can you exactly explain how you tested this?

gnupg 2.0 reached EOL - there won't be any fixes.

Do you mean that GnuPG installed to c:/gnupg/bin/ crashed if that mentioned --homedir is given but it does work if it is installed at the standard place? Please run "gpgconf --version" in both ways.

FWIW, I ran the same test with three card versions: