I don't know why this issue plagued me and what is the culprit. I am trying Windows build for latest pyca cryptography 36 dev1 and got linker error while compiling cryptography-rust:

"C:\Python37\cryptography-main\src\rust\target\i686-pc-windows-gnu\release\deps\cryptography_rust.cryptography_rust.8yeboqs1-cgu.12.rcgu.o:cryptography_rust.: undefined reference to _imp___ZN3pem11ASCII_ARMOR17hda6e74d90990760eE collect2.exe: error: ld returned 1 exit status"

Missing function should obviously be named ZN3pem11ASCII_ARMOR17hda6e74d90990760eE and linked from pem library. But why it got erroneous imp prefix? No idea.

I'm using 32-bit environment with Python 3.7 / Rust 1.48 (i686-pc-windows-gnu) / PEM 1.0.0

I write a generate private key program with pem:

extern crate openssl;
extern crate pem;

use openssl::rsa::Rsa;
use pem::{Pem, encode};

fn main() {
  // Generate a new 4096-bit key.
  let rsa = Rsa::generate(4096).unwrap();

  let public_key = rsa.public_key_to_der().unwrap();
  let private_key = rsa.private_key_to_der().unwrap();

  let private_pem = Pem {
    tag: String::from("RSA PRIVATE KEY"),
    contents: private_key,
  };
  let private = encode(&private_pem);

  println!("{}", private);
}

But I couldn't found a way encode public data to PKIX format, do you have an idea?

Thanks much!

The removes the dependencies on both regex and once_cell, and gives significant performance increases in the current benchmarks. It passes all the tests, and I believe it has the same semantics as the regex.

I have added the Pem type to an enum that was previously able to derive Serialize and Deserialize but I can no longer derive as Pem does not implement the serde traits.

Could we add this support behind a serde feature flag please? It should be quite straightforward I think given that Pem is just a couple of String values.

Happy to do the work if you would land this as it's quite tedious manually implementing the serde traits in my codebase on an enum with quite a few variants!

Thanks for the prompt reply in #27! :cake:

This PR changes parse_many to return a Result. Feel free to discard the CHANGELOG.md if you do not want to maintain it, I figured it'd be somewhat useful with the breaking change. 😃

First off, thanks for the super helpful project! :cake:

I was looking at exposing pem::parse_many to Python users via the cryptography package (https://github.com/pyca/cryptography/issues/6351#issuecomment-932148321). In that process I discovered that parse_many silently discards all invalid sections, which I found quite surprising. That makes it hard to provide good error messages as I cannot differentiate between malformed and missing sections.

Long story short, would you entertain the idea of either changing parse_many to return a Result<Vec<Pem>> or adding an alternative method name (parse_all, parse_many_strict?) that returns an error on the first parsing failure? I'd be happy to send a PR with whatever you prefer. 😃

For reference, here's the current parse_many implementation:

https://github.com/jcreekmore/pem-rs/blob/b2cfec184815fecace9b5b1844eb6b15bda69793/src/lib.rs#L320-L326

This pull-requests adds benchmarks to encoding and decoding PEMs.

I hope to follow up with some more pull requests, adding support for PEM headers along with other ergonomic improvements, but I wanted to get benchmarks in first to validate that my future PRs will not regress performance.

There appears to be some interaction between once_cell and the 32-bit toolchain for windows that is causing the ASCII_ARMOR symbol to be mis-linked. To work around the issue reported in #29, hide the ASCII_ARMOR symbol inside of a function so that it is not even crate-wide available but is only available inside the function. Closes #29.

This decreases number of dependencies from 8 to 4.

Disabled features are:

• perf
  • PEM decoding should not be in a critical path
• unicode
  • Unicode support is not needed for ASCII only files

It might be more ideal to build a special purpose simple parser for PEM files, but this was an easy change with relatively large benefits IMHO.

When encoding data into PEM, the library uses \r\n line endings. This commit provides the user the ability to change this behavior and use \n instead by introducing encode_config and encode_many_config functions, which take an additional argument providing configuration for the encoding process. For backwards compatibility, encode and encode_many will use CRLF by default.