Peter Bex

Hello Andy!

This is true.  There aren't always people online.  The channel
seems to see random flurries of activity, but usually when someone
asks something in #netbsd, an answer quickly follows (as long as
someone knows the answer).

There are a handful of channel regulars (I won't mention names)
who can be a bit abrasive.  It's unfortunate when only one of
those will respond to questions.

I haven't seen truly NSFW discussion that often.  Feel free to tell
people to take that discussion elsewhere when you notice it, though!
It's part of our responsibility as channel regulars to keep the
discussion on track, or at least within acceptable parameters.
Don't leave it to channel operators, there are only a few and we're
not always online.

Agreed.  It's part of our de facto "live and let live" policy.
Generally the atmosphere is very friendly and I always feel it's
a place where people should feel welcome.  I also think you're
doing a great job at that with your friendly personal "welcome"
messages, Andy :)

But perhaps we've been too lenient towards some people.  It's also
important that complaints are forwarded to channel operators, so
that they are aware of this and can take action.

Indeed.  It's happened in the past with agressive trolls.

Cheers,
Peter (aka sjamaan on freenode)
-- http://sjamaan.ath.cx

What's the use of that?  It won't buy you any extra protection if the
hash would be accepted as-is instead of the password.  In fact, now
you would have *two* strings (instead of one) that are accepted as
equally valid passwords.

Perhaps you can encrypt it in the cookie, to prevent casual onlookers
from discovering the password.  However, if anyone can obtain the cookie
(eg via the Firesheep plugin) they can still use that to login even if
they don't know the actual password - they can just reuse the encrypted
blob.

The session is slightly safer than storing it directly in the cookie
because one would have to break into the server rather than access
the cookie store in the client.  However, if anyone can recover the
session id, they can connect with this user's credentials as well.

I would think that's challenge-response based, but I'm not sure.  The
documentation seems to hint that it's just the password, but hashed.

Why not?  If the script lives on the server, there shouldn't be a way
for the user to recover the password even if it's put in the string.

Unfortunately, I'm not aware of any truly secure method of doing this.
Sorry!  Maybe someone else knows of a good approach.

Cheers,
Peter
-- http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
                            -- Donald Knuth

Read more »

A simple sed(1) expression should do the trick:

sed -E 's/ +/ /g' old-file > new-file

GNU sed also allows in-place editing using -i, so you can avoid
writing it to a second file.  Some seds accept a different flag
to enable extended regexps.

Cheers,
Peter
-- http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
                            -- Donald Knuth

Read more »