Fix critical bug in symlink command handling found during testing
Previously, while symlink targets were checked for the string "..", symlink
names were unchecked; this allowed symlinks to be placed outside of the
permitted areas for which the signing key is authorized and even outside of the
managed file tree, requiring only that the containing directory already exist.
The test case places a symlink directly into the top-level pub/ directory to
demonstrate the issue and confirm that it is fixed.
I consider this bug critical because while the rogue symlink can only refer to
something else at or below its own location, it could replace an existing
symlink. While I do not expect that this provides any way to crack system
security, careful misuse could certainly cause considerable nuisance, possibly
breaking the entire system if an attacker can find a symlink that is critical
for the system's operation and replace it with a dangling symlink.