Split CLI for managed and unmanaged trust anchor modes

Original interface with single -k option whose behavior depended on file permissions was confusing.

Closes #145 (closed): Added two separate command line argument for keyfile for managed and unmanaged mode. Removed setting based on folder and file permission.

Closes #168 (closed): Added makefile variable KEYFILE_DEFAULT to specify default keyfile, which is used when no other keyfile is specified. This is mainly useful for distributions which skip root keys.

changed milestone to %1.4.0

added ~402 label

added 1 commit

• cac63b1b - default keyfile set in Lua code

Compare with previous version

resolved all discussions

unmarked as a Work In Progress

added 9 commits

• cac63b1b...3c1d9d6e - 5 commits from branch master
• 4b716fd1 - keyfile argument distiguish managed and unmanaged mode
• 187fd7f7 - compile time option to specify default keyfile
• 4e79eb64 - default keyfile set in Lua code
• 759200b7 - keyfile: update doc, help and manpage

Compare with previous version

Actually, I'm thinking again on the naming, because it might be slightly confusing ATM. The "unmanaged" mode in our case currently really differs only in changes not being persisted in any file, but otherwise it's 5011-managed the same way. (Of course, in default settings changes need a month to apply, so without persisting the timers there probably won't be too much practical difference.)

Maybe --keyfile-readonly or --keyfile-ro. Or keep the name and change the semantics of -K to really static anchors, i.e. cmdline equivalents of http://knot-resolver.readthedocs.io/en/latest/daemon.html#c.trust_anchors.add (In docs the parameter isn't even called confusingly "unmanaged" like in code but "readonly" :-)

Oh, that is weird. I agree that "ro" option should behave as static trust anchor.

Honestly I do not see any reason to have non-persistent RFC 5011 so I'm proposing to remove it completely. Either go with full RFC 5011 and writeable file or ignore RFC 5011 and use static trust anchors.

@vcunat Thank you for bringing this up!

I see my comments within the TA code aren't sufficient to explain such things, unfortunately.

One advantage is that for completely unmanaged TAs it's very easy to support mixing multiple TA owner names within a single file – we can simply read the whole file and push the string into trust_anchors.add. (It won't guard for managed TAs overwriting those later, but I don't think that's needed.)

One possible motivation for the current state is (and was IIRC) that kresd won't attempt to re-read the file if it changes, which could affect very long running instances, as one use case is to have a read-only TA file managed by the OS packaging.