Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEMDocument(pemString:) does not support Windows line endings #66

Open
natevw opened this issue Sep 17, 2024 · 1 comment
Open

PEMDocument(pemString:) does not support Windows line endings #66

natevw opened this issue Sep 17, 2024 · 1 comment
Labels
kind/bug Feature doesn't work as expected. size/S Small task. (A couple of hours of work.) status/needs-design Needs further discussion and a concrete proposal.

Comments

@natevw
Copy link

natevw commented Sep 17, 2024

When initializing a PEMDocument (or in my case really a swift-certificates Certificate) via a pemString: which comes from a Windows-world service, an error is thrown that it "could not find PEM start marker". The same string piped to openssl x509 is recognized successfully.

I believe the problem is that

let (
beginDiscriminatorPrefix,
beginDiscriminatorInfix,
beginDiscriminatorSuffix
) = self.firstRangesOf(
prefix: "-----BEGIN ",
suffix: "-----\n"
)
looks only for a suffix of specifically "-----\n" and thus does not match on what in my case is "-----\r\n". (There may be more "\n"-dependent logic beyond that point but this is the source of the initial failure.)

The workaround I'm using is to pass in myPemString.replacingOccurences(of: "\r\n", with: "\n") but it would be nice if these libraries could handle line breaks more generically. I'm not sure if this is the most relevant standard but RFC 1421 says:

To represent the encapsulated text of a PEM message, the encoding function's output is delimited into text lines (using local conventions) […]

which I suppose could be argued that the PEM document conventions could to be local to the receiver but in this case my PEM document is using the "local conventions" of the sender :-)

@Lukasa
Copy link
Contributor

Lukasa commented Sep 18, 2024

Thanks for this @natevw! This is a good catch.

I'd like to avoid replacingOccurences(of:with:) here, but updating our parsing logic to handle windows newlines would be very valuable.

@Lukasa Lukasa added kind/bug Feature doesn't work as expected. status/needs-design Needs further discussion and a concrete proposal. size/S Small task. (A couple of hours of work.) labels Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Feature doesn't work as expected. size/S Small task. (A couple of hours of work.) status/needs-design Needs further discussion and a concrete proposal.
Projects
None yet
Development

No branches or pull requests

2 participants