SmallRye X.509 library and additions to the SmallRye Common library

[Farah Juma]

We have a few components in the WildFly Elytron project that could potentially benefit from being moved to SmallRye so they can be consumed by other projects. In particular, the Elytron components we have in mind are as follows:

• Client SPI for Let's Encrypt's Automated Certificate Management Environment (ACME) protocol (https://github.com/wildfly-security/wildfly-elytron/tree/1.x/x500/cert/acme)
• Utilities for generating certificates and certificate signing requests (https://github.com/wildfly-security/wildfly-elytron/tree/1.x/x500/cert/base)
• Utilities for ASN.1 encoding/decoding (https://github.com/wildfly-security/wildfly-elytron/tree/1.x/asn1)

We have selected the above components because the Quarkus team has already expressed interest in their use so these are good candidates to be shared.

The idea would be to create a SmallRye X.509 library that contains components for the ACME client SPI and for the utilities for generating certificates and certificate signing requests.

A component that contains utilities for ASN.1 encoding/decoding could be added to the SmallRye Common library. Since these utilities depend on a few components from WildFly Common (codec, bytes, iteration, and array), we could also add these components to SmallRye Common to avoid introducing a dependency on WildFly Common. 

In terms of attribution, for both the SmallRye X.509 library and the additions to the SmallRye Common library, we could take the same approach that was taken when the SmallRye Common library was added, i.e., we could add the “Co-authored-by” trailers to commits that include content authored by multiple people.

Any thoughts on this?

Thanks,

Farah

[David Lloyd]

I think this is an interesting idea. I have a couple questions though...

Is the idea to separate the code from the WildFly branding? Is the
recent modularization effort of Elytron not sufficient to make the
subprojects consumable by downstream projects, or are there dependency
issues that are coming into play, or some other motivating factor?

SmallRye Common hasn't quite gotten to the "wheels hitting the road"
point (just due to backlog/resourcing) so there might be some delay in
releasing these bits/making them live, so that might be something to
consider if there is a schedule in play here. Also I'm wary of
blowing it up too quickly considering its low (effectively negative)
real-world age.

That said I think it's reasonable to move things there if they're
sufficiently "neutral", especially things that already had a home in
WildFly Common previously, assuming they weren't too regrettable
implementation-wise. :-) The others we'd probably want to evaluate on
a case-by-case basis, probably in dependency order if it comes to
that, to ensure that we're really not making it "Common and Also Some
Security" for example. Some of these things might be better done as
top-level SmallRye projects, or part of a bigger effort to make
Elytron more of a SmallRye thing in general, or whatever.

> --
> You received this message because you are subscribed to the Google Groups "SmallRye" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to smallrye+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/smallrye/d459b6cf-f4a8-4199-8bab-e64d7d26799c%40googlegroups.com.



--
- DML

[Farah Juma]

On Thursday, March 5, 2020 at 4:53:19 PM UTC-5, David Lloyd wrote:

I think this is an interesting idea.  I have a couple questions though...

Is the idea to separate the code from the WildFly branding?  Is the
recent modularization effort of Elytron not sufficient to make the
subprojects consumable by downstream projects, or are there dependency
issues that are coming into play, or some other motivating factor?

The main idea here is to separate the code from the WildFly branding since there is often some push back to using things from the WildFly namespace. These initial candidate components seem like a good fit for a more neutral location than the WildFly Elytron project.

 

SmallRye Common hasn't quite gotten to the "wheels hitting the road"
point (just due to backlog/resourcing) so there might be some delay in
releasing these bits/making them live, so that might be something to
consider if there is a schedule in play here.  Also I'm wary of
blowing it up too quickly considering its low (effectively negative)
real-world age.

This would be ok since we don't have a specific schedule in play here.

 

That said I think it's reasonable to move things there if they're
sufficiently "neutral", especially things that already had a home in
WildFly Common previously, assuming they weren't too regrettable
implementation-wise. :-) The others we'd probably want to evaluate on
a case-by-case basis, probably in dependency order if it comes to
that, to ensure that we're really not making it "Common and Also Some
Security" for example.  Some of these things might be better done as
top-level SmallRye projects, or part of a bigger effort to make
Elytron more of a SmallRye thing in general, or whatever.

On Thu, Mar 5, 2020 at 3:23 PM Farah Juma <fj...@redhat.com> wrote:
>
> We have a few components in the WildFly Elytron project that could potentially benefit from being moved to SmallRye so they can be consumed by other projects. In particular, the Elytron components we have in mind are as follows:
>
> Client SPI for Let's Encrypt's Automated Certificate Management Environment (ACME) protocol (https://github.com/wildfly-security/wildfly-elytron/tree/1.x/x500/cert/acme)
> Utilities for generating certificates and certificate signing requests (https://github.com/wildfly-security/wildfly-elytron/tree/1.x/x500/cert/base)
> Utilities for ASN.1 encoding/decoding (https://github.com/wildfly-security/wildfly-elytron/tree/1.x/asn1)
>
> We have selected the above components because the Quarkus team has already expressed interest in their use so these are good candidates to be shared.
>
> The idea would be to create a SmallRye X.509 library that contains components for the ACME client SPI and for the utilities for generating certificates and certificate signing requests.
>
> A component that contains utilities for ASN.1 encoding/decoding could be added to the SmallRye Common library. Since these utilities depend on a few components from WildFly Common (codec, bytes, iteration, and array), we could also add these components to SmallRye Common to avoid introducing a dependency on WildFly Common.
>
> In terms of attribution, for both the SmallRye X.509 library and the additions to the SmallRye Common library, we could take the same approach that was taken when the SmallRye Common library was added, i.e., we could add the “Co-authored-by” trailers to commits that include content authored by multiple people.
>
> Any thoughts on this?
>
> Thanks,
> Farah
>
> --
> You received this message because you are subscribed to the Google Groups "SmallRye" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to smal...@googlegroups.com.