Currently, all a user needs to do to use commons-crypto is to include it as
a dependency in an application that runs on a supported operating system
with a supported version of OpenSSL (1.0 and 1.1). Commons-crypto
dynamically, and IMO quite elegantly, determines the underlying OS and
OpenSSL
On Tue, 14 Jun 2022 at 16:26, Gary Gregory wrote:
>
> Hi All,
>
> The component name was indeed ill chosen for what is effectively an
> OpenSSL wrapper. Maybe we could make that obvious on the site by
> calling the page "Apache Commons Crypto, an OpenSSL wrapper".
>
> I am in favor of adding more
Yes it has. The current issue is that if a component does not use the
latest Apache RAT plugins, then it must do so in its POM. This could be
handled automatically if we released a new commons-parent.
Gary
On Tue, Jun 14, 2022, 15:42 Matt Sicker wrote:
> The issue with the previous RC required
The issue with the previous RC required an updated version of the Commons
release plugin. I don’t remember if that’s been done yet.
—
Matt Sicker
> On Jun 14, 2022, at 05:12, Alex Herbert wrote:
>
> On Mon, 13 Jun 2022 at 17:46, Matt Sicker wrote:
>
>> I haven’t had a chance to try a
Hello.
Le mar. 14 juin 2022 à 17:21, Gary Gregory a écrit :
>
> That would make it pretty painful for users IMO
The price to pay for playing outside the FLOSS ecosystem.
> and we'd need to make
> sure users are pointed to a "safe" and authentic place to get the
> binaries in addition to the
Since we're talking about exposing new functionality, there's been a major
new OpenSSL release since our last release, so we should probably discuss
putting support for it on our roadmap, along with exposing
additional APIs. I'd like to add support for Blake2 in the next release,
and I'm happy to
Hi All,
The component name was indeed ill chosen for what is effectively an
OpenSSL wrapper. Maybe we could make that obvious on the site by
calling the page "Apache Commons Crypto, an OpenSSL wrapper".
I am in favor of adding more Java methods to wrap more OpenSSL APIs as
PR #165 does, that
That would make it pretty painful for users IMO and we'd need to make
sure users are pointed to a "safe" and authentic place to get the
binaries in addition to the jars.
We can leave it up to the RM as to what to do on a per release basis I
suppose, but I would not like us to build code and extra
Le mar. 14 juin 2022 à 16:38, Alex Remily a écrit :
>
> As a user and past contributor, my view of Commons Crypto is that it is a
> Java wrapper around certain common features of OpenSSL, full stop.
Maybe the mistake was in the name (?).
> As
> such, it provides near-native performance to the
As a user and past contributor, my view of Commons Crypto is that it is a
Java wrapper around certain common features of OpenSSL, full stop. As
such, it provides near-native performance to the Java developer for
processor-intensive operations via a Java API. It is a set of tools for
developing
On Tue, Jun 14, 2022 at 3:08 PM Gilles Sadowski wrote:
> Is it a Java wrapper around a specific library ("openssl")?
> Is it a set of tools (a.o. strong random number generators) for developing
> cryptographic applications in Java?
> Is it both? Does it intend to be more?
>
> In order to
Hello.
Given the trouble it entails and the very few people who can or want
to be involved in (the maintenance of) cross-compilation, wouldn't it
be safer to make all binaries optional?
It would be the application developers' responsibility to drop them to
a location where the [Crypto] wrapper
Hello.
Contradicting comments about the latest contribution offer[1] suggest
that the scope of the [Crypto] component is ill-defined.
Is it a Java wrapper around a specific library ("openssl")?
Is it a set of tools (a.o. strong random number generators) for developing
cryptographic applications
On Mon, 13 Jun 2022 at 17:46, Matt Sicker wrote:
> I haven’t had a chance to try a second RC. I’ve been out sick the past few
> days as well. If you’d like to help make the release, let me know!
>
I asked the question as a contributor asked after their PR bug fix was
merged. IIRC the previous
14 matches
Mail list logo
