Work work work
I'll see if I can take a look this weekend...
Gary
On Fri, May 15, 2020 at 10:19 AM Geoffrey Blake <geoffrey.w.bl...@gmail.com>
wrote:
> bump
>
> On Mon, May 11, 2020 at 10:21 AM Geoffrey Blake
> <geoffrey.w.bl...@gmail.com> wrote:
> >
> > All outstanding PR's have been merged to the repository, the code
> > coverage from coveralls looks good to me at over 80% coverage.
> >
> > There are some areas that lack coverage, such as static main functions
> > in some classes, exception paths that guard against failures coming
> > from the crypto library, internal functions that are not used by the
> > current implementation, and checking for missing native libraries
> > again in places that are guarded from being hit higher up in the class
> > hierarchy. Are there good reasons to push for more coverage for
> > these cases? i.e. remove the dead code?
> >
> > Otherwise, can we move forward with getting a new release? Marcelo
> > merged some build system fixes that should allow us to now collect
> > artifacts from the various platforms to one primary build machine for
> > Gary to do the final release.
> >
> > -Geoff
> >
> > On Tue, Apr 28, 2020 at 9:31 AM Geoffrey Blake
> > <geoffrey.w.bl...@gmail.com> wrote:
> > >
> > > I see now, you are correct Alex. My confusion is stemming partly from
> > > my lack of familiarity with Java (I touch Java code once every few
> > > years), and not having the API in my head. You can get to
> > > OpenSslJnaCipher in that way. It really should be included in
> > > CryptoCipherFactory.CipherProvider as the middle option in the
> > > fallback list. Currently that enum only exposes JNI and JCE if you
> > > don't explicitly override those with a properly set Properties
> > > structure.
> > >
> > > I feel the support for LibreSSL in commons-crypto is fine as is.
> > > Using CryptoCipherFactory.getCryptoCipher() will work and pass back
> > > the supported engine as expected, JNA support gets disabled as
> > > expected. I don't think JNA is critical.
> > >
> > > -Geoff
> > >
> > > On Mon, Apr 27, 2020 at 8:11 PM Alex Remily <alex.rem...@gmail.com>
> wrote:
> > > >
> > > > So I did a little homework and JNA appears to be a first class
> citizen
> > > > in Commons Crypto. One instantiates a JNA-backed CryptoCipher just
> as
> > > > one does JNI or JCE. The OpenSslJna class is exposed for that
> > > > purpose. I hacked together the below from some JNA test classes to
> > > > demonstrate and it runs successfully to completion as a stand alone
> > > > program.
> > > >
> > > > I think we're back to asking the question of whether or not to
> support
> > > > LibreSSL. I know that Commons Crypto fully supports OpenSSL on a Mac
> > > > because that is my primary development environment. I also
> understand
> > > > the convenience argument and I know it's a PITA to install OpenSSL
> > > > manually on a Mac, especially a new one. Nevertheless, this build is
> > > > already complex in large part because of the native interface, so
> > > > adding yet another native binary to the support list is going to
> > > > exacerbate the situation. Maybe we put it on the roadmap as a future
> > > > enhancement and see how many votes it gets.
> > > >
> > > > Thoughts?
> > > >
> > > > Alex
> > > >
> > > > public static void main(final String args[]) throws Exception {
> > > >
> > > > final String cipherClass =
> OpenSslJna.getCipherClass().getName();
> > > > Properties props = new Properties();
> > > > props.setProperty(CryptoCipherFactory.CLASSES_KEY,
> cipherClass);
> > > > String transformation = "AES/CBC/NoPadding";
> > > > final byte[] key = DatatypeConverter
> > > > .parseHexBinary("2b7e151628aed2a6abf7158809cf4f3c");
> > > > final byte[] iv = DatatypeConverter
> > > > .parseHexBinary("000102030405060708090a0b0c0d0e0f");
> > > > final byte[] inputBytes = DatatypeConverter
> > > > .parseHexBinary("6bc1bee22e409f96e93d7e117393172a");
> > > > final byte[] outputBytes = DatatypeConverter
> > > > .parseHexBinary("7649abac8119b246cee98e9b12e9197d");
> > > >
> > > > CryptoCipher enc = Utils.getCipherInstance(transformation,
> props);
> > > > enc.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > > new IvParameterSpec(iv));
> > > >
> > > > CryptoCipher dec = Utils.getCipherInstance(transformation,
> props);
> > > > dec.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key, "AES"),
> > > > new IvParameterSpec(iv));
> > > >
> > > > final int blockSize = enc.getBlockSize();
> > > > byte[] temp = new byte[inputBytes.length + blockSize];
> > > > final int n = enc.doFinal(inputBytes, 0, inputBytes.length,
> temp, 0);
> > > > final byte[] cipherText = new byte[n];
> > > > System.arraycopy(temp, 0, cipherText, 0, n);
> > > > Assert.assertArrayEquals("byte array encryption error.",
> outputBytes,
> > > > cipherText);
> > > >
> > > > temp = new byte[cipherText.length + blockSize];
> > > > final int m = dec.doFinal(cipherText, 0, cipherText.length,
> temp, 0);
> > > > final byte[] plainText = new byte[m];
> > > > System.arraycopy(temp, 0, plainText, 0, m);
> > > > Assert.assertArrayEquals("byte array decryption error.",
> inputBytes,
> > > > plainText);
> > > > }
> > > >
> > > >
> > > > On Mon, Apr 27, 2020 at 1:14 PM Geoffrey Blake
> > > > <geoffrey.w.bl...@gmail.com> wrote:
> > > > >
> > > > > JNA is the middle ground between JNI and JCE in terms of
> performance
> > > > > is my understanding without needing any .c files to create linkage.
> > > > > The problem appears to be that there is no conditional loading and
> > > > > stubbing of functions like can be done easily in the JNI code and
> is
> > > > > why macOS throws that error, LibreSSL lacks the rdrand() function.
> > > > > Perhaps it was included as a path to get rid of the native binaries
> > > > > that have to be built for JNI? But wonder if the performance
> wasn't
> > > > > there, or the macOS failures prevented its full development?
> > > > >
> > > > > -Geoff
> > > > >
> > > > > On Mon, Apr 27, 2020 at 9:15 AM Adam Retter
> > > > > <adam.ret...@googlemail.com.invalid> wrote:
> > > > > >
> > > > > > > I think Geoff just answered this question for us.
> > > > > >
> > > > > > Yup he was quicker with his reply than me! Thanks :-)
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Adam Retter
> > > > > >
> > > > > > skype: adam.retter
> > > > > > tweet: adamretter
> > > > > > http://www.adamretter.org.uk
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
