Without going into detail on the encryption and the way is can be
implemented (that would for me be to really enter thin ice ;-) i just
wanted to express support for your request.
I for one would surely appreceate the ability to easily switch on and
off encryption for a client, or even better; for/by a specific user at a
specific time. [Being located outside the US, I also need to rase a flag
for the need to make the crypt functionality usable in an international
AFS version as well].
When were these mails exchanged, when were your request rejected?
We are all aware of the change in attitude to changes of AFS and the
outspoken intent from Transarc to _improve_ AFS. I guess what I'm trying
to say is maybe this type of improvement of AFS has come in a better
light now, after the pro statement of direction for the AFS product.
The closing of this request might just have been due to lack of
resources at Transarc to improve AFS _at_all_ at the time, hence the
shallow arguments.
The customer base would benefit from an implementation of this request,
given the implementation works right. I'm for example not sure that the
crypt switch should be on a afs-client basis only. It might be a good
thing to make this switch available to you depending on who you are, i.e
you need to qualify in some way to switch on crypted transfer e.g by
being granted membership in a specifig AFS group or something. Mybe I'm
out of line here. If so, I'm sorry.
Thanks,
/peo
Greg Hudson wrote:
>
> > 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.)
--
Peo Mard
