Re: [9fans] factotum & invalid entries

[Russ Cox <russcox@gmail.com>]

In response to the flood of messages in this thread:

- I decided against silently deleting keys.  It would be very
  confusing if keys just magically disappeared.  I like the
  disabled=by.factotum tag a lot better.  I didn't use the log
  file mainly because it's intended only for debugging messages.
  I wouldn't think to look there to figure out why a key disappeared.

- Adding disabled=by.factotum only changes whether
  factotum uses the key in authentications.  It doesn't
  change whether you can see the password.  You never can.
  That's the whole point of factotum.  Except in proto=pass,
  which exists to break the rule.

- Factotum has a precise semantics for disambiguating key
  selection: use the first one.  That said, there is nothing stopping
  you from adding your own tags and then using the -k flag to
  mount to resolve the ambiguity some other way.  This has
  been there since day 1.

- If you've developed a habit of deleting bad keys to avoid the
  original problem that was reported, you can drop the habit.

- When you add a new key with the ctl file, here is what happens.
  If there is already a key in factotum with exactly the same set
  of public attr=val pairs, that key is replaced with the new one
  and stays at the same place in the list.  Otherwise, the new key
  is appended to the list.  When doing this comparison, the role=
  and disabled= attributes are ignored.  This means that if you have
  a key like:

    key proto=p9sk1 dom=foo user=bar !password? disabled=by.factotum

  and you write a new

    key proto=p9sk1 dom=foo user=bar !password=quux

  to the ctl file, then the first key is replaced by the second.  But
if the first
  had an attribute baz=1 that the second did not, or vice versa, then
  the new key would just be added to the list.

There's a lot of incorrect speculation flying around about what
factotum might or might not be doing.  When in doubt, try it.

Russ