> On Apr 15, 2022, at 2:25 PM, David Blevins <[email protected]> wrote: > >> On Apr 15, 2022, at 1:10 PM, Jean-Louis Monteiro <[email protected]> >> wrote: >> >> David, yes I figured you'd want to work on JWT. I looked and it seems our >> setup needs some love. Some additional tests with EC based algorithms and a >> couple of other endpoints need to be updated. > > On the note of EC keys, I wonder what people think about potentially using > this key parsing library I wrote: > > - https://github.com/tomitribe/churchkey > > It does parse EC keys in several different formats, supports 100+ curves and > has 1450 unit tests. If you have a public or private key in a handful of PEM > formats, OpenSSH format, SSH2 format, JWT format or plain binary DIR format > it will parse the key. > > The very significant con is that it would be the first time we adding a > library from that org to our server. It's something I've deliberately > avoided. I've always preferred to keep lines clean. I'm not sure how I feel > about adding such a dependency and potentially opening a can of worms. > > I'd like to hear some thoughts from others. Perhaps I'm being overly > cautious.
I thought about this for a few weeks and came to the conclusion I'm not being overly cautious. I don't think we want corporate names of any kind being imported in our source or visible in our Maven dependencies of the server itself. Tools are ok, but the actual thing people are downloading and putting in production. My first thought was to fork it all over, but that would create a maintenance headache. I checked and there was a good domain name available so I repackaged all the code and maven groupId to the following completely neutral names: package: io.churchkey groupId: io.churchkey It's already been released and is in Maven Central. Our key parsing will get a serious upgrade shortly. -David
smime.p7s
Description: S/MIME cryptographic signature
