"gpgsm: invalid radix64 character 2d skipped" when trying to import a PEM file with DOS line endings (CR+LF)
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	thomas
	Feb 14 2020, 4:07 PM

Description

$ gpgsm --import crlf.pem
gpgsm: invalid radix64 character 2d skipped
gpgsm: invalid radix64 character 2d skipped
gpgsm: invalid radix64 character 2d skipped
gpgsm: invalid radix64 character 2d skipped
gpgsm: invalid radix64 character 2d skipped
gpgsm: total number processed: 0

This happens when crlf.pem contains CR+LF line endings. It works fine with just LF.

Use case from http://lists.wald.intevation.org/pipermail/gpg4win-users-en/2020-February/001607.html is importing certificates from openkeys.de

Details

External Link: http://lists.wald.intevation.org/pipermail/gpg4win-users-en/2020-February/001607.html
Version: gpgsm (GnuPG) 2.1.18

Revisions and Commits

rG GnuPG
	rG38f819bd6d77 gpgsm: Fix import of some CR,LF ternminated certificates
	rG6248739799fd gpgsm: Fix import of some CR,LF ternminated certificates

Related Objects

Mentioned In: T4860: Release GnuPG 2.2.20

Event Timeline

thomas created this task.Feb 14 2020, 4:07 PM

Thomas, please provide a sample certificate. I can't access the intevation site to see whether one of the links has the cert. And pretty please fix the wald certificates!

Which OS are you using? Is that a Debian version or something?

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.

And any certificate with CRLF should work to reproduce the problem, that's why I didn't attach one here (just use an editor), but if you want to use the certificate of the OP of the thread on Wald, you can download it at https://api.openkeys.de/api/certificate/brandmauer.de/eric.weis/

The gpgsm version I used is from a system with Debian stretch, I haven't tried newer versions.

Really interesting: The code didn't changed since since 2003 and the bug must have been there all the time. It does happen only for 25% of the certificates with CR and LF; the others have padding characters at the end '=' which is also an indication of the end of the base64 block. I wonder why this has not been reported more often; maybe because most people import binary certificates.

• werner claimed this task.Feb 15 2020, 7:08 PM

• werner triaged this task as Normal priority.

• werner added a commit: rG6248739799fd: gpgsm: Fix import of some CR,LF ternminated certificates.Feb 15 2020, 7:23 PM

• werner added a commit: rG38f819bd6d77: gpgsm: Fix import of some CR,LF ternminated certificates.