> MIT opened TR-404234 and defect 9998 with patches to add support to
> the client and a flag to fs to enable encryption. Somehow this
> TR/defect got closed (as we noticed last week during periodic
> open-TR review), and we're not sure yet under what conditions that
> happened. This patch was a modification of the CMU patch (fixed some
> stuff).
Well, here's the justification Transarc gave for rejecting the defect:
To begin with, this is an extremely customer-specific fix that
we do not feel would benefit the customer-base at large.
Security issues of this type need thorough testing, which
development considers to be non-trivial. The documentation
impact will also be significant as it will be necessary to
adequately warn customers of the potential problems with such
a change. Finally, as mentioned previously, the user
interface as it stands now is not the most user-friendly
component of the product and we do not want to add more
options to commands unless there is a strong need to do so.
We do not feel that is the case here.
As far as I can tell, there is nothing customer-specific about the
patch I sent them. It fixes the level problem with the cryptall flag,
adds VIOC_{GET,SET}RXKCRYPT pioctls, and adds an "fs crypt" command to
invoke those pioctls. If other sites would like to see client support
for requesting encryption, they might consider contacting afshelp and
referencing defect 9998.
(So far MIT has not done any load testing, and it's possible that
making it easy for client machines to request encryption would be a
mistake for that reason. I don't buy any of the other arguments
given, though.)
