I drafted something at https://github.com/apache/sling-org-apache-sling-commons-crypto/pull/6. Please have a look. Konrad
> On 22. Jul 2026, at 22:17, Oliver Lietz <[email protected]> wrote: > > On Wednesday, 22 July 2026 10:29:24 CEST Konrad Windszus wrote: >> Hi, > > Hi Konrad, > >> Unfortunately Jasypt used in Commons Crypto (https://sling.apache.org/ > documentation/bundles/commons-crypto.html) is no longer maintained: >>> This library is no longer maintained, but it is kept here for historical >>> reference. A lot of effort went into it back in the day, and I wouldn't >>> want to just delete it. >> (From https://github.com/jasypt/jasypt/blob/master/README.md) >> >> Would it make sense to come up with an implementation based on the JCA >> (https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/Cry >> ptoSpec.html#ProviderArch) That way one would have the option to pick >> between different providers. The default one shipping with most JREs ("Sun >> JCE provider, >> https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProvider >> s.html#SunJCEProvider) already provides quite some algorithms. Bouncycastle >> is an alternative provider supporting even more algorithms: >> https://www.bouncycastle.org/documentation/specification_interoperability/# >> algorithms-and-key-types. > > Supporting JCA makes totally sense and AFAIR I looked into it years ago. > Let me check, if I have still some initial code somewhere. > o.a.s.commons.crypto.internal already contains support for other > implementations. > >> In the end I would like to hook this up with CACs >> (https://sling.apache.org/documentation/bundles/context-aware-configuration >> /context-aware-configuration.html) so that a property is optionally only >> stored in an encrypted fashion (right now this is always stored as plain >> text JCR property which is not suitable for secret data). > > Regards, > O. > >> WDYT? >> Konrad > > > > > >
