The test is fixed. It's included in my PR #103, along with the revised Dockerfile.
On Thu, Aug 6, 2020 at 11:03 AM Rob Tompkins <chtom...@gmail.com> wrote: > > Precisely. That’s another technique we’ve used in rng. > > -Ropb > > > On Aug 6, 2020, at 11:01 AM, Matt Sicker <boa...@gmail.com> wrote: > > > > Or alternatively, if using random values each time, have it retry the > > test with a different value. It's typically better to use an actual > > property testing library for these types of tests anyways. One example > > library I found is https://jqwik.net/ (these types of testing > > libraries are more common in functional programming like in Scala). > > > > On Thu, 6 Aug 2020 at 09:59, Matt Sicker <boa...@gmail.com> wrote: > >> > >> Choose a seed value for the `new Random()` constructor and the tests > >> will be deterministic. > >> > >> On Thu, 6 Aug 2020 at 09:57, Rob Tompkins <chtom...@gmail.com> wrote: > >>> > >>> > >>> > >>>> On Aug 6, 2020, at 10:56 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > >>>> > >>>> This is all fine and good but how would you fix the test such that it > >>>> does > >>>> not fail randomly. PR anyone? > >>> > >>> Either static inputs for determinism, or putting a probabilistic boundary > >>> in which the solution can fall. > >>> > >>> -Rob > >>> > >>>> > >>>> Gary > >>>> > >>>> On Thu, Aug 6, 2020 at 10:54 AM Matt Sicker <boa...@gmail.com> wrote: > >>>> > >>>>> The ECC stuff I mostly learned about from various Bernstein papers > >>>>> like this one: https://cr.yp.to/newelliptic/nistecc-20160106.pdf > >>>>> > >>>>> On Thu, 6 Aug 2020 at 09:50, Rob Tompkins <chtom...@gmail.com> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Aug 6, 2020, at 10:42 AM, Matt Sicker <boa...@gmail.com> wrote: > >>>>>>> > >>>>>>> Well, for testing RNGs, I can understand using property testing, yes. > >>>>>>> It would also be useful for testing fuzzing scenarios like making sure > >>>>>>> the GCM tag is invalid for any random input data (giving a near zero > >>>>>>> probability of valid data) or that an elliptic curve implementation > >>>>>>> doesn't leak out information about points outside the curve or respond > >>>>>>> to invalid inputs improperly or things like that. > >>>>>> > >>>>>> +1 - the elliptic curve stuff I’ll have to defer to you on as I’m less > >>>>>> a > >>>>> number theorist and more of a logician. > >>>>>> > >>>>>> -Rob > >>>>>> > >>>>>>> > >>>>>>> On Thu, 6 Aug 2020 at 09:37, Rob Tompkins <chtom...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> On Aug 6, 2020, at 10:33 AM, Matt Sicker <boa...@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> Now I hope we don't have unit tests depending on non-static state > >>>>>>>>> for > >>>>>>>>> its random number generator! ;) > >>>>>>>> > >>>>>>>> We actually do have a considerable number of those in our projects > >>>>> where we use probabilistic epsilons on the output. See commons-rng. > >>>>> Note, > >>>>> Gilles is quite good at writing such tests. > >>>>>>>> > >>>>>>>> -Rob > >>>>>>>> > >>>>>>>>> I'd expect a crypto library's test > >>>>>>>>> suites to include several hard-coded known-good and known-bad > >>>>>>>>> ciphertexts with static keys/IVs similar to the test cases presented > >>>>>>>>> in their RFCs (especially since said tests are typically small > >>>>>>>>> enough > >>>>>>>>> to copy/paste the binary data fairly easily). > >>>>>>>>> > >>>>>>>>> On Thu, 6 Aug 2020 at 08:19, Gary Gregory <garydgreg...@gmail.com> > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> On Thu, Aug 6, 2020 at 8:31 AM Alex Remily <alex.rem...@gmail.com> > >>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> No problem. I'll do it when I get home tonight. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Thanks Alex! > >>>>>>>>>> > >>>>>>>>>> Gary > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On Thu, Aug 6, 2020, 8:25 AM Gary Gregory <garydgreg...@gmail.com> > >>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> Hi Alex, > >>>>>>>>>>>> > >>>>>>>>>>>> Would you mind creating that ticket with that info? > >>>>>>>>>>>> > >>>>>>>>>>>> Thank you, > >>>>>>>>>>>> Gary > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Aug 6, 2020, 08:10 Alex Remily <alex.rem...@gmail.com> > >>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> That is an intermittent issue that I haven't been able to > >>>>> reliably > >>>>>>>>>>>>> reproduce. As I recall, the test that's failing is supposed to > >>>>> fail, > >>>>>>>>>>> but > >>>>>>>>>>>>> in a different way. I think it's supposed to fail because of a > >>>>> short > >>>>>>>>>>>>> buffer but occasionally fails because of an internal error, and > >>>>> when > >>>>>>>>>>> that > >>>>>>>>>>>>> happens this test fails. I don't know when it was introduced. > >>>>> We > >>>>>>>>>>> should > >>>>>>>>>>>>> probably document it in jira and or realese notes. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Wed, Aug 5, 2020, 10:53 PM Gary Gregory < > >>>>> garydgreg...@gmail.com> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi All: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I am seeing what may be a random AEADBadTagException in > >>>>>>>>>>> GcmCipherTest? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> For example: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> [ERROR] > >>>>>>>>>>>>> > >>>>> testGcmTamperedData(org.apache.commons.crypto.cipher.GcmCipherTest) > >>>>>>>>>>>>>> Time elapsed: 0.015 s <<< ERROR! > >>>>>>>>>>>>>> 881java.lang.Exception: Unexpected exception, > >>>>>>>>>>>>>> expected<javax.crypto.AEADBadTagException> but > >>>>>>>>>>>>>> was<java.lang.InternalError> > >>>>>>>>>>>>>> 882 at > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>> org.apache.commons.crypto.cipher.GcmCipherTest.testGcmTamperedData(GcmCipherTest.java:224) > >>>>>>>>>>>>>> 883 > >>>>>>>>>>>>>> 884 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Any thoughts? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The above is from > >>>>>>>>>>>>>> > >>>>> https://travis-ci.org/github/apache/commons-crypto/jobs/715348986 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Gary > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Matt Sicker <boa...@gmail.com> > >>>>>>>>> > >>>>>>>>> --------------------------------------------------------------------- > >>>>>>>>> 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 > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> Matt Sicker <boa...@gmail.com> > >>>>>>> > >>>>>>> --------------------------------------------------------------------- > >>>>>>> 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 > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Matt Sicker <boa...@gmail.com> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> 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 > >>> > >> > >> > >> -- > >> Matt Sicker <boa...@gmail.com> > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > > > --------------------------------------------------------------------- > > 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
