Merge with xml-encryption

[forty]

Hello,

What would you think of absorbing this package inside xml-crypto https://github.com/auth0/node-xml-encryption ?

The reasons why I think it would make sense:

• your package is named xml-crypto and not xml-signature, so doing encryption would make sense :)
• having fewer but bigger and more supported/used packages is good for the community
• both projects have the same license
• both projects have mostly the same dependencies (I have just made a PR to remove node-forge from xml-encryption)
• xml-encryption is quite small too (~300 LoC)

I'm not suggesting to just copy paste everything, but to import and update the code so it can fit your coding standards (which seems to be a bit different from theirs)

What do you think?

[forty]

I'll note that I'm coming from https://github.com/node-saml/passport-saml which depends on both packages.

[LoneRifle]

Given that xml-encryption is more actively maintained and well-resourced, it really should be a matter of this repo merging its implementation with them. I otherwise agree with all your other points. I do not have the bandwidth to undertake this right now though.

[RopoMen]

@forty I like this idea as well. I'm maintaining passport-saml fork, suomifi-passport-saml and these latest xmldom issues xmldom/xmldom#270 is giving me some headache because I cannot update "xml-crypto" and "xml-encryption" to use latest xmldom version.

If this absorption would happen, then at least there would be only one dependency that is also using xmldom ;)

[forty]

@RopoMen oh I have read something about your fork just yesterday, good luck with that :) (I'm in the same kind of boat ;) )
While you are here, may I ask why you needed to work? In my experience, node-saml contributors are pretty active and open to contributions.

@LoneRifle Hum, my very quick assessment concluded that xml-crypto seemed more popular and more active :) And after reading both code bases, I think xml-crypto is a saner starting point ;)
I will try to negotiate some of my time later this year to work on this (no promises, and not in August for sure).

While we are at it, @LoneRifle, what's your feeling on Typescript? :)

[LoneRifle]

@LoneRifle Hum, my very quick assessment concluded that xml-crypto seemed more popular and more active :) And after reading both code bases, I think xml-crypto is a saner starting point ;)

@forty I trust your judgment on this matter - I assumed some stewardship of this package only because we were dependent on it for work, but we will be migrating away from SAML in due course.

While we are at it, @LoneRifle, what's your feeling on Typescript? :)

No strong feelings either way, with respect to this particular package

[LoneRifle]

@forty so I've spent time thinking about this on and off; given that xml-encryption is still somewhat maintained, I thought one approach would be to import their source as a git submodule. This resolves @RopoMen's most immediate concern (and probably others' too) - having to keep up with two separate dependencies with an overlapping set of transitive dependencies (eg xmldom). As time passes, we can look into making further changes to couple the two codebases more tightly.

wdyt?

[forty]

@LoneRifle The fact that xml-encryption "is still womewhat maintained" is debatable :)

Vulnerabilities fix PRs are starting to pile up https://github.com/auth0/node-xml-encryption/pulls

I have just repinged the last people to have merge something there on this PR auth0/node-xml-encryption#86, we'll see if they answer 🤞

[forty]

Okay, my bad, they have answered very quickly when I pinged them directly, they seem still active then 👍

In that case it might be worth chatting with them to see their point of view.

[cjbarth]

Has there been any movement on this @forty, @LoneRifle ? I'm working on #243, but if it is possible to move to a single library, I'd much rather put my @ganesha289 effort there.

[cjbarth]

It appears that there isn't any movement in this direction. Instead, perhaps we should move functionality that is needed piece-by-piece into this library. I'd be glad to help review any PRs to that effect.