[2625] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: Please strongly consider backing out the zephyr servers

daemon@ATHENA.MIT.EDU (Susan S. Minai-Azary)
Mon Mar 5 13:41:37 2001

Mime-Version: 1.0
Message-Id: <p0432040fb6c98d7b8cef@[10.0.1.29]>
In-Reply-To: <200103051607.LAA27132@multics.mit.edu>
Date: Mon, 5 Mar 2001 13:41:06 -0500
To: John Hawkinson <jhawk@mit.edu>, release-team@mit.edu, op@mit.edu
From: "Susan S. Minai-Azary" <azary@MIT.EDU>
Cc: pismere@mit.edu
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Hello to all interested parties.
I agree that the server changes need to be backed out temporarily.  I 
will be sure that the WinZephr changes are made ASAP.  It sounds like 
our customers will be impacted if we do not do this.  We should get 
this done before the Institute closes and we leave people unsupported 
and surprised.
Susan


At 11:07 AM -0500 3/5/01, John Hawkinson wrote:
>Hi,
>
>     As some of you have no doubt seen, it appears that the latest
>zephyr server deployment has broken WinZephyr. There is strong
>suspicion (from Greg) that this is because some additional security
>checks were added to the zephyr servers, and WinZephyr is not sending
>subscription messages authentically.
>
>     Garry and Greg have suggested that since WinZephyr is not
>officially supported, it is appropraite to not back those changes
>out.
>
>     I would like to strongly argue against this. There are a
>reasonable number of WinZephyr users (I don't know how to quantify it)
>who will be severely inconvenienced by WinZephyr not functioning. Many
>WinZephyr users are not particularly technically saavy (being Windows
>users) and relatively ill-equipped to deal with this sort of
>problem. There is no currently available upgrade path (i.e. WinZephyr
>release that correctly sends subscription messages authentically). The
>counterargument seems to be twofold:
>
>   a) Reverting the code re-introduces a security vulnerability with
>   respect to forging subscriptions. But this vulnerability has been with
>   us for many years, and there are no known exploits, and it seems not
>   too likely that they will pop up, soon.
>
>   b) Reverting the code will break interrealm zephyr with CMU again.
>   Interrealm zephyr with CMU is a new feature that has already been the
>   cause of much instability in our zephyr environment, and has already
>   been broken for the past few weeks anyhow. I don't think there is
>   any serious dependancy on it, whereas a number of users of Windows
>   environments at MIT (in many cases support staff and faculty as well
>   as students) will be inconvenienced by lack of WinZephyr support.
>
>
>     It seems clear to me that reverting the zephyr servers to restore
>WinZephyr support is the most customer-focussed thing that can be done.
>I would request that this be thought about and executed expeditiously,
>if at all possible. It's been broken since Saturday evening and the
>clock only moves forward.
>
>     Thanks.
>
>--jhawk
>
>p.s.: I include release-team as the relevent patches that affect this
>were checked into the Athena source tree. I'm not sure what would be
>a better place to raise this (owls?)
>p.p.s.: I don't use WinZephyr, I'm just trying to act as an advocate.


home help back first fref pref prev next nref lref last post