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

[<io...@ap...>]

> 
> On Wed, Jul 24, 2002 at 10:44:42AM -0400, Kevin J. Menard, Jr. wrote:
> > 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.

I wouldn't go with an option like PGP unless I was positive all linux 
distro's and BSD distro's came with it by default.  solaris comming up as 
3rd.

> 
> yes. I was only trying to enumerate the most common options.
> 
> > 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
> 
> Imho a sig would give the most trust to the package's integrity, with
> SHA1 second and MD5 third.

I went with MD5's because they're the most commonly posted from the 
upstream author.  It's also a safe bet all *nix clones will have the md5 
utility.

> 
> > 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.
> 
> Yes - MD5 is the most popular method of these. SHA1 should be as easy
> as MD5 and is the preferred method to determine a checksum on OpenBSD
> (you type "sha1" instead of "md5" and get a different value).
> 
> > 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
> 
> Yes, they don't change. That's what i wanted to say, too - as long as
> people trust (or independently verify) the checksums for the provided
> packages, it doesn't really matter that much if the script goes to
> his website and downloads software from there.
> 
> > 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).
> 
> Yes. Imho it works the other way round: Bryan collects the "original"
> checksums and then downloads the packages mostly from their original
> sites and checks if the download succeeded, using his canned list
> of checksums (etc/md5sum.conf).

Correct. Not all original authors provide MD5's however. In which case i 
just make one myself and trust that the authors package has no trojens or 
anything of that nature.

> 
> > 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
> 
> That theoretical possibility of a clash, or rather, that someone could
> fake a file for a given MD5 sum, made OpenBSD switch to SHA1 where no
> such method appears to be currently known.
> 
> > 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
> 
> Hacking into apache.org is very evil indeed. Hijacking the session could
> easily be prevented by offering HTTPS or SSH (RSYNC) or SFTP downloads.

I'm limited to the services I can run on sf.net.  HTTPS/SFTP/SSH(RSYNC) 
are not an option right now. I don't take security lightly but it gets to 
a point where if you're that paranoid about it, maybe you shouldn't be 
useing a canned script like ATB.  Where do we draw the line?

> 
> > I don't build much from source these days.
> 
> For me, it depends. If you have a number of different platforms, but the
> need/want to have similar packages installed on each, possibly with
> slightly different options, you may reach a point where building stuff
> yourself is easier than downloading several flavours of canned packages
> for each platform.
> 
> > Btw, did Bryan fix your forum account and/or set up your SF access?
> 
> Ooops - at least I never tried again, but I also have not received
> anything from him, too. You also don't list me as a developer
> (which is ok with me).

Give me your login name on SF and I'll add you as a developer if you'd
like.  As far as the (broken) forum goes, thats a different problem.  I
can't even find the original author's website now. And the admin feature
lists users by page, I can't shift through 1000 pages for you of course.  
I can however just edit your sql record.  Whats your login name on the
forum so i can find the sql record manually?

> 

Logs:

ATB logs everything 2 seperate ways.

*.log 
*.iw

checkinstall is just a wrapper for an older C program called installwatch
that was dropped by the old author and picked up by a new one recently.  
installwatch itself is just a wrapper for 'make' (actaully anything at
all) that records all file access done by the daughter program.  When a
system (linux, freebsd) is detected that installwatch will compile on, ATB
compiles and uses installwatch. So if there was a trojen in one of my BASH
scripts or even in a makefile in any package it will be recorded in
logs/*.iw.  The RPM creation system currently built into ATB requires the
*.iw log files. checkinstall also uses the installwatch logs to create the 
debian packages i believe.

*.log's are simply redirecting the output of make's and what not
throughout all the scripts.

another packaging option: use the rpm script in contrib/ .  This creates 
an RPM using the ATB script+sources package and your previously saved ATB 
settings file.  It only works with RPM packages though. and recompiles 
everything on the host system using "./install -f".  Not a viable option 
for most. 

-Bryan