Project

General

Profile

Bug #5136

ValidatorConfig with more than one trust-anchor - Cannot create dynamic group, because group already exists

Added by Junxiao Shi about 2 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Security
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

Environment: Ubuntu 18.04 amd64, ndn-cxx 0.7.1.

x.cpp

#include <ndn-cxx/face.hpp>
#include <ndn-cxx/security/validator-config.hpp>

int
main()
{
  ndn::Face face;
  ndn::security::ValidatorConfig validator(face);
  validator.load("validator.info");
  return 0;
}

validator.info

trust-anchor {
  type file
  file-name A.ndncert
}
trust-anchor {
  type file
  file-name B.ndncert
}

Note: having more than one trust-anchor is supposed to be supported, as evidenced by examples in ndn-cxx/docs/tutorials/security-validator-config.rst and nfd.conf.sample.

Steps:

ndnsec key-gen /A > A.ndncert
ndnsec key-gen /B > B.ndncert
g++ -std=c++14 -g -o x x.cpp $(pkg-config --cflags --libs libndn-cxx)
./x

Expected: no error

Actual: program crashes

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<ndn::security::v2::TrustAnchorContainer::Error> >'
  what():  Cannot create dynamic group, because group validator.info already exists
Aborted (core dumped)

Stack trace:

(gdb) bt
#0  0x00007ffff6da4fb7 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6da6921 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff73fb957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff7401ae6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff7401b21 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff7401d54 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7c19627 in ndn::security::v2::TrustAnchorContainer::insert (this=this@entry=0x7fffffffdf98, groupId="validator.info", path=..., refreshPeriod=..., 
    isDir=isDir@entry=false) at ../ndn-cxx/security/trust-anchor-container.cpp:68
#7  0x00007ffff7b9860e in ndn::security::v2::CertificateStorage::loadAnchor (this=this@entry=0x7fffffffdf90, groupId="validator.info", 
    certfilePath="/home/vagrant/B.ndncert", refreshPeriod=..., isDir=isDir@entry=false) at ../ndn-cxx/security/certificate-storage.cpp:64
#8  0x00007ffff7c5d7f9 in ndn::security::v2::Validator::loadAnchor (this=this@entry=0x7fffffffdf90, groupId="validator.info", 
    certfilePath="/home/vagrant/B.ndncert", refreshPeriod=..., refreshPeriod@entry=..., isDir=isDir@entry=false) at ../ndn-cxx/security/validator.cpp:198
#9  0x00007ffff7c2e8bc in ndn::security::v2::validator_config::ValidationPolicyConfig::processConfigTrustAnchor (this=this@entry=0x555555793310, configSection=..., 
    filename="validator.info") at ../ndn-cxx/security/validation-policy-config.cpp:138
#10 0x00007ffff7c30786 in ndn::security::v2::validator_config::ValidationPolicyConfig::load (this=this@entry=0x555555793310, configSection=..., 
    filename="validator.info") at ../ndn-cxx/security/validation-policy-config.cpp:100
#11 0x00007ffff7c30e96 in ndn::security::v2::validator_config::ValidationPolicyConfig::load (this=this@entry=0x555555793310, input=..., filename="validator.info")
    at ../ndn-cxx/security/validation-policy-config.cpp:66
#12 0x00007ffff7c314b7 in ndn::security::v2::validator_config::ValidationPolicyConfig::load (this=0x555555793310, filename="validator.info")
    at ../ndn-cxx/security/validation-policy-config.cpp:45
#13 0x0000555555559b88 in main () at x.cpp:11
#1

Updated by Varun Patil about 2 months ago

This happens because we use the config filename for the groupId (I guess this was unintentional; the variables are named filename and file). A patch I submitted changes this to use the certificate name instead, but this brings another problem - if two files refer to the same certificate, then it will throw. Maybe we should use a concatenation of the two filenames?

Also the dir type suffers from the latter problem already.

#2

Updated by Junxiao Shi about 2 months ago

I don't know what groupId is, but if a unique identifier is needed, you can use a counter or a GUID.

#3

Updated by Davide Pesavento about 2 months ago

  • Status changed from New to Code review
  • Assignee set to Varun Patil
#4

Updated by Varun Patil about 2 months ago

Junxiao Shi wrote in #note-2:

I don't know what groupId is, but if a unique identifier is needed, you can use a counter or a GUID.

For dir we're using the directory of the certificate as given in the config file, but I think a better solution (separate issue) would be to use a canonical path to the dir/file with the cert (as Davide suggested).

I don't see the issue if a certificate is loaded twice though, so idk if it's a big deal.

#5

Updated by Davide Pesavento about 2 months ago

  • Status changed from Code review to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF