NFD » ndn-cxx

Cross-project links:
https://github.com/named-data/python-ndn/issues/13
https://github.com/named-data-iot/ndn-lite/issues/72

NDNts will get this feature as well.

I suspect this change is causing test failures in ndns: https://jenkins.named-data.net/job/ndns/1351/OS=Ubuntu-20.04/console
Junxiao, can you take a look please?

I'm afraid this broke ndncert too https://jenkins.named-data.net/job/ndncert/446/
Ignore the ASan errors, I think those happen only because an earlier BOOST_CHECK should have been a BOOST_REQUIRE. The real failure is just before the Asan error.

ndn-tools is also affected. Fix here: https://gerrit.named-data.net/c/ndn-tools/+/6698

...and NFD, please fix. https://github.com/yoursunny/ndn-cxx-breaks/runs/6088291933?check_suite_focus=true

Basically almost all actively used projects were broken by this change.

Btw, is there an easy way to get the identity or key name that signed a packet, regardless of what's in the KeyLocator (cert or key)? If not, we should consider adding some convenience functions such as SignatureInfo::getSigningKey() or something like that.

Davide Pesavento wrote in #note-16:

is there an easy way to get the identity or key name that signed a packet, regardless of what's in the KeyLocator (cert or key)? If not, we should consider adding some convenience functions such as SignatureInfo::getSigningKey() or something like that.

This doesn't belong in SignatureInfo.
It can be a free function: NDNgo has keychain.ToKeyName.
It can also be a method of KeyLocator type.

There's no conceptual difference between KeyLocator and SignatureInfo in this regard. And it's supposed to be a convenience function, so the fewer chained method calls to get what I want, the better (within limits of course). So SignatureInfo seems about right to me.