Re: [Apachetoolbox-devel] Re: General: logging revisited...

[Kevin J. M. Jr. <km...@WP...>]

Hey Toni,


Wednesday, July 24, 2002, 10:12:24 AM, you wrote:

>> KJMJ> granted. As said, the thing to do - imho - is to at least just
TM>   ^^^^ ?!?

This misquote is most likely due to the fact that I forwarded the message to
de...@ap..., so mutt must have thought I was the author.

TM> Yes. MD5 and SHA1 sums are a good way of suggesting that the tarball
TM> on the server hasn't been tampered with, even if it comes from
TM> evilbryansoftware.com. PGP signatures are another way of asserting
TM> that.

PGP signatures don't seem to be so prevalent, at least from my experience.
And I simply don't have enough experience with gnupg to be able to perform
this checking (though I could learn, I just haven't had the need).  As far
as SHA1, I really haven't seen that being used outside the realm of LDAP
password storage, but I'm sure it's because most people are still using MD5.

TM> Hmmm? I don't exactly understand this one, and _if_ I get the complete
TM> tarball, this _is_ from evilbryansoftware.com, or rather,
TM> apachetoolbox.com. But that's not a fundamental difference in the
TM> way it works, or could work.

The point I was trying to make is that if the package on his server were not
the same, but something he patched, then repackaged, and then conned people
into downloading.  He was trying to avoid people thinking this.

TM> I was also under the impression that Bryan - for some packages - has a
TM> kind of backup server to download from when the original source is
TM> unavailable, unreliable, or the owner can't afford to have all people
TM> download his software.

This is true, but the md5sum shouldn't change just because it's on a
different host.  Of course, unless the user goes to the original author's
page to check, he'll just have to trust that the md5sums in etc/md5sum.conf
are accurate (which almost negates the purpose in the first place, but
that's besides the point :-P).

TM> Hmmm... Other than looking at the checksums and the patches, and
TM> possibly the original sources, what should the paranoid user do?

See above.  I would think that this would be enough.  As far as I know,
there haven't been any proven real-world collisions with md5sums given
different inputs.  But I'm no security expert either.  Actually, as a home
user, I'm naive.  I figure if someone was able to hack into apache.org and
change the tarball, or otherwise hijack my session to get me to download the
wrong one, then it just wasn't my day and I'd chock it up as a lost.  Hasn't
happened yet :)  For production machines (which I really don't own), I would
check the md5sum, but normally I just apt-get my packages anyway.  I don't
build much from source these days.

TM> There is a point where it's easier to program it all onself instead
TM> of trying to find out if a foreign package is trojaned or not. But
TM> then I don't think I understood what you said.

Yeah, it does get a little overkill.  Security experts will push this, but
hardly anyone else cares (or knows enough to care).

TM> No way since my desktop is *nix, too.

I dual boot my machines.  Linux hasn't gotten where it merits me tossing my
whole Windows system, and unfortunately, of all the *nixes out there, it has
the best hardware support (which isn't all that great).

>> filtering, templates, macros, etc. goes, I haven't used anything else as
TM>   ^^^^^^^^^  ^^^^^^^^^
TM>   procmail?  vi?

Heh.  Yeah, I use that stuff, but it's just not worth it.  I wanted
something fast and easy.  I like the CLI just as much as the next guy, but I
like the GUI too.

TM> In mutt you could do this with a hook that sets the header according
TM> to various criteria. I just have a std setting for all mails and use
TM> vi(m) to manipulate them as needed.

I could do it with a macro in the bat! (which has regexp support), but like
I said, I typically like to be CC'ed on list responses.  To each his own.

Btw, did Bryan fix your forum account and/or set up your SF access?

-- 
Kevin