NFD » ndn-cxx

/** \brief Unpublish certificate bundle upon destruction.
*/
class ScopedCertBundleHandle;

Is there an example of how I would implemented this?

// The CertBundleBuilder can collect intermediate certificates from the local KeyChain, caches in a
// CertificateStorage, or the network via a fetcher.

Does this mean the builder can search through all three for the same certificate if they were set by the application?

/** \brief Emitted when state has changed.
*/
signal::Signal& afterStateChange;
// CertBundleHandle type must be copyable. Thus, this signal must live elsewhere
// (e.g. an internal struct owned by CertBundleBuilder) and only a reference is stored.

I'm also not sure how this should work. According to the documentation, only the owner of a signal can emit it. (https://github.com/named-data/ndn-cxx/blob/master/ndn-cxx/util/signal/signal.hpp#L46).
Why must the handle be copyable?

I can house the signal in the Handle class and have the builder possess a shared pointer to the handle instead. Is there an issue with this implementation?

// The CertBundleBuilder can collect intermediate certificates from the local KeyChain, caches in a
// CertificateStorage, or the network via a fetcher.

Does this mean the builder can search through all three for the same certificate if they were set by the application?

Yes.

Why must the handle be copyable?

It simplifies calling code, and allows CertBundleBuilder to control lifetime of the handle.

You can have CertBundleHandle hold a weak pointer to some internal structure, and forward every function call to methods on that internal structure. The CertBundleBuilder is the only entity that has a shared pointer to that internal structure.

\brief Enable retrieving certificates using a CertificateFetcher.
\pre setStorage has been invoked.

void
setFetcher(CertificateFetcher& fetcher);

Could you give a brief overview of how the CertBundleBuilder would use the CertificateFetcher? From what I understand, the CertificateFetcher requires a Validator. Specifically, the fetch function needs to be passed ValidationContinuation and ValidationState in addition to a CertificateRequest.

the CertificateFetcher requires a Validator.

CertificateFetcher is normally used in the context of a Validator, but it does not require a Validator.

the fetch function needs to be passed ValidationContinuation and ValidationState in addition to a CertificateRequest.

Pass a callback function as ValidationContinuation, to receive the certificate that has been retrieved.
Make a subclass of ValidationState, and override its fail method, to get notified when certificate retrieval has failed.

/** \brief Unpublish certificate bundle upon destruction.
*/
class ScopedCertBundleHandle;

Could you explain how this class works a little more? What exactly does "unpublish" mean here? Just deleting the CertBundleHandle? What else needs to be done?

Destructor of ScopedCertBundleHandle invokes CertBundleHandle::cancel(). Both function would set the state of CertBundleHandle to UNPUBLISHED.
Depending on where a certificate bundle is published, this triggers the following actions:

• CertBundleImsInserter(wantDelete=false) does nothing.
• CertBundleImsInserter(wantDelete=true) deletes Data packets associated with the certificate bundle from the IMS.
• CertBundleProducer stops responding to Interests with Data packets associated with the certificate bundle, and unregisters the prefix if it's not needed from any other published Data.
• CertBundleRepongInserter(wantDelete=false) does nothing.
• CertBundleRepongInserter(wantDelete=true) deletes Data packets associated with the certificate bundle from the repo.

Regarding CertBundleRepongInserter: please hold off on implementing this class. ndn-python-repo is being designed to replace repo-ng software, and it uses a different protocol.
CertBundleRepongInserter will be replaced with CertBundlePyRepoInserter, once ndn-python-repo resolves their protocol issues.
API design of CertBundleRepongInserter is directly adoptable to CertBundlePyRepoInserter.

Should the CertBundleBuilder maintain the CertBundleHandles returned by add internally at all?

Should the CertBundleBuilder maintain the CertBundleHandles returned by add internally at all?

CertBundleHandle is a copyable handle. Each handle has a weak pointer to some internal object that reflects the publishing state of the CertBundle. Every copy of CertBundleHandle points to the same internal object.
The only shared pointer of that internal object is owned by CertBundleBuilder, and is deleted when the CertBundle is unpublished.
When CertBundleHandle finds its weak pointer becomes empty, its state becomes UNPUBLISHED, and its cancel() method becomes a no-op.

How do you define failure to build a cert bundle? I was thinking that the builder would publish the certs it successfully found even it wasn't able to reach a self-signed certificate. So the only failure would be if it was unable to get a the first certificate in the chain. But now that I'm working on the fetcher, I'm not sure this is the case.

How do you define failure to build a cert bundle?

A producer is responsible to provide the entire certificate chain needed to verify their Data. Therefore, the bundle should contain every intermediate certificate.

I was thinking that the builder would publish the certs it successfully found even it wasn't able to reach a self-signed certificate.

This could be a best effort bundle creation mode, but the full bundle mode (collect every intermediate certificate) must be supported.

If you want to support this mode, add a CertBundleBuilder constructor parameter.
The mode should be defined as an enum, not a boolean, to improve readability.
Default value is up to you.