NFD

https://gerrit.named-data.net/3898 patchset2 disables timestamp checking in nfd::CommandAuthenticator so that unit testing can pass.
This is a temporary solution until ndn-cxx can provide a suitable validator.

NFD can still run, and local ndnping + ndnpingserver works. However, prefix registration via /localhop/nfd command prefix probably will not work because it relies on v1 validator.

Mgmt/TestCommandAuthenticator/BadKeyLocator_BadCertName test case is deleted because KeyLocator carries key name in v2 so a transformation step from unversioned certificate name to key name is unnecessary. It is processed in the same way as NotAuthorized test case.

https://gerrit.named-data.net/3914 ndncert

Junxiao Shi wrote:

The custom policy also stores KeyLocatorName as a packet tag on the "original Interest"; tag type 20 will be reserved in PacketTagTypes once we agree with this design.

Please explain why this tag is needed.

Many test cases were using KeyChain::sign to create command Interests, but KeyChain::sign only creates signed Interests in v2. https://gerrit.named-data.net/3976 changes them to be signed by CommandInterestSigner via CommandInterestSignerFixture.

Regarding SignerTag in CommandAuthenticator: This tag allows the authentication function to obtain the signer name without calling getKeyLocatorName again. The signer name needs to be passed to AcceptContinuation, and can also enhance logging messages.
It's inefficient to call getKeyLocatorName again, and it's also non-trivial to do so because getKeyLocatorName requires ValidationState which is not intended for use outside of Validator.

Junxiao Shi wrote:

Regarding SignerTag in CommandAuthenticator: This tag allows the authentication function to obtain the signer name without calling getKeyLocatorName again. The signer name needs to be passed to AcceptContinuation, and can also enhance logging messages.
It's inefficient to call getKeyLocatorName again, and it's also non-trivial to do so because getKeyLocatorName requires ValidationState which is not intended for use outside of Validator.

Understood, thanks. And why can't the signer name be passed around as a regular function argument when needed?

why can't the signer name be passed around as a regular function argument when needed?

Validator API does not have a mechanism for a policy to directly communicate with calling code.
Both the policy and the calling code are reused across multiple packets, so std::bind is not an option.
Changing that API is out of scope of this issue.

https://gerrit.named-data.net/3974 patchset6 fixes a potential memory error when config reload occurs during validation.
As Zhiyi answered on ndn-lib, if Validator is destructed during validation, it would trigger undefined behavior in current version, and would cause validation to fail in a future revision.
The Validator may be destructed if config reload occurs.
To solve this problem, CommandAuthenticator retains the validator through shared_ptr during validation.

This situation is untestable at this moment because all validation policies used by CommandAuthenticator complete synchronously.
However, CommandAuthenticator cannot rely on such undocumented synchronous completion, and thus needs to use shared_ptr.

Junxiao Shi wrote:

This situation is untestable at this moment because all validation policies used by CommandAuthenticator complete synchronously.

Can you create a dummy async policy for unit test purposes?

This situation is untestable at this moment because all validation policies used by CommandAuthenticator complete synchronously.

Can you create a dummy async policy for unit test purposes?

No. CommandAuthenticator manages the policies internally. There is no external control on what policies are used.

https://gerrit.named-data.net/4059 v2::ValidatorNull in ndncatchunks.

https://gerrit.named-data.net/4060 ValidatorNull in nfdc. This commit is intended for a quick fix.
"nfdid" is unavailable. I'll re-implement NfdIdCollector as a ValidationPolicy in another commit.