There are no betas; either you apply the patch mentioned above ( rG2f08a4f25df7) to a stock 2.2.20 or you build from the Git repo (STABLE-BRANCH-2-2, see https://gnupg.org/download/git.html).

thanks a lot dkg and werner :)

Could you guide me to where I find the beta or snapshot, so I could test it and give you feedback? I seem to be unable to find it on my own.

Noch was: Die Tipps für die Passphrase auf Seite 26 sind teilweise katastrophal. Der Tipp mit "jeden 3. Buchstaben" sollte entfallen. Die Überschrift heißt doch Passphrase, nicht Passwort. Eine Phrase kann gerne lang sein und auch vollständige Wörter enthalten, es müssen nur genug davon sein.

That's odd. :-)

FWIW, the code was written by the author of the specs and he note in his original patch (rGe0972d3d96) :

Thanks for your report. The problem of GnuPG was that it mandated padding length < 16 bytes, which is wrong.

In T4909#134002, @werner wrote:

• Is it a PGP 2 key (OpenPGP version 3 key format)? Support for this has been removed from gnupg 2 for security reasons.

The key was generated with gpg (not gpg2).

• Did you created or imported the key with gpg 1 after you installed GnuPG 2?

Yes.

In this cae, use gpg 1 to export the key and then import it again using gpg 2.

Importing the secret keys gives:

Please explain what your problems is. Setting arbitrary debug flags is not helpful for your or us.

In T4906#133954, @JW wrote:

@jukivili,

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

Of course, you are absolutely correct. I'll update the text accordingly. I thought EdDSA and EcDSA would be expressing differences between Cv25519 and NIST-256. I am not an expert. :-)

EdDSA is sign only - how do you want to encrypt to such a key? Did you mean cv25519 and ECDH?

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

@jukivili : Thank you. Please apply & push it.

Today I wanted to check linked issue: main window of Kleopatra doesn't remember size.
I worked on it again full day and found really good solution which is already present in KDE libs.
This is new fix for dialogs mentioned in this ticket and for MainWindow:
https://phabricator.kde.org/D28580

@werner what size of each additionally allocated secure memory area would you recommend? Is this something, that is better to set or leave up to the gpg-agent to decide? Will this additional memory be freed when not needed anymore or will it stay allocated until the process dies? I guess, the documentation could be expanded to answer this.

Attached patch should solve the issue for gcc 7.5 and clang 8.

Patch with my fix: https://dev.gnupg.org/D498
(now I know how to submit it!)

Thanks for looking into this!

You can test with newer compiler.

OK. I reopen this ticket to collect information.

It looks like the recipe to build the source file is missing the necessary arch options. I.e., -mcpu=power7 -mvsx ...

I can't reproduce the error (no problem for build). My (cross-)compiler is:

I think that it is compiler issue for AltiVec (now, VSX) support.
The usage is not ambiguous. It _is_ ambiguous in the header file.

Thansk for your report.

It runs like:

$ gpg-connect-agent "scd devinfo --watch" /bye
S DEVINFO_START
S DEVINFO_END
S DEVINFO_STATUS new
S DEVINFO_START
S DEVICE generic D276000124010200F517000000010000 openpgp
S DEVINFO_END
S DEVINFO_STATUS removal
S DEVINFO_START
S DEVINFO_END
OK
$ 

Push the change to master.

werner closed this task as Spite.

We do not use Github.

See my comments on the other bugs you posted today.

Please see my other comments; we need proper bug reports and not just arbitrary snippets.

That are all development versions and they may require the latest changes from the repo of other libraries.

Please write proper bug reports and do not just post snippets from some arbitrary build process. In addition master is non-released software and thus it is in general better to ask at gcrypt-devel@gnupg.org for help.

Sorry, if you use your own copy of GnuPG on GitHub, it is all up to you. We do not use Github.

I've tested this issue on my Windows10 laptop.

I've checked: this issue is reproducible in Kleopatra 3.1.11 / Win10
I have installed version of Gpg4win, not portable

Also see Issue #10, Add Travis testing in the GnuPG GitHub. The PR adds Travis testing to the entire GnuPG suite.

The problem itself is fixed (in T4495: UBsan finding "certdump.c:695:3: runtime error: null pointer passed as argument 2"). The variable buffer cannot be NULL at memcpy.

thanks!

Done; will go into 2.2.21 (T4897).

Thanks.

This bug is linked to restoring window size in case of multi-monitor multi-DPI setup.
There is QT bug report: https://bugreports.qt.io/browse/QTBUG-77385

Of course it is important, that's why it it printed by default.

This is an important information to know because it can help to avoid bug reports.

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).

I think that what you want is adding --batch option. In the gpg manual, we have:

--passphrase-file file
       Read  the passphrase from file file. Only the first line will be
       read from  file  file.  This  can  only  be  used  if  only  one
       passphrase is supplied. Obviously, a passphrase stored in a file
       is of questionable security if other users can read  this  file.
       Don't use this option if you can avoid it.

Hello Team,

For operations which require private key, it is needed to unlock private key.

From where did you downloaded it? Did it show a valid issuer for the software (Intevation GmbH)?

Thanks for the quick fix, @werner!

Fixed.

Hello,
Sorry for the late reply but with your help we found a bug in our code and it has been fixed. Thanks for your assistance!

Arggh, this code is a whole mess (e.g. it uses its own logging code). I spent the last week to rework large parts of it for master. I am going to look into this case now.

If you want OCSP you need to enable it. CRLs or OCSP are a MUST under the profile we developed gpgsm. This is why --disable-crl-checks by default is not possible. There are lot of interesting things you will come across if you start to use S/MIME. For example you also need to care about the algorithms used for intermediate certificates used to sign CRLs - they need to comply to the policy as well. Or the rarely used PSS padding we encounter sometimes and which is not supported and will probably not be supported

Okay. Thanks.

You forwarded me an email, which said it went well.