Wolfgang S. Rupprecht wrote:
Mel <mel@xxxxxxxxxxx> writes:
James Wilkinson wrote:
me go hmmmm. Whats up with this? Trojan or just a signing slip up?
I suspect it's a signing slip-up. I'm seeing the same thing (on x86_64).
Me too. But I noticed that the non x86_64 version was ok.
yum clean all and reload did not fix it.
Looks like a new, signed rpm file has been propagated around.
Unfortunately they didn't bother to bump the RPM version number so yum
kept on getting some internal error with "range not satisfied" (from
memory).
Rummaging around /var/cache/yum and removing the old tcpdump* files
fixed things, but then users shouldn't have to rummage around cache
directories to get a distribution screw-up back on track. This is the
sort of thing that makes new users say "linux is too complicated."
-wolfgang
So was this a trojan version or an unsigned version? I thought the date
for tcpdump and libpcap were both dated in January even though the
development package was dated Mar 15th.
Anyway, looking up information for libpcap and tcpdump on a Windows
machine had me cross paths with the 2002 incident and kicked in the
antivirus software for windows.
Just to be safe, are these incidents unrelated? Did I just happen to
cross the virus via google and the packages were only messed up by the
build process?
I did come to the realization that you should not try to install
unsigned rpms in case this was an attempt to trojan version the mirrors.
Slightly paranoid by the incident.
Jim
--
Humor in the Court:
Q: ...any suggestions as to what prevented this from being a murder trial
instead of an attempted murder trial?
A: The victim lived.
