0.14.0 release planning

[djc]

Proposed release notes

0.14.0 contains a number of potentially breaking API changes, though hopefully the rate of API change should slow down after this. Here is a summary of the most noticeable changes you might run into:

• signed_by() methods now take a reference to an &Issuer type that contains both the issuer's relevant certificate parameters and the signing key (see Use Issuer directly in the public API #356). The from_ca_cert_der() and from_ca_cert_pem() constructors that were previously attached to CertificateParams are now attached to Issuer instead, removing a number of documented caveats.
• The RemoteKeyPair trait is now called SigningKey and instead of KeyPair being an enum that contains a Remote variant, that variant has removed in favor of KeyPair implementing the trait (see Unbundle params from output types #328).
• The KeyPair::public_key_der() method has moved to PublicKeyData::subject_public_key_info() (see Unbundle params from output types #328).
• Output types like Certificate no longer contain their originating CertificateParams. Instead, signed_by() and self_signed() now take &self, allowing the caller to retain access to the input parameters (see Unbundle params from output types #328). In order to make this possible, Certificate::key_identifier() can now be accessed via CertificateParams directly.
• String types have been moved into a module (see Move string types to separate module #329).

@cpu @est31 thoughts?

[cpu]

Should we also highlight these breaking API changes?

• ef250b5 - the KeyPair::public_key_der() -> subject_public_key_info() change.
• 67a73a7 - the Certificate::key_identifier -> CertificateParams::key_identifier change.

Otherwise LGTM

[djc]

Should we also highlight these breaking API changes?

• ef250b5 - the KeyPair::public_key_der() -> subject_public_key_info() change.

• 67a73a7 - the Certificate::key_identifier -> CertificateParams::key_identifier change.

Otherwise LGTM

Good points, added.

[est31]

the KeyPair::public_key_der() -> subject_public_key_info() change.

The name and rustdoc of subject_public_key_info is a bit jargon-y. Maybe add something to the rustdoc that it contains the public key? Such a sentence sentence was there before ef250b5. It doesn't have to be that sentence 100%, just something with that purpose.

[djc]

The name and rustdoc of subject_public_key_info is a bit jargon-y. Maybe add something to the rustdoc that it contains the public key? Such a sentence sentence was there before ef250b5. It doesn't have to be that sentence 100%, just something with that purpose.

See

• Tweak docstring for PublicKeyData::subject_public_key_info() #358

[djc]

rcgen currently has ring as one of the default features. Do we still want to keep that? rustls now has aws-lc-rs as a default, but will likely stop selecting a default in the future. In other crates, I like requiring downstreams to pick the provider.

[cpu]

my ranked preferences are:

1. replace aws-lc-rs as the default, matching current rustls
2. remove the default entirely
3. the status quo

I think it'll be smoother to piggy-back on the rustls change later on vs doing it here first.

[djc]

my ranked preferences are:

1. replace aws-lc-rs as the default, matching current rustls
2. remove the default entirely
3. the status quo

I think it'll be smoother to piggy-back on the rustls change later on vs doing it here first.

I'd probably go the other way:

1. Remove defaults
2. aws-lc-rs by default
3. ring by default (status quo)

I think picking explicitly is better. I also think fewer transitions is better, so it doesn't make much sense to me to transition to aws-lc-rs by default now if we already think we might want to transition to no default later. Given that rcgen does not depend on rustls, I don't see a strong reason to stay directly aligned with rustls.

[est31]

1. ring by default (status quo)
2. aws-lc-rs
3. Remove defaults

My reasoning: ring still has a better portability story than aws-lc-rs and on many platforms it still requires cmake to be present. rustls wants to be fast, which makes a lot of sense as it is on the hot path, but rcgen can be a few percent slower or faster. Of course, if you already use rustls then rcgen using ring makes little sense, which is IMO the strongest argument in favour of aws-lc-rs.

Googling "cmake" on the aws-lc-rs issue tracker:

aws/aws-lc-rs#766
aws/aws-lc-rs#800
aws/aws-lc-rs#780
aws/aws-lc-rs#828
aws/aws-lc-rs#522

Admittedly, ring is not very portable either, but it is certainly more portable than aws-lc-rs.

No defaults is I think annoying because it increases the number of things people need to do in order to generate a certificate. You'd require enabling an rcgen feature in order for it to be useful, or even use independent crates.

Let's revisit this decision in a year maybe. Maybe by then aws-lc-rs is more portable, they are not stagnant either. Maybe by then rustls has no defaults, then defaulting to ring is a better decision.

[djc]

Okay, let's stick with ring for now. I'll publish the release soon.

[djc]

• Published rcgen v0.14.0 at registry crates-io
• [new tag] v0.14.0 -> v0.14.0
• Release notes