[20824] in Athena Bugs
Re: clearcerts vs. clear-netscape-password, etc.
daemon@ATHENA.MIT.EDU (John Hawkinson)
Thu Sep 26 19:49:03 2002
Date: Thu, 26 Sep 2002 19:47:14 -0400
From: John Hawkinson <jhawk@MIT.EDU>
To: "t. belton" <tbelton@MIT.EDU>, Camilla R Fox <cfox@MIT.EDU>
Cc: bug-infoagents@MIT.EDU, web-agents@MIT.EDU, netscape-release@MIT.EDU
Message-ID: <20020926234714.GA22408@coleco-sidewinder.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200209262125.RAA08665@red-herring.mit.edu> <Pine.GSO.4.33L.0209261623330.23121-100000@iphigenia.mit.edu>
t. belton <tbelton@MIT.EDU> wrote on Thu, 26 Sep 2002 at 16:55:04 -0400
in <Pine.GSO.4.33L.0209261623330.23121-100000@iphigenia.mit.edu>:
> From: "t. belton" <tbelton@MIT.EDU>
> > Well, the scope certainly has increased. Is that really necessary,
> > particulary to include netscape-release on issues specific to
> > Athena?
>
> I added those lists because I wanted people to see my explanation of what
> the scripts do - just as I am keeping them now because I want them to see
> this rant.
OK. Perhaps I'm under a misimpression, but I thought that "netscape-release" is
"People who worry about qualifying versions of Netscape for Windows/Mac, and
who like to be certain that Athena is running something that's generally
compatible, but do not care about minutiae like how Athena consultants support
small problems that are specific to the Athena version." Under that impression,
it would seem to me that perhaps netscape-release deserves occasional status
updates of The Big Picture, or Important Pieces of the Small Picture, but
probably does not want to be cc'd on a lengthy discussion about How Athena
Should Deal with a particular issue.
[ Uhoh. I can see from that paragraph that this message is going to be too
long-winded. ]
> I have noticed in the last few days that my information on
> Mozilla issues is not trickling down properly to the people who actually
> provide help to users.
Yup. Let's hash it out here.
First, I should clarify that you'll necessarily have to worry about Athena
issues seperately from other "Netscape Release" issues, and that the
information dissemination hierarchy for Athena is going to be a bit
different. (Perhaps that was obvious, but I'm trying to avoid confusion).
Camilla R Fox <cfox@MIT.EDU> wrote on Thu, 26 Sep 2002
at 17:25:37 -0400 in <200209262125.RAA08665@red-herring.mit.edu>:
| cfyi is the consultant's FYI list. People doing Athena support (OLC,
...
| olc-stock is the appropriate place for submissions to the OLC Stock
...
| software-announce is appropriate for announcements of newly available
That's a good overall summary of the important lists.
Whenever you make a large-scale change that you think "power users" will care
about, and you think support folks will care about, that has to go to
software-announce. Example: "Mozilla 1.1 is installed in infoagents."
Whenever you're planning a large-scale change, or making a small tweak
that affects support folks, cfyi is the right place. Yes, it's
somewhat constrained to OLC Consultants, but "everyone who does
support in the Athena environment" knows they need to read it (also,
don't be mislead by the set of folks on it, it is read by many in
discuss, and often important messages that go there are forwarded to
other lists as appropraite). Examples: "We're planning to install
Mozilla 0.1 next week," "We're going to change the default Mozilla to
1.1 in two weeks," "Please use the ``clearcerts'' command under these
circumstances..."
olc-stock is somewhat more of an internal list that I don't think should
have to worry about, unless you're actively reviewing the OLC stock answers
(great if you have time, but really the consultants' job), or you know
something is going to be a stock question/answer, and want to give it
a heads up. In keeping with your concern about having too many lists
to worry about, olc-stock should be the first one you forget.
It's probably appropriate to copy web-agents on _all_ of these kinds of
messages, since that's basically the "infoagents locker maintainers list," aka
"who would inherit when you get run over by a truck."
As for the BLT and the Helpdesk, they don't deal with the Athena netscape
at all, so for these kinds of changes, I don't think they need any notice.
[Now's the time for BLT/HD people to pop up and say I'm on crack.]
> I don't generally want to send to a lot of lists because I don't want to
> be spamming right and left with browser information. What I would LIKE is
> to be able to tell one person that represents each group with a need to
> know, and have that person tell the group. But this has not worked.
This would be fine if you had a list of who those people were and
you and they both concurred that they were the contact points. But you
don't have that, so let's get it straight.
> I think, therefore, it is the wrong idea to expect me to be able to
> broadcast Mozilla information to everyone on all those lists who need it,
Unfortunately, I think it's pretty clear that your perception is inaccurate. I
fully agree with cfox when she says:
| Well, it's not too hard for the maintainers of other software.
| That Mozilla touches a lot of people's lives increases your obligation
| to send announcements, rather than decreasing it.
Furthermore, the increased burden on you is very light. Despite the
fact that I just did it today (asked why netscape-release was cc'd), I don't
think that many people are going to ever going to complain if you hand
out too much information. At least not Athena-people. So put this fear
to rest.
> In the case of 'clear-netscape-password,' if you're right, jhawk, then OLC
> is propagating incorrect and outdated information. The script hasn't been
> named that for - I don't know, considerably more than a year - and it is
> not something I would just tell people to run casually in any event.
That's one way to look at it, but the other side of the coin is,
"the script is named that and that's what people are using."
Regardless of what was intended, that's in fact the current state
and breaking it is undesirable.
> This renaming discussion did not take place in a vacuum! It was not my
> unilateral decision; in fact, it wasn't even my idea. Various people
> participated, among them people whom I expected to update docs and pass
> the word along. Remember, I don't maintain any OLC docs and I can't change
> them directly. In fact, if I recall correctly, you were an onlooker and
> may even have been an instigator in the decision to rename it to
> 'zap-certificates' so that its destructive behavior would be more clear.
> Where did this information get lost? We DID a name transition. We DID an
> announcement. Or at least I thought we did at the time. This should be old
> news!
Well, my recollection is somewhat different. I thought we agreed that
"zap-certificates" was a better name, but we did not agree that the old
name would ever go away. I expected we would pertpetuate both names
well into the next decade.
The reality is that it's your responsibility, as the person making the
change, to make sure that all relevent groups have CONFIRMED that they
are on board with your changes before you desupport an old version. So
talking about it is not sufficient. In reality, the only group whose
documentation is really important is OLC; other documentation is derived
from that, and probably not a showstopper (or something like that).
> Certificates are disposable, but if a user doesn't realize they'll have to
> get more after using this script, that's a problem, because then they'll
> be annoyed.
True, but I think it's a small problem. Users already know how to get
certificates again. Any certificate-using web site tells them how to do it,
and since certificates expire at regular intervals and users use multiple
(non-Athena) machines, they get used to it...
> And other data - notably mail - can be encrypted with the cert
> password such that if the cert is lost, all that mail is lost too.
> That IS destructive. At the very least a live human should be
> warning users what to expect before they run it.
Here we come to a tricky judgement call. Almost nobody uses certificates in
this way (or uses non-MIT personal certificates). I have never seen anyone warn
a user that this might happen, and only infrequently do I see anyone bother to
ask if a user has non-MIT certificates. I've never seen an answer of "Yes." I
myself am "guilty" of this practice too.
I'm not sure what to do about it. I'm tempted to say "This risk is so
small we should ignore it completely." On another level, I'm tempted
to say, "OK, we should modify Mozilla so it is very hard to use
the master password to encrypt anything."
[ And before we go off concerned about security, I'll point out that most
users just use their Kerberos password to as their Master Password. Too
bad we don't have a good kerberized encryption mechanism to throw in
and just get rid of the password. ]
Anyhow, I'm sure the latter won't fly. I doubt you'll succeed in educating
the support community to pretend that there is a real risk of a problem
when in fact no one actually has it.
I think the best you can do is ensure that "clearcerts" and/or
"zap-certificates" contain all the warnings you are concerned about,
and possibly a "type YES if you really want this" section. This
acknowledges that you're never going to convince the support
infrastructure to pass on the warning with the force you seem to
desire...
| I think hitting cfyi with all your announcements and links will accomplish
| a lot of what's needed. People on there have the power to update stock
| answers, etc.
Concurrance.
I hope I don't come off as too harsh. Let me know if it seems that way.
--jhawk
