[Nfd-dev] ndn-cxx Bug 4808

[Junxiao Shi]

Hi Alex

The existence of every line of code requires a failing test. What test
prevents one from writing "return 0;" or "static uint32_t i; return i++;"
as the random number generator function?
https://gerrit.named-data.net/5134 has fixed the test such that its failure
rate is less than 0.01%. I see no reason rejecting it.

There are tests that checks that the encryption/decryption can accept a
hard-coded ciphertext, and that the SHA256 digest equals a value specified
in the standard.
https://github.com/named-data/ndn-cxx/blob/c53df03ff33bcfc59d6630b6f8aaa9e3d5eaada9/tests/unit/security/transform/private-key.t.cpp#L292-L316
https://github.com/named-data/ndn-cxx/blob/c53df03ff33bcfc59d6630b6f8aaa9e3d5eaada9/tests/unit/security/transform/digest-filter.t.cpp#L59-L64

Yours, Junxiao

On Mon, Jan 21, 2019 at 3:31 PM Alex Afanasyev <aa at cs.fiu.edu> wrote:

> Such a test does not really belong to our library.  Yes, we need to know
> that random generator on a platform behaves correctly, but given that we
> are using a 3rd party library for that (and ndn-cxx is merely a convenience
> interface to openssl), we are relying on a 3rd party to do the job
> correctly.   If we extend this "disagreement" further, we can have a tons
> of other ridiculous tests:  that encrypted value is indeed encrypted and
> cannot be decoded; that signature cannot be easily cracked; that SHA256
> digest has proper entropy properties; and so on and so forth.   So far, the
> test we had "in a soft" state had no meaning and even if "fixed" would have
> little meaning (there is nothing we can change, really); the failed hard
> test only hinders other meaningful checks.
>
> --
> Alex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20190121/181af3ad/attachment.html>