Slashdot Mirror
Kurt Seifried On The Danger Of Binary RPMs
"He begins: 'I'm always amazed at the lack of articles on topics like RPM and PAM. These are basic systems components and tools that people use every day but which, generally speaking, are poorly understood (if at all). Prepare to be educated.. . . Generally speaking, RPM's must be installed as root, which means that RPMs can do anything on your system: install new files, overwrite files, reconfigure system settings, add new users, etc.
Why is this important? Because many people download RPMs from semi-trusted or untrusted sources and blindly install them.'
Curious George points out: "The potential for danger (with many newbies and not-so-newbies making use of binary RPMs from untrusted sources) is that Linux could develop an unwarranted reputation for problems by someone (or perhaps some Corporation?) purposely diseminating RPMs with built in vulnerablilities or exploits. We should do our part to educate and spread the word on this issue."
Why? Dependencies. For instance, if you're trying to install GTK as a RedHat package, but you've already compiled GLIB using the source. Now, the GTK package won't install because it can't find GLIB in its "registery" (shudder)...
An issue I have with binary distributions that I have encountered in the wild is that in most cases there is little indication of which headers and libraries the binaries were built against.
An rpm may have been built against the original Redhat 6.2 release, RedHat 6.2 with a couple of the ( rather extensive ) updates applied, redhat 6.2 with glibc 2.2.x installed from source, redhat 7.0, mandrake etc..
At least a source rpm can be rebuilt against the libraries and headers on *your* machine.
I am a lawyer and this constitutes legal advice and I shall indemnify you against any losses arising from taking it.
The source code could have just as easily been modified. A couple of lines in some obscure part of it is all that would be required to do the same thing any RPM install script could do. Quit being so damned paranoid already or just get your RPMs from a trusted source like the author or a major distribution's site where they check them.
Yeah, and guess what.
Those Makefiles run as root on your system, and can therefore do anything, bla bla bla.
Besides, all an rpm file is, is a fancy cpio archive. You can rip it apart and not let rpm do anything extra.
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Anybody can sign a package. That doesn't mean shit. As another posting mentioned, any fool can setup a GeoCities page, or similar, and provide their keys for verification, and still provide trojaned packages.
Why do some people think package signing is an end-all, be-all solution to trojan binaries? It's just one more way to lull yourself into a false sense of security. And of course, I think it's funny that people bitch that the Debian package format doesn't support it, considering that for all practical purposes, it gains you absolutely ZIP.
Maybe the Debian way has some advantages - keep all your packages in trusted archives, where they've been verified and tested, instead of relying on digital signatures to keep bad things from happening. You'll note having a real pen-and-paper signature from a person doesn't stop them from doing bad things either.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Good idea. But who are you?
(I don't mean that snidely -- I'm serious. What are you going to do to assure that trustedrpm.net means anything?)
1. Get the GPG key of the maintainer from a trusted source.
2. Add it to your GPG keyring using "gpg --import keyfile.txt"
3. Do "rpm -K somepackage.rpm".
4. If it's signed properly by someone on your keyring, it'll say "md5 gpg OK". If not signed at all, it'll just say "md5 OK". If signed, but not by someone you know, or if it's been tampered with, it'll say "md5 GPG NOT OK".
I use several packages that are a real pain to install-- ALSA and Livid are two examples. Lately, I've been trying out quasimodo and ardour (two sound recording applications.) Most of these packages come from cvs, primarily because I'm interested in the source. ALSA is very unstable, and because it is kernel dependent-- the updates are as frequent as kernel releases.
..
/usr/cvs/bin, but still, one needs to install libraries with the (root only) libconf tool. On the other hand, "configure" defaults to installing in /usr/local ..
But each of these packages consists of several subpackages-- each of which must be installed, before compilation of the next subpackage can proceed.
ALSA consists of alsa-driver, alsa-lib, and alsa-utils. LiViD consists of libcss, (optionally) libmpeg2, oms, and omi. Quasimodo has about six different sub libraries (at least one of which depends of ALSA), plus associated applications. Ardour depends on Quasimodo...
The only sane solution I've found is to totally automate the process with a loop along the lines of.
#!/bin/bash
for d in libcss libmpeg2 oms omi
do
echo "entering package $d"
cd $d
autogen.sh
make clean all
su -c"make install"
cd
done
While I do have to type the root password several times, it is a bit more convenient than compiling source as root. But is it reall more dangerous than typing "rpm -Uvh *.rpm"?
Probably the best solution would be to set up a user accessible (/usr/cvs perhaps) hierarchy that doesn't require root access to write to e.g.
The right thing to do is to fix any problems with package signing, and to make the system transparent. (So if I install a Redhat system out of the box, it should come with a Redhat public key, and rpm should warn me if I install anything not signed with that key.)
Danny.
I have written over 900 book reviews
Huh? rpmfind tells you *exeactly* where it got the RPM from. What's the problem?
"The invisible and the non-existent look very much alike." -- Delos B. McKown
autorpm
Imagine user-friendly applications that can rely on the existence of a compiler to produce their own plugins or compile user instructions into very fast machine code.
And even dumb users may appreciate the ability to get an application in a small package that they know will work on their system.
It is true that the compilation should be hidden from the user. The download should be a single file that you double-click, it then compiles with a nice "N% done" meter, it then pops up a window with two buttons, one says "try the program" (which runs it, and it can be pushed repeatedly). The other says "install the program", this then asks for the root password and does the installation.
Back to the time when men were Stallman!
Sorry. Couldn't resist the pun.
--
--
Don't like it? Respond with words, not karma.
And these self-same newbies are going to be able to download source, *inspect the code for trojans*, and compile?
Security is as security does. Downloading a binary from an untrusted source isn't a whole lot more risky than downloading an indecipherable source code to compile.
Unless you're some sort of Code Hero, you just gotta trust that people aren't out to screw ya. I'll take the convienence of binaries over the P.I.T.A. of source, any day...
--
--
Don't like it? Respond with words, not karma.
You're talking about using a disassembler on the binary, right? Those produce rather hard to read but decipherable assembler code. Just getting the source in C (or even the original source in assembly with comments if the author cares not for cross-platform portability) would be at least 10 times easier.
But there is a huge difference between machine code (1's and 0's) and assembly language. There are only a very few highly strange people that can glean any meaning at all from machine code.
Source RPMs solve nothing. If you are retreiving any software from an untrusted source, then running that either as root or as any user that ever switches to root from their account, you can be owned quite easily. The only solution is to verify that the software does what you want by reading the source, or having someone you trust (like a distribution or local admin) do it for you.
I'll have to get back to you guys on this one. I've been too busy reviewing the SRPM for Emacs. Another two years and maybe I'll be ready to compile it.
You install your programs into /usr/local/stow/foo/*, and then from /usr/local/stow type stow foo, which then creates symlinks into the /usr/local hierachy. To remove the symlinks, simply cd /usr/local/stow and stow --delete foo, and then you can safely remove /usr/local/stow/foo.
Very simple, very effective.
Go you big red fire engine!
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
There have been several people pointing out that they never inspect the source anyway, son binaries are just as safe. I don't think that's quite true. At least the source normally comes from a relatively 'trusted' source, whereas if you're donwloading a binary rpm from a 'contrib' directory, you may not be able to find out who wrote it.
However, I'd be more interested to hear if anyone has been stung by malicious rpms - is the problem widespread at all?
It's possible to be paranoid enough to qualify for medication and STILL not be 100% sure they can't "get you". NSA spooks sniffing your monitor's EM radiation to see your screen. A virus in your flashable bios. Those fun kernel module rootkits you can't detect without a clean boot disk and a hex editor (which is a fun way to inspect a 40 gigabyte drive...)
Personal inpsection simply doesn't scale. It hasn't been a realistic option for anybody who couldn't afford to do it as a full time job since the days of the commodore 64.
What you do is you find somebody to trust who will do this for you. Then you have to trust them. If Red Hat doesn't do it, than somebody who makes a distro based on paranoia (Red Helmet?) will make money by being, basically, paranoid and proud of it.
Red Hat obviously isn't it. It installs nfs by default. It installs a network writeable LPR even if you haven't installed printer support. That's just wrong...
But RPM's are just Linux's equivalent of running normal programs under an MS os. You can get viruses/trojans/whatever we're calling the variant this week. That's what being root means, and some things HAVE to have that access. (By definition, configuring the system requires the ability to make changes to it. Why does this seem to suprise people?)
Rob
While a binary is easy to install, your download should also include the source.
If for some reason you don't want to make the code, don't. (Don't know how, don't care to. don't think is a hole, that cool.)
But if you're the least concerned about security or just run on a different platform, you should be able to examine (and possibly tweak,) and then compile the code to check if it matches the binary so you're sure of what you've got..
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
'course if you're using NT etc. it can be configured to only let admins run installshield.
In Win2k we're warned when we try to install an unsigned driver. I've heard that in WinXP we won't have the option to install one.
:-)
/winnt/system32. I don't know about XP. (installing the beta is on my todo list, as XP is in my company's migration path) I wouldn't mind a bit if XP /warned/ users before installing an unsigned binary application. Then again I'd be pretty pissed if it /prevented/ me from doing so.
What does that give us? It makes sure that the binaries we're installing are safe and virus free. (unless you consider any M$ software a virus, as the popular saying goes.)
Granted M$ could abuse this process by making it hard for certain companies to get their binaries certified, but that may be a price to pay for safe software. (and this is another tangental discussion.)
Now this takes care of drivers, but doesn't seem to account for applications. Win2k doesn't care what application you install. It will happily let you install viri that make modifications to
So maybe Microsoft has a point. I know RPMs freak me out. I'd feel safer installing only signed, certified "virus-free" software on any OS.
I used to use Redhat exclusively. It's on my servers, my workstations, and was on my laptop. But lately, I have been running into the "linux speed of change factor". Running redhat and trying to do cutting edge development doesn't mix. downloading the newest libs means fighting with trying to install into the non-standard redhat file-layout. (Example: download and compile the latest dev apache. It doesn't want to install to /home/httpd and /etc/httpd it wants to be where the developers told it to be and that is not where redhat put's it.) Digging deep into the embedded linux world, binary RPM's are 100% useless, embedded is a completely different beast...
binaries, oh binaries.. good for an appliance user. Ok/notok for a real user. (DEF: real user, person who compiles their own kernel, configures things by hand to makes them work perfectly, and digs around in the bowels on occasion.) and bad for a developer. I dont know where it will all go, companies want to hold tight to that "Golden IP" thing they think is valuable but in reality is worthless(Sorry ATI, your drivers are not making you billions..), and companies are never run by visionaries... they are run by self centered businesspeople (Of course they are, they wouldnt be a business if they weren't) who will not share with others unless it makes them more money or is worthless anyways (and even then they are usually greedy.... anyone seen dBase release the code to version 1.0?? nope and they never will.... greed...)
The world will be forever split. Opensource over here and corperate over there... It's more important that the Opensource people keep a lot of pressure on the Corperate people than try to "play nice"......
Because...Corperate will NEVER play nice. (It's not in their best interests.)
Do not look at laser with remaining good eye.
dselect has the worse userinterface ever. You're the first person who has said anything remotely nice about it.
Which is why Debian is moving away from dselect to aptitude.
Je ne parle pas francais.
If there is a problem that reduces the trustability of PGP Signatures in RPM files, or that reduces the liklihood that a signature can be verified, then we should develop an RPM web of trust for RPM signers. I'd be willing to front the webspace and database is such a thing doesn't already exist.
I'm just an RPM packager and user. No one can say, "you can trust my RPMs" but it would be great if there were a system available by which a packager could build a trust relationship with users, and by which users could verify the claims RPM packages.
If it's needed TRUSTEDRPM.NET can be used to start a mailing list and website so other people interested in building a network of trusted RPM packagers can dicuss what could or should be done. I can provide any other resources that are needed (application server, databaser server, bandwith, etc.) and do the development work too. I'd really like to see this happen now, not later.
What's needed isn't resources of course. It's qualified and enthusiastic participants.
It is easy to verify the signature of an RPM produced by a major vendor. However we need a system by which individual packagers can build trust with the users of their RPMs. Perhaps a "web of trust" type system would work, or perhaps someone can suggest a more appropriate solution.
The problem still remains. It lies not with the technology but with the lack of a trusted source. Are there any existing systems for building RPM signature trust?
I have just registered TRUSTEDRPM.NET for the purpose of hosting an application to help build trust amoung RPM signers and users, assuming somethign doesn't already exist.
This approach of trusting only certain authorities is very limiting; it means that only well-known groups could provide me with software. Signatures protect against tampering between the source and destination, but what about attacks from the source? In this modern age, I would like to be able to try software from some random dude in Tuva or Timbuktu. How can I do that without exposing myself to attacks?
One approach that I've wanted to try should be helpful, but I haven't had time to build it. Others have talked about this elsewhere, I'm pretty sure, but I still don't have the app in my hands. Do any of you have time to write it?
Most software I install is installed by root, but will then be run by a random user. Let's suppose that I'm willing to trust code as an unprivileged user but not as root.
The fundamental approach is sandboxing. Don't trust software based on the name of the author (and the signatures that authenticate it), but on what the software does. We're going to run the installer (e.g. rpm or configure/make/make install) from within a specially-configured subterfugue process. Subterfugue intercepts system calls and can replace the requested actions with custom ones. open,write,mkdir,mknod,rmdir,unlink,etc. will all be intercepted.
I would configure subterfugue such that:
At this point, no files outside the sandbox have been modified. Post-modification checks are done here, optionally examining the "diff" relative to the real file. If any of these tests fail, the software should not be installed. If it is to be installed, then the modified files are moved from the sandbox to the real locations.
Whether installation is aborted or completed, clean-up is merely erasing the entire sandbox directory.
This sort of thing is complicated to use, but that's because it's asking for complex judgement from the user. It's begging for a clean front-end with permission rules ("let it create new executables in /usr/local/bin",
"allow all writes to this
directory subtree", etc.). And if anyone has a
simpler way to achieve this goal (other than
the current "hope you're safe").
Furthermore, this approach only protects from installer attacks that are trying to gain root access. It doesn't protect against attacks against run by the user account (which could even be root!). If one were really committed, one could place a subterfugue wrapper around all programs, tuning them for permission only for the files and network access you decide they need. But there you may have an unacceptable slowdown from the interception of all system calls.
Only one problem: having the package be signed doesn't tell you anything about how safe it is to install it. All it tells you is that the package was built by the person who claims to have built it. It doesn't tell you whether you can trust the person who built it not to have trojaned it, or even whether the person actually is the person they claim to be ( see the recent obtaining of official Microsoft certificates from Verisign by parties not affiliated with Microsoft for an example ). Given that, signatures on the binary RPMs are completely inadequate for security ( just as signatures on ActiveX components are completely inadequate for security ), and if you do the things needed to make them secure then you wind up not needing the original binary RPM at all anyway.
That's one of the points. You know it hasn't been tampered with since it was signed, but you've no assurance that someone didn't unpack it, trojan it, repack it and sign it with their certificate ( which happens to look very similar to the one that should be on it, perhaps even being in the right company name ). Nor does it give you any assurance that the server you got it from wasn't compromised and not only the packages altered but the certificates and signatures/fingerprints on the server as well. You end up having to go obtain the packages and the certificates to verify them directly from the original author to get those assurances, and do it over an untamperable connection with verification of the sender's identity ( not a certificate, actual out-of-band verifiable proof of identity ), at which point you don't need a digital signature on the package for either authentication of source or detection of tampering.
Compiling from source is a much better alternative in any case. The only time I RPM anything is when it takes 15 packages to let me use a certain piece of software (KDE for example), but even now I'm thinking that compiling would save me headaches.
"It's here, but no one wants it." - The Sugar Speaker
At least with RPM you can see whats it going to do
and what files the package holds
eg rpm -qpl package.rpm
rpm -Uvvv --test package.rpm
I wish redcarpet had this
Duh,
Never install an RPM unless:
1) You wrote it (my favorite)
2) The vendor (Red Hat, Mandrake et al) released it (and the sig verifies)
3) The developor released it with thier software (think fetchmail)
Even then #3 can be dangerous. Since RPMs install as root you can really kill yourself if you install a fscked up RPM.
Take APC for example. They have no concept of how (Red Hat) Linux does things and the early versions of their RPMs for their PowerChute software showed. It always made me nervious when I installed their stuff.
Sounds like it would be a porn centered
distribution... Divx and newsreading etc
in the default install!
Unfortunately, a strap-on security model
is always very sucky. Look at ACLs on any
unix or even NT. Your model sounds like a
typical hacked up pile of shite.
What you want is capabilities.
See www.eros-os.org
Basically - a capability is an
unforgeable object reference.
In a true capability system,
that is the only way to do
anything outside your own address space.
This allows anyone to implement a very
simple security model which is much
easier to verify. It also gets
rid of all the dumb ass home grown
authentication systems on unix. (ie Each
app authenticating people in a funny way)
Do you have specific examples? I know that Red Hat takes great care of all packages on the main Red Hat CD:s, and make all of them themselves. I believe the Powertools CD:s are the exception, but I think it's explicitly stated that those are from third parties.
GNU/Linux. The Freshmaker.
So what is your suggestion? Should they ship a kernel in their distro with known bugs, when they instead could easily fix it by applying a patch?
If you want a pristine kernel, download one from kernel.org yourself or rebuild the kernel source rpm with whatever options you want. If you want a stable and well-tested kernel that works well with your distro and is built with the necessary options, use the kernel that comes with the distro. If you want to know what changes were made, just read the documentation for the kernel source rpm.
Don't confuse your distro with kernel.org; they fill different purposes. kernel.org has to distribute pristine kernels, but they can have serious bugs, that's not their problem. Your distro on the other hand does not have to ship pristine kernels, but they should not contain any serious bugs and it's their problem to make sure it doesn't.
GNU/Linux. The Freshmaker.
These packages are GPG signed by Red Hat, Inc. for security. Our key is available at:
http://www.redhat.com/corp/contact.html
You can verify each package with the following command:
rpm --checksig
If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command:
rpm --checksig --nogpg
So it's not exactly a new idea :-)
GNU/Linux. The Freshmaker.
It seems to me that I would be hard-pressed to go out and find a piece of infected software, for pretty much any operating system. If I want some program taht does something, I stick it into google, get the homepage. The bins/source on that homepage isn't gonna be infected, cause they want people to use their program, not NOT use it. Even tucows/sunsite/sourceforge or whatever isn't gonna have viruses. I think that we're talking about a completely nonexistant problem here.
I would naturally think twice about installing something I got from somebody on IRC, but come on, I think that when you get something off a large software repository, it's not gonna be infected.
What does matter is better linux games...
-S
I really like the fact that the "printer-formatted" link was given. Who wants to see all those ads? Wait, don't answer that.
Binaries can be audited too.
Not legally in the US anymore, thanks to the DMCA. At least, not if the license says you can't.
Not to imply that I agree with Kurt's article in any way...
The fact is, you HAVE to trust, no matter what operating system you use. There are lots of people out there who, believe it or not, use linux, and don't know a thing about reading source code in C or any other language. (I am not one of those... I know C quite well.)
There are other people who just don't want to look at the source... or fill their disk with it, or whatever. Installing binaries comes with the same risk as installing any old piece of software for any other popular OS. (Windows, MacOS). Millions of people take that risk every day, without problem.
Are there dangers? Hell yes there is. Do most people know this? Yeah, they probably do. Do most of them care? Probably not. Personally, for my desktop machine, I really don't care. For the critical systems I maintain... yeah, I do care. But Joe Average nonprogrammer doesn't, and even if he did care... he can't understand the source anyway.
Yes, using binaries is dangerous, but comparatively not that dangerous at all.
On the issue of package signing. Well, I can set up a geocities website... make a trojan RPM, give it away... and even sign it with GPG and give away the public key all on the same site... and some of the comments here seem to imply that there are users out there who think merely having a signature on the package makes it all good
Think again. ANYONE can sign a package... and anyone can set up a website to give away binaries and GPG keys that sign them. Even better, one can provide source that doesn't have the trojan... to make people feel more comfortable. Maybe even make it broken a little so that people try out the binary to see if it works any better.
I can think of a dozen ways to get people to use binaries over source. Some are even familiar... remember the first versions of BladeEnc?
So, in the end... you take a risk anyway.. You can lower it, even to zero... but most people will take the risk.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
Quick poll, raise your hand if you inspect EVERY piece of software you install for security problems. I thought so.
If are going to be that paranoided, we should do one of two things: 1) Throw our computers away and never use them again because we don't know what we might be installing. 2) Go back to the time when men were men and everyone wrote their own programs, compilers, shells, etc.
Give me a break...
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
Why is Kurt getting so much press for (re)stating the obvious?
-- Ed Carp, N7EKG erc@pobox.com PGP KeyID: 0x0BD32C9B What I'm up to: http://intuitives.mine.nu
In this case, the "problem" can also be the "solution."
/etc/shadow, for obvious reasons.) This helps stop malicious installation of users, or compromising existing ones.
I've written some (Debian) packages which do nothing but set/clear the immutable flags of selected files when they're installed/removed.
Some examples:
lockdown-kernel will "chattr +i" the kernel images and modules, plus the configuration files used by the module loader. This helps stop installation of malicious kernel modules.
lockdown-users will "chattr +i" much of the user database. (Not
lockdown-apt will "chattr +i" the configuration information used by "apt". This helps stop malicious modification of my system upgrade process.
lockdown-lib will "chattr +i" the core libraries, and the ldconfig information. This helps stop malicious modification of the core libraries - or the library search path.
I'm sure you get the idea. If I really do want to modify something, e.g., adding a user or installing a new kernel, I just remove the "lockdown" package, do the work, then reinstall it. This approach isn't perfect - unless I also change the capacities bounding set a malicious package can simply call "chattr" itself - but it's a good first step.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Yes but how many windows lusers who are not even capable of changing their default homepage are going to do that.
It has been said on slashdot a billion times. People can not be expected to actually mess with their software and that's why people use windows. You wouldn't let your mother use linux and your mother would not be able to mess with NT or windows 9x. Windows is an OS for people who don't care and who can't deal.
War is necrophilia.
I got my mother a MAC. No more tech support call sto me! Really a mac is a great choice for mom or dad. I still don't think I would go with linux because dad likes AOL (go figure).
War is necrophilia.
This rpm issue is simply not just about if RPM's are binary or source.
... have everything to loose if intentionally delivering shady software. Just look how anxious they are wat providing security updates to their products for faults that no one really can blame them for.
The issue is, can I trust this software to be free from trojans or other evil stuff?
It's like using credit cards, you will happily use your credit card at some well reputable store but will be reluctant to use it in some shady dark alley business.
It's just the same with software. A well known softwarehouse such as RedHat, SuSe, Mandrake
Also single persons with a good reputation such as Wietze can easily be trusted since this guy has so much reputation to loose if he intentionally does an evil act with his software. The same goes for other people that seems to be proud of what they are doing.
It's all about trust. You can trust the person or organisation that has much to loose if they provide software with trojans etc.
These softwarehouses signs all their RPM's cryptografically with the company key and you can easily check that it's a genuine package made in good faith.
//Pingo
--- Linux or FreeBSD, it's like blondes or brunettes. I like both. ---
I dont understand, how is this any different to InstallShield overwriting and destroying your windows settings?
How we know is more important than what we know.
<sarcasm>
Don't you mean it stick's out like a sore thumb?
</sarcasm>
------
Machine code is no less logical than source code (and it can be more logical in some cases). A lot fewer people can understand machine (or disassembly) code, but there's nothing inherently hidden about it.
Assembly language is easier than you think. Really. Try it.
------
Binaries can be audited too.
------
Why does everyone use make install? How do you people keep the cruft from building up on your system when you upgrade and/or remove programs?
------
Well, yes, but I don't have to be talking about it for my point to stand.
------
Yeah, but (if you guys in the US do your jobs and get on your politicians backs,) that won't be true for very long.
------
which is really kind of funny since you could simply chmod u+r the file :)
treke
Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
I've found it safe to install the realplayer rpm(apt-get install realplayer requires the rpm)
treke
Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
Consumers think they want binaries.
...
In reality, consumers don't know the difference (or care) as long as it works and explains what they need to know to them. Give them a graphical program that does a
./configure; make; make install
... for most packages and they'll be happy. I've taught many people to install source packages without any knowledge of C, Makefiles, etc.
- Michael T. Babcock (Yes, I blog)
The point I made was the distribution of source. I made no claim to this being more secure or less, simply a retort to the person who claimed that users don't want source because binaries are easier.
... when the police state happens ... ;-)
If you want the point, however, it means that everyone has the sources. Its a bit like everyone having guns but not knowing how to use them
- Michael T. Babcock (Yes, I blog)
Dependancies are easier to track at compilation time as well.
- Michael T. Babcock (Yes, I blog)
This is quite valid.
I'll admit that for some projects, source distribution is unwieldy (although I compiled my own versions of glib, gtk and gnome-lib for most versions on a K6-200), but Make's ability to track dependancies removes the need for recompiling the whole project for a patch.
- Michael T. Babcock (Yes, I blog)
you cannot possibly inspect the source of every program you install.
However, they overlook one thing: If the source is out, it CAN BE audited
Hrm. Perhaps others capable of source audits can download the soruce while I download the binary? Is it just me or this completely obvious?
That sounds more like an argument for using Open Source software rather than an argument for downloading SRPMs.
Unfortunately, a strap-on security model is always very sucky. Look at ACLs on any unix or even NT.
...wait, they all use ACLs already.
And? What makes them strap on? So Unix wasn't designed to be a secure OS. Neither was it designed to be anything more than a time sharing system.Its evolved beyong those functions and works great. The ACLs on an Unix, NT, 2K, and VMS work very well.
What you want is capabilities.
I want them too, but they don't replace ACLs. Capabilities are already in kernel 2.4.
I have some Word templates on a SMB server. I want:
* The software to be owned by the admin account
* The software group to have read and write permission, and SetGID properties
* The staff group to have
* Other users to have no access.
RWX doesn't allow me to do this in anyway which isn't vastly hackish.
This allows anyone to implement a very simple security model
ACLs are as simple or fine grained as you need them to be, and a single line ACL is quite obviously simpler than an RWX permission.
which is much easier to verify.
Bah. Same thing - again, ACLs can be less compels than RWX if that's all you need.
the dumb ass home grown authentication systems on unix. (ie Each app authenticating people in a funny way)
Damn straight. Things like Squid, and BIND, and
Capabilities are nice. They don't replace the need for ACLs, and while they work well and should be used, the RWX / Capability combination is more complex than a single tight ACL, combined perhaps with capabilities should you need them.
We need such complex tools is because we build systems that the end-user has no chance to understand completely.
I especially find the comments about how source RPMS are even less likely to be checked by users amusing.
When are we going to stop designing systems so that they're programmer friendly and start designing them so that they are owner friendly.
Note I didn't say user-friendly.
The whole user friendly detour is juat a way to cover up a scam that gives programmers a job at the expense of usefulness, practicality (coolness we can afford), and general product value.
I propose we throw away terms like user, programmer, hacker.
Why?
The term owner is much better than the term user because it implies that the owner has a purpose for the product wheras the term user implies consumer-guinea-pig-product-swallower.
Owner implies that he/she will focus on a task and use the same sort of skills some doing their own gardening would, namely a little research here and there, a little planning, a little sitting in the sun and enjoying the pride of a task accomplished.
And yes the last bit I would consider a skill.
The great success of the user-friendly scam is due to to the lack of any satisfaction people derive from completing a task nowadays.
Owner vs programmer:
Code-fiend-quack-sophist vs artisan or artist. See owner vs user. Again tool builder versus someone with nothing better to do than sell bigger and bigger APIs for more and more overpriced products.
Owber vs hacker:
Frobb technician vs seasoned and focused problem solver.
And of course the term owner also makes the lack of any ownership in today's market stick out like a sore thumb.
Don't patronize, don't pontificate, and don't sell people stuff you built aimlessly.
The message on the other side of this sig is false.
No. it's more like this:
A black box in the plane won't stop the plane from crashing. But when it crashes, you can find out why it crashed afterwards.
However, they overlook one thing: If the source is out, it CAN BE audited. Which means, that if the rumour shows up that vendor XY somehow tries to sneak in some spy-ware / trojan into your system, anyone can verify it (and it's easy to find those worrysome socket/bind calls in a media player's source)
That is, it won't protect you from trojans, but once you suspect a program, you can easily verify *exactly* how your system is compromised, and the vendor who shipped it gets a BAD reputation from it.
Same reason I misspelled cojones as cajones in my .sig a while back -- because rediculous is slightly closer to many people's pronounciation.
But just remember the handy mnemonic:
If you don't want to be an object of ridicule, look up the spelling of the damn word.
You mean OpenBSD and NetBSD as well, not just FreeBSD.
Not only do the checksum verifications give you added security, but most ports that are committed come with a good look-over to correct bad programming with regards to race conditions and inappropriate behavior of setuid/setgid applications. While they might not find every bug, it's better than nothing.
You're ignoring or forgetting one crucial difference.
If I install an untrusted binary rpm, there are scripts that get run as root. Not a lot of people understand them, look at them, even know how to look at them.
If you install from source, what gets run as root. ./configure, make, and a couple of shell commands to copy the binaries and documentation into their proper place. If the source is trojaned, it's still going to be inside a user sandbox. If ./configure is trojaned, at least it's a lot more likely someone will notice that. I've never once looked at the install scripts in an rpm, but I've more configure plenty of times... *shrug* so I do think installing from source is more secure.
"That old saw about the early bird just goes to show that the worm should have stayed in bed."
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
So a necessary part of an OPERATING SYSTEM is a compiler? Thats nuts.
Although your point of joe consumer not knowing the difference is accurate.
I'm still working on a clever footer.
Consumers dont want source.....they want binaries.
Asking your average consumer to compile their software is very, very unfriendly....prone to error and generally a bad idea if you really want Linux to be a consumer desktop.
If linux is ever going to make it as a consumer OS then there is going to have to be some sort of compromise between ultimate security and ultimate ease of use.
I'm still working on a clever footer.
Er, dude - the clock is based on the local time of YOUR PC! For example, when I look at slashdot, the times are presented in AEST, which is +10 GMT (or is it -10?).
Maybe you should change the time on your PC?
It's more complicated than that. Someone can set up> a server that looks like the master .rpm or .deb server, and pollute a DNS cache so that the name of the real server points at the fake server for anyone using that cache.
As you say, the best way to know for certain (for some value of "certain") is by using cryptographic techniques.
M
GROGGS: alive and well and living in
Anyway, what hasn't been mentioned is something I've been thinking about around virii. I think a big part of the reason a Linux virus has been unable to get off the ground is because we basically don't pass around binaries. When was the last time you gave anyone a binary? When was the last time you received one? We've all gotten so used to "./configure; make install". Writing a virus that attacked autoconf source code would in theory be possible, but, again, the distribution vector isn't very good, because we don't even pass around the source code.
The way software gets distributed on Open-Source systems is, I tell a friend of mine, "Dude, check out this software...it's called Blady-blah. Just find it on freshmeat." Even more than the permissions system of Unixes, I think this reliance on compiling from the original source (because it's the easiest thing to do) is what keep virii out of the Linux swimming pool.
yah, MacOSX and all...
read all about it at Timepasstown
Frankly, on my GNU/Debian system, I find installing /any/ kind of RPM hazardous to my system's health.
Weapons of Mass Analysis
I personally use source tarballs all the time, since slackware's "package" management is just tarballs with an installer bootstrap. Do I feel any less succeptable?
NO
Why? I'm using the source right? Well, it's not like every time I download a new program I inspect every line of code. That would be rediculous. I don't know how everyone else is, but if there is a configure script, hell, I won't even read the INSTALL file. If I can get it working the first time, I won't even read the README. I've been through enough 'configure ; make ; make install' cycles that I try what looks right first and ask questions later. And I'd bet most others do to. Which makes us all just as vulnerable to attack as the 'binary downloading newbies'.
Free Online Woodworking Resources Directory
The user that installs the RPM has to be able to write to the installation directories and to the RPM db. With the --relocate switch, you can set the directories that most applications write to. With the --dbpath switch you can control the RPM database to write to.
Not all software needs to be installed as root, you could do something like add certain users to a group which has write access to /usr/local. That still wouldnt stop install scripts being able to run a bindshell-type of program though.
I question wether or not this is what you should be trying to tell a 'newbie'. These types of issues should not be the end users concern and there is already enough confusion for many new users. This should instead be the concern of the people who develop the package systems and improve security methods, not the average desktop user. For the experienced, like someone else said this falls into the duh category. I don't complain about articles that are boring but this one is just wrong. Similarly, I won't tell someone to inspect thier engine for problems after it's installed by their mechanic, that is what they pay thier mechanic for. Ever consider you're asking too much of the user?
I really don't see what's so confusing about it. There are no precedences, the permissions are checked for your currend UID and GID, and if what you're trying to do isn't permitted to either, you get an error.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
Basically, this doesn't let application A mess with application B's stuff. It enforces a rigid model on package structure, which may not be a bad thing. It forces vendors to clearly identify apps which need to mess with other apps, because they'll need extra privileges, which users might not want to give them.
I don't see what the big deal is with source RPMs - something malicious could just as easily be put into the source tree and then you would only be compiling it yourself. (But with your very own optimizations, it might just run that much faster!!
The answer is more just to d/l [source,binary] packages directly from trusted sources. I certainly don't drag a rake through all the source of the packages I compile!
Just get the stuff from someone you trust. Although I remember hearing something a few years ago that even Redhat doesn't truly check every package's source thoroughly. (Which is completely understandable, provided they excercise some caution.
I think that these responses are missing the point the author was making in that the rpm binaries are typically (if not always) installed set UID root.
Perhaps we should be looking at ways of making that better in the future. For instance, you install the OS, of course, at this time all of the rpms are installed by root, however, a casual newbie now wants {insert your favorite package that does not come with distro here} installed. At this time he/she grabs a binary rpm from the first site a seach yeilds (lets say he/she does not know about rpmfind or the home page of thier distro)... I think that from a security point of view, perhaps now the user would be better off if all packages they installed did not need root to do it.
Of course, after saying all of that, I think I recall a distro that does this already (does not use root for package installes, etc). Anyone know what distro does this?
No, the most specific permission takes precedence: user > group > other. For example, if I'm user khym in group people, I will not be able to access this file:
----rw-rw-1 khympeople95 Apr 15 04:05 somefile
How about you fix it yourself?
In case nobody over in Linux/OSS land has noticed, the world of consumer OS and consumer internet software has settled on a solution to this problem: cryptographically signed packages. Microsoft has used it for ActiveX and IE downloads for a long time, and is now using it for system components. Java's security model has reliance on signed components built into the foundation.
Pretty simple guys, go get a code-signing cert and sign all binaries using standards-based signing mechanisms (check OpenSSL). If you are the developer, sign the source tarball. If you are the builder of binaries, sign the binary tarball. Use a codebase that provides a permanent URL for the source of the component, and use a consistent versioning scheme.
Next step is creating auditing tools that step through your path and check for untrusted components.
Once the mechanism is in place, all you need is an enterprising distributer to make a 100% signed system. Now the user has to trust that the distributer has done their homework and actually reviewed the code and/or checked with the original developer.
One last thought: wouldn't it be cool if the kernel dynamically checked the signatures on components as they executed? This could kill performance, so you'd probably want to precheck a select set at startup and then just compare hashes as the components loaded.
Premature optimization is the root of all evil
This is one of the key advantages of FreeBSD's ports system. It installs everything from source, but first performs a checksum validation on the tarball. Expert users can inspect the code manually if they want, but novice users can rest assured they're using untainted code if the checksum test is passed.
Be serious. While it would be trivial to setup, the effort involved wouldn't be. Do you honestly think the average trojan writer is going to go to this effort? They're too busy pissing their pants laughing if someone downloads the program, there is no way they would go to this effort. They don't need too. Some RPM packages already email the creator when they're installed (details available upon request). The trojan installer is about as likely to do this as they are to come break into your house and steal your computer. Get real.
This is quite possibly the worst example of scaremongering I've seen outside of 20/20 and Dateline...
---
Love that wording, makes them sound like one step down from Navy Seals...
Security is a myth people. You are always the weakest link. RPM's, as has been stated, are no worse than source. The author of the article is clueless. Actually more likely he just loves the sound of his own voice...
---
This is a known issue, however, as with all software ensure you trust the source of the rpm. If it's an rpm, you can probably find the rpm at http://rufus.w3.org/ or http://www.freshmeat.net/ and I would look at one or both of those before I went to joessoftware.com and downloaded anything.
As usual, get the source and look for yourself inside to see if there's anything you should be wary of before you build and install. Build as your user and run the program a couple times before you 'make install' as root.
Now with binary rpms, you can use midnight commander, type 'mc' at the command prompt, and you can look into rpms and find out what files are listed, where they are going and you can even get them out of the rpms into your home directory AS THE USER and use the binaries without root permissions. That would limit the damage should one be evil. After you assure yourself it's okay, THEN install as root.
DanH
Cav Pilot's Reference Page
Cav Pilot's Reference Page
UNIX - Not just for Vestal Virgins anymore
My experience with Kurt Seifried is that he's a pompous asshole windbag. First he wails on Caldera for not including OpenSSH _binary RPM_ files for their eDesktop 2.4 distro, even though there are OpenSSH RPM files for their eServer distro that work on eDesktop just as well. He went so far as to call the fine folks at Caldera "lame" for not including them by default. When I wrote him personally, and suggested that calling them lame was out of line (I'm not a Caldera user, but I think that showing your ass and giving the unwashed masses in the corporate-0wned media examples of bickering and infighting are poor advocacy), he was a complete asshole about the whole situtation. I'd paste in the original emails, but I was so pissed after I had tried to be civil with him, and all he could do was be a smartass, I shit-canned the emails. And now, after bitching that they didn't provide binary RPMs (which they did, but with eServer, not eDesktop... a point he never acknowldeged), he now goes on a tirade _AGAINST_ binary RPMs? If you ask me, Kurt Seifried is a bunch of hot fucking air, and not press-worthy.
There are two major products that come out of Berkel
./configure --prefix=$HOME/bin
You try it.
Besides, if you'd looked at the link he provided, you'd have seen that it had nothing to do with what you are talking about.
-b
application directories . . hmm, they sound kind of Mac like to me. Good idea? Dunno . . .
this isn't the seifried that I know! He didn't use the word 'moron' even once in that article ... at least, not that I found. Someone must have installed a binary RPM as root on him and it overwrote his 'moron' libs.
What I (and many other idiots) need is a step by step idiot's guide to getting RPM signature verification working. Someone must have written such a thing, does anyone know where to find it? It won't allow me to achieve the supreme security level advocated by Mr Seifried, but I will be much better off than I am now.
This is a problem with _any_ binary package management system. All binary package management systems are prone to this.. it's not just an RPM thing. If you're installing binary packages from an untrusted or unknown source, then it's your own fault if someone hides a trojan in one. Installing something blindly is on the same level as leaving an unfiltered telnet port up.. if you go around doing stupid things, don't be surprised when it all blows up in your face. Binary package management systems are great, especially if you build the packages yourself and have multiple machines to manage from a single common code base. If your filesystem acts up, you can verify all the packages that have been installed to detect any form of corruption and change, without having to resort to something as annoying as tripwire.
Why don't more desktops support application directories? Then, I just download a binary archive, extract it and run! No need to be root, no need to run any scripts and no problems uninstalling if it all goes wrong.
Nope - won't work.
Running configure will update Makefile and config.h, which means you have to recompile. So, it's not a binary install.
Application directories allow you to easily install binary packages without being root.
To summarise: yes, you can install as a normal user, but only from source, which is daft!
I can't believe that there isn't a single mention of Red Carpet in this entire thread except for some poor bastard who got moderated down to "0".
The obligatory link:
http://www.ximian.com/apps/redcarpet.php3
Anyway, this is THE TYPE of product that is necessary for newbies to use Linux. It lets you install packages you have downloaded yourself in addition to providing "channels" which contain many of the packages you might want. It also alerts you to updated software (possible security fixes) in those channels. Before installing a package, it automatically checks crytographic signatures. I think that a product like this with access to a broader software library than Ximian provides would take a significant chunk out of this problem.
---
That's not the point.
.deb.
With Debian, 99% of your software is going to come from ftp.debian.org or whatever your local mirror is, because the Debian developers have packaged so much stuff up for us.
So you generally don't have to trust some random hacker's RPM, you have an official
OK, there are always exceptions that you can't get hold of from the Debian ftp sites, but there's more official Debian packages than official RedHat packages.
Unless something has radically changed in the 12 months that I've been away from RedHat.
Yours Sincerely, Michael.
And if you do pick up a source RPM for Red Hat, the "2.96" compiler may contain bugs or incomplete features that generate a broken binary.
Because of Red Hat's perfidy, I no longer trust commercial Linux distributions; I'll stick with Debian, thank you.
And the behavior of Microsoft/InstallShield is no excuse for Linux to be sloppy or insecure. Linux is supposed to be better than the competition, remember? If :Linux wants to be taken seriously by "real" people, its community needs to focus on trust and security. Shipping beta compilers and source code archives is not the answer...
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
Okay, so it's "flamebait" to question Red Hat's trustworthiness -- but an article is "insightful" or "interesting" when criticizing Microsoft.
Ahhh. And people wonder why Slashdot is losing relevancy... (whoops, there goes more karma!)
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
Actually, unless something has changed in the past little while, debs do not support signing. The uploads are signed by the maintainers, but a user who downloads debs from one of the root debian mirrors or elsewhere has no way to verify where it came from. Conectiva has extended apt to handle signatures for rpms (with their apt-rpm system), but I don't think they've done anything with debs. Red Carpet verifies deb signatures by downloading a detached signature for every deb (thus maintaining compatability while also being able to verify at least Ximian's packages).
In a sense, this may be a hard problem to solve, simply because the debain project is so distributed -- there is no "debian package" key that can be used to sign all the debs that are available in the official distributions, and requiring a user to have each of the maintainers' public keys in their keyring is impractical. Perhaps there could be a debian packaging key that is automatically used to sign a package after a maintainer uploads it, but the security of this would be questionable.
The problem is that rpmfind employs a spider to find rpms and place them in the database. Thus, even if you know what the source URL is, anyone can create, say, a directory structure that looks like a Red Hat distro and place trojaned files in there -- then they can track downloads, and voila, an instant list of who (probably) installed what package. And this is something that can be trivially done today. The only way to guard against this is to verify signatures, something that I would say 90% of casual users simply don't when using rpm manually.
[Read with voice: "Five minutes to stage, people!", Starbucks-in-hand, legwarmers, hand-on-hip, etc.]
WTFWJD
Okay, what we really want to know is, what is RPMs answer to dselect (a lovely curses-based package browser, installer, and more.)? In my opinion, RPM systems lack mostly this. (And I freely admit to doing little research on the topic.)
WTFWJD
ATTENTION:
The point of having a moderated discussion forum is to discourage or at least filter out this sort of eye-turd. Moderators, please do your job.
WTFWJD
If there's a mechanism for signing rpm's (like there is for deb's) then that helps a little, if you have the public keys already to make sure nobody has messed with the rpm's you've downloaded. The big distros (Red Hat, Debian, etc.) should make some effort to get their key fingerprints widely publicized so people can check signatures easily.
If you compile from source, you are open to having a compilier that generates code with trojans or back doors. If you take binaries, you leave the door wide open.
But that doesn't even matter. Why not?
If you ask the NSA if they can break XYZ encryption system, their response is "We won't have to." They of course mean that the weak link is by far the user, not the software. If you are downloading updates, you are probably connected to some sort of network. So you spend all day setting up a firewall and blocking all sorts of traffic. But what happens when your pissed off friend walks up to your desk and reboots into single user mode? We should spend more time educating the users about what -behaviors- are putting them at risk, then we can worry about what kind of packages they are downloading. Atleast if some package contains some destructive code, we will all hear about it. But have you ever taped a password to your monitor? Which is worse?
Uninnovate - Only the finest in engineering.
in the slashdot posting.
Something like - "This article is aimed at sponge headed morons who don't know how to tie their shoelaces" would be nice. Then I wouldn't have wasted my time reading the article.
What is this guy talking about? My harddisk came with 7500 RPM... I didn't install it - In fact I'm pretty sure you can't download more RPMs for your harddisk... Or maybe it's the new OpenTurbo 1.0? ;-)
I'm too tired to be posting
Any technology distinguishable from magic, is insufficiently advanced.
Of course, most commercial entities already ship binary code packages with built-in vulnerabilities or exploits. They're called "bugs". (or, "Innovations", depending on which company you're talking about.)
I don't see how this is any different for RPM's than it is for any other way to add or update software, on any platform. People who downloaded "illegal betas" for their new Mac OS X Boxes are in the same boat. I don't think any of them were trojans, but you never know...
Stick to downloading from "trusted" sites (i.e. The Authors' or OS Vendors') as part of your overall plan for keeping your system healthy. This should be drilled into every computer user, from newbie to expert!
(Which Authors' and OS vendor's sites we should trust is an excersise left to the reader.)
I find that most "I compiled it from source because I don't trust binaries" is just a lot of macho willy-waving and 31337 nonsense.
Virtually none of the people spouting such crap had inspected the source for trojans, or were even capable of doing so.
Compiling from source got them nothing but more pain and hard work.
--Shoeboy
--Shoeboy
(posting anonymously to preserve my precious karma)
OK, so what if you do always compile your code first. So what? Unless you're an expert, you still won't find security problems. There's no benefit to compiling your own source code first if you can't read it.
It's not just just what can screw up the OS. You may get some thing that you don't even want to install.
I have no objection to install packages, if
OS/2 - because choice is a terrible thing to waste.
.. No more dangerous than making something from scratch, as root, that you haven't audited yourself.
Heh.
Do you like German cars?
Just one thing stands out to me - anyone who installs RPM's off the web or from anywhere other than the install or source CD's for the dist. better know what the hell they are doing, sources or not. If you second guess your source binaries you might as well be downloading shoddy windows software with broken uninstalls, etc...
This article is full of BS. Suppose you follow this guy's advice and compile the code from the source. How do you know the source doesn't contain a trojan within it? Yeah like people are going to do a line-by-line audit every time they upgrade/install a rpm.
Installing a binary rpm puts you at the same risk level as a source rpm, if downloaded from the same site. It's foolhardy for the author of that article to spread mis-information, making unsuspecting readers feel secure about something when in fact, the risk is still the same.
---------
Did you just fart? Or do you always smell like that?
eTrade SUCKS
I always prefer source because of config.h... most programs don't have it I know.. but when its there its nice to browse the features and options contained within.. and some times you find nice little gems.. like BitchX's NOTIFY_BITCHX_COM. It sends a packet to BitchX.com and lets them know how many people are actually using there client.. Am I really worried about them knowing where I IRC? Well.. not really.. I am really boring.. however, when I notice strange packets in my firewall's logs I don't start to think its more than it really is.. prevents me from having to go through every program (though this one would be fairly self explanatory) and figure out what was sending the data.
It is important to note also, you should download the signatures directly from the distributor of the software you are trying to validate.
DONT use mirrors to get the signatures or md5 sums... that is as insecure as not even checking them!
-EvilMonkeyNinja
a.k.a. Joseph Nicholas Yarbrough
Security Grunt by Day
Programmer by Night
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
Don't trust them.
/etc/shadow to some hotmail account.
.o file. Then you would compile their binary into the other binaries built from source *WITHOUT KNOWING*! Most spec files do not do a make clean before they build, and this (of course) could be taken out *because* it is open source. Open source solves a whole lot of problems... problems that are becoming more and more important every day. But it also opens up new problems that don't exist in commercial products. Don't be a OSS zealot... Most of the time you are wrong.
Believe me... I understand that main sites can me loaded. Never download from a site or mirror you don't trust. A few sites on my "trust" list:
ftp.ibiblio.org
ftp.redhat.com
ftp.slackware.com (ftp.freesoftware.com)
ftp.cdrom.com
One bad thing is that these are all *very* popular sites! Therefore, they are targets for someone who would want to do this. The upside is, they are highly maintained & secured.
Some say "source RPMs fix the problem!!"
I say "your full of crap!!"
A source RPM can be backdoored in both the sourcecode, or the rpm spec file. It could contain the exact same sourcecode that the main distribution contains, but have a modified spec file that emails
Source RPMs are not any more safe than RPM files. Sure, if the person was stupid, they may have included the source for the modified version of the trojaned code, but more than likly, they are going to compile that object statically, and put the original source files in the RPM *with* the
The only way you can know for certain that the file you have is unmodified is to use crypto. If you don't trust that Redhat/whoever will stop at nothing to be sure that you don't get backdoored software, you shouldn't be using thier products. That is one of the reasons I hate MS software. It is known for it's easter eggs/backdoors. It makes me uncomfortable.
A point to note... This is exactly the reason the US is going to abolish crypto laws. It will help protect both consumers, and corporations.
-EvilMonkeyNinja
a.k.a. Joseph Nicholas Yarbrough
Security Grunt by Day
Programmer by Night
-EvilMonkeyNinja
Mild Mannered Host by Day
Wild Hammered Programmer by Night
>To be extra careful, you should also sit down and
...and the rest of the source code
>read any patch files included with the source RPM,
Both DEB and RPM support signed packages, but at least most software installed on a Debian system over the Net is by apt-get, which uses specific sites to fetch most of the packages you'd ever want. On RPM based systems, I'm always resorting to a hunt for packages on rpmfind, where their origin is less clear.
SALAD BARF! DELI-DUMP SUSPECT NABBED
A gross-out gourmet was caught dumping human waste on a Midtown salad bar - and is suspected in more than a dozen similar stomach-turning incidents, police said.
Workers at the deli grabbed the feces-flinging fiend after they noticed him emptying two bottles of disgusting-smelling liquid onto food trays in the back of the store at around 5:40 p.m., police said.
Cops responding to the bizarre call arrested Arellano and confiscated the bottles, which were sent to the Health Department for testing.
"Oh, it makes me sick just thinking about it," said Alpine customer Dawn Riggins, a 33-year-old beautician from The Bronx. "What kind of person would do that? It's disgusting."
Arellano was charged with reckless endangerment, criminal mischief, criminal tampering and public urination.
And in a twist sure to make Midtown workers lose their lunch - or never eat it again - police said they are investigating numerous other incidents at eateries in Penn Station, Grand Central Terminal, and around 42nd Street.
Officials said Arellano has already been identified by witnesses as the man who recently tried to foul the food at Mike's Take-Away Deli in Grand Central, and will soon be charged in that case.
Other suspected victims of the dung-disher in the past few days include a Krispy Kreme, Zaro's Bakery, and Caruso's Pizza in Penn Station, police sources said.
Police are also investigating him for other alleged incidents, officials said.
Police said several proprietors witnessed what they thought was bizarre behavior by a man matching Arellano's description - while others had customers complain of foul odors coming from certain foods.
Deli customer Keshia Williamson said the incident explains why deli salads often taste like, er, garbage.
"I'm sure this happens at other delis, too," said the 21-year-old college student. "The person who did this is an animal. He could've gotten people sick.
"I'm not going to eat anything more from a salad bar."
_________________________
as title Does somebody know what "GnuPG signature" is?? Thanks in advance