response 37 of 81:

Sep 25 22:41 UTC 2006

STeve, why does Marcus seem to think this was talked about "over, over, and
over" yet you seem to think nothing was discussed?  Which is it, gents?
I'm also amused that Marcus is talking about 1) pissing off staff and, 2)
concensus building; yet, nobody seems to agree with neither STeve or mdw on
how things are being conducted.
Black box, anybody?

response 39 of 81:

Sep 25 22:56 UTC 2006

Marcus is probably referring to conversations from several years ago.

It's interesting that Marcus seems to be against my proposal, yet his argument
almost supports it.  In particular, he speaks about how organizations as small
as grex shouldn't rely on any single individual to keep them running.  That
would imply, in cases like this, sticking as close to the standard software
distribution as possible.  It would certainly rule out things like
experimental Kerberos servers that would almost certainly require the
originator to maintain (unless someone were to invest quite a bit of effort
into it).  I'm not at all sure I followed the rest of his argument; the last
time this came up for discussion was nearly two years ago, when grex moved
to this machine.  It's hardly been under continuous debate since then.  At
the time, the decision to leave the custom hash in place was made in order
to facilitate allowing Marcus to plug in his modified KDC.  But Marcus only
logged into grex two or three times in the ensuing two years (his recent
logins seem to coincide with this discussion), and given how the staff climate
has changed over that time, it seems reasonable to re-open the issue.

response 41 of 81:

Sep 26 03:22 UTC 2006

Nothing.  The source is BSD licensed, and at least in the
opinion of the author, is a mathematical algorithm that embodies
no novel, unique, or unbvious principles.

response 43 of 81:

Sep 26 17:38 UTC 2006

re #42
 I'm astonished that anyone would feel strongly enough about it
 to want to change it or even discuss it very much.
I'm kinda the opposite.  I'm surprised people are upset that it was suggested
and brought up as a possible "update" when the argument in favor was fairly
concise and makes sense.  Standards are not evil.  If someone has the time
to standardize bits of the system and nobody gets injured or denied system
access then what is the harm?  I'd rather see the staff foster a relationship
of interest and improvement rather than one that harbors distrust while
embracing a stagnant mindset.

response 45 of 81:

Sep 26 18:18 UTC 2006

Eventually, there could be a compromise somewhere that allows for system
improvements to be formal.  Ideally, these improvements would be the kind that
are not denied unless proof of obvious DoS or degradation occurs as a result.
Will that happen on Grex? I seriously doubt it.

response 47 of 81:

Sep 26 23:44 UTC 2006

Patch management is one of those things where if it isn't obvious whether
you're updates are improvements then you should do a risk assessment.  I'd
venture to guess that staying on older or non-standard modules would be a
higher risk.

response 49 of 81:

Sep 27 14:23 UTC 2006

At the board meeting last night Marcus suggested that the sensible time
to start a transition to a standard password algorithm would be in the
course of the next upgrade to a new version of OpenBSD.  (He was not
exactly advocating such a change, but he wasn't opposing it either, just
suggesting the best way to do it.)

I think that makes sense.  You really want to have the system off-line
while you do this, so you can confirm that new and old passwords are
working right before letting users loose on them.  During the system
upgrade is a period when we will be working on the password system
anyway.  The change is absolutely non-urgent, so I don't see much reason
to do it before then.  Why impose extra down time over this?

So I guess that's what I'm advocating at this point.  During the next OS
version upgrade, we install the patches to enable authenticating with
Marcus's passwords, but have new passwords be created with a standard
hash.  By the time of the upgrade after that, we should be able to drop
the Marcus stuff entirely and use a stock authentication system.

When is the next OS upgrade due anyway?  We are on 3.8 now.  Looks like
4.0 is about to be released.  But it doesn't look to me like 4.0 is a
major step.  It looks more like 4.0 was the next number after 3.9.  I
don't know.  Looks like we are getting into the time range where an OS
upgrade would be reasonable to do, but not yet critical.

response 51 of 81:

Sep 27 19:35 UTC 2006

Regarding #49; I think that's sensible, though another couple of points I'd
throw out are that (a) this doesn't necessarily involve any downtime, and (b)
there's nothing that says you can't put the pieces in slowly.  For instance,
the current login code handles both OpenBSD's native password format and
grex's.  We could modify (potentially) plop in the new version of newuser at
any time with no effect on existing users at all.  Similarly, the passwd
command could be put in at any time.  The changes to wnu were just to the
Makefile (to get it to link against some the stuff I added to newuser to
support the OpenBSD hash format).  That could be done at any time.  A
potential plan could be to pick the least frequently used of these commands,
put it in, watch for trouble for a few weeks, move in the next
least-frequently used command, watch for trouble, etc.  The slight advantage
over doing it all during an upgrade is that *if* there's a problem and the
changes need to be backed out (and it's not discovered during the upgrade
itself) you aren't stuck backing everything out at the same time.

I also agree with Todd that it's not *so* risky as to be undoable before the
next upgrade.

I'd champion the middle ground, piecemeal approach, so that it could be backed
out at the first sign of trouble.

response 53 of 81:

Sep 27 22:10 UTC 2006

It's up to them to prove you wrong.

response 55 of 81:

Sep 27 22:40 UTC 2006

You lost me, coach.

response 57 of 81:

Oct 2 23:08 UTC 2006

They don't; I think password expiration got turned off with the move to
OpenBSD on the i386.

response 59 of 81:

Oct 7 20:26 UTC 2006

It goes into the Grex Process, where people talk it to death until
everyone loses interest, and eventually it's let slide unless some kind
of disaster happens.  This is very similar to the Seattle Process, which
is how transportation issues are managed here in the Pacific Northwest.

response 61 of 81:

Oct 7 21:04 UTC 2006

re #59
The light rail is on track but I know what you mean if you're referring to
the viaduct.