But I don't need to read all the code for the Firefox package to make sure that it is secure. I only need to audit the maintainer scripts (the {pre,post}{inst,rm} scripts that are contained in its Debian package) and the permissions of the files in the package (check there are no setuid binaries, for instance) to make sure that it is secure....
I just did that right now. It took about thirty seconds.
Not that I needed to, since the package itself came from the Debian archive and is therefore safe (or at least, if the Debian archive is compromised, I would have much more important things to worry about...)
I am glad that they are not. Bundles are fine if you only have to keep track of one or two programs, but I would sure miss apt-get upgrade if I ever had to use a Mac myself.
It is a failing in the RPM format. If it was a deb you could have run dpkg-deb extract foo.deb/tmp/blah. Or ar x foo.deb; tar -zxf data.tar.gz. I believe there is an rpm2cpio utility that will let you do something similar with an RPM.
It is important any time you try to perform an operation that you lack the priviliges to do.
Hopefully in a few years, all software will have been rewritten properly, that is, as it would have been in the first place if the developers were at all competant: to function without requiring write access to the entire filesystem and registry.
If you really *must* install an RPM or Deb from an untrusted source, you can easily extract its contents and view the package's contents along with any maintainer scripts that it contains.
How can you do this for a binary blob of a third party setup program on a windows system?
Once you have run a program via sudo, can a mailcious program not inject further keystrokes into your terminal application and therefore run anything it wants?
Or with the default sudo configuration (without tty_tickets), can a malicious program not simply wait for you to authenticate yourself to sudo, and then run anything it wants via sudo from then on?
Or more fun: can't a malicious program wait for your to run your terminal emulator and run sudo, and then listen for further keypresses, steal your password, and use it as it wants from then on?
Privilige elevation is trivial on most systems once malicious software is running on the system.:(
The main idea is to let companies know that it is possible to release hardware specifications in an NDA-esque way to kernel developers *without* having to publish their/precious/ secrets. Chances are that, the secrets are not *within the code* but developers need to know about them to implement the drivers.
The NDAs that Grek K-H talked about were of the kind that would keep details about the release of products secret until a specific date (e.g., product launch). I don't think he was talking about the kind of NDAs that maintain secrecy about hardware implementation details, etc. Such NDAs are harmful because they prevent the driver from being modified once the original maintainer dies, loses interest, etc. They should be rejected with prejudice.
Or you could run Debian, and install the apache2, libapache2-mod-php5, libapache2-mod-perl and php5-mysql packages. And then scream because you are using PHP and MySQL.
That's a shame. If you want to investigate further, you might have more luck if you amend boot.ini to look for the installer (or grub, or whatever bit is failing) on the other drive. And/or contact debian-boot@lists.debian.org so that they know that it doesn't work if Windows isn't installed to the primary master disk.
I've burned more copies of Windows to slipstream in hot fixes, service packs and new device drivers, all because MS are too retarded to make Windows try to load drivers off anything other than a goddamn floppy disk.:)
It is seriously not trivial. The steps required are arbitrary and complex. The whole thing is very poorly designed. Or you have to use some dodgy bit of third party software. Until Windows fixes this it just won't be ready for the desktop.
Are you kidding? This reminds me of the old adage about the 20 year old broom. 7 new handles and 12 new brushes and it still cleans as well as it did when it was new.:)
Another option is backports.org. Or simply backporting the packages that you want from unstable to your stable system yourself. Debian's packaging tools make this very easy (dpkg-checkbuilddeps and apt-get build-dep among others).
Frankly, in this area, "UNIX/POSIX" compatibility can go fuck itself. Does POSIX even specify audio output interfaces? Did "UNIX" (System V? BSD?) even ever have sound output?
ALSA is not only desired by high-end audio users. All users want basic features such as the ability for two programs to use the sound card at the same time. ALSA provides this (part of alsa-lib) and OSS does not.
ALSA is not necessarily Linux-specific. As far as application programs are concerned, ALSA is merely a stable program library (libasound.so.2). Nothing stops you from porting alsa-lib to another platform, or implementing another library with the same interface. If would probably be quite easy to get it working today, by configuring alsa-lib to use the pcm plugin that talks to Pulse Audio server, which can output to OSS or many other sound systems/devices/interfaces.
Finally, if you bothered to do the most basic research about the i386 GNU/Linux Flash player, you would have found out that it is Adobe's plan to separate out the GNU/Linux-specific parts of the player into a separate library with a stable interface. Anyone (who uses i386) would then be able to implement their own platform-specific replacement and thus get the Flash player running on their platform.
s/web browser/propritary browser plugin that uses an obsolete/deprecated audio output system/
Fortunately Flash 9 is now available (at least for i386) and so this particular piece of config-file cargo-culting can by forgotten, and sink back to the depths of the Pit from whence it came.
Slashdot Mirror
But I don't need to read all the code for the Firefox package to make sure that it is secure. I only need to audit the maintainer scripts (the {pre,post}{inst,rm} scripts that are contained in its Debian package) and the permissions of the files in the package (check there are no setuid binaries, for instance) to make sure that it is secure. ...
I just did that right now. It took about thirty seconds.
Not that I needed to, since the package itself came from the Debian archive and is therefore safe (or at least, if the Debian archive is compromised, I would have much more important things to worry about...)
I am glad that they are not. Bundles are fine if you only have to keep track of one or two programs, but I would sure miss apt-get upgrade if I ever had to use a Mac myself.
It is a failing in the RPM format. If it was a deb you could have run dpkg-deb extract foo.deb /tmp/blah. Or ar x foo.deb; tar -zxf data.tar.gz. I believe there is an rpm2cpio utility that will let you do something similar with an RPM.
It is important any time you try to perform an operation that you lack the priviliges to do.
Hopefully in a few years, all software will have been rewritten properly, that is, as it would have been in the first place if the developers were at all competant: to function without requiring write access to the entire filesystem and registry.
If you really *must* install an RPM or Deb from an untrusted source, you can easily extract its contents and view the package's contents along with any maintainer scripts that it contains.
How can you do this for a binary blob of a third party setup program on a windows system?
http://rofi.pinchito.com/eiciel/?s=5
When was the Debian archive compromised?
Once you have run a program via sudo, can a mailcious program not inject further keystrokes into your terminal application and therefore run anything it wants?
:(
Or with the default sudo configuration (without tty_tickets), can a malicious program not simply wait for you to authenticate yourself to sudo, and then run anything it wants via sudo from then on?
Or more fun: can't a malicious program wait for your to run your terminal emulator and run sudo, and then listen for further keypresses, steal your password, and use it as it wants from then on?
Privilige elevation is trivial on most systems once malicious software is running on the system.
Hibernate? Or install a decent operating system that has some kind of session management...
Or you could run Debian, and install the apache2, libapache2-mod-php5, libapache2-mod-perl and php5-mysql packages. And then scream because you are using PHP and MySQL.
That's a shame. If you want to investigate further, you might have more luck if you amend boot.ini to look for the installer (or grub, or whatever bit is failing) on the other drive. And/or contact debian-boot@lists.debian.org so that they know that it doesn't work if Windows isn't installed to the primary master disk.
;)
Or just use a CDRW.
Have a filter automatically forward the message to their postmaster with a complaint prepended? :)
What a coincidence, http://goodbye-microsoft.com/ came up a couple of days ago. You can use it to boot the Debian installer from Windows directly. :)
I've burned more copies of Windows to slipstream in hot fixes, service packs and new device drivers, all because MS are too retarded to make Windows try to load drivers off anything other than a goddamn floppy disk. :)
It is seriously not trivial. The steps required are arbitrary and complex. The whole thing is very poorly designed. Or you have to use some dodgy bit of third party software. Until Windows fixes this it just won't be ready for the desktop.
Probably ATI's IP, in the form of patents.
Are you kidding? This reminds me of the old adage about the 20 year old broom. 7 new handles and 12 new brushes and it still cleans as well as it did when it was new. :)
Another option is backports.org. Or simply backporting the packages that you want from unstable to your stable system yourself. Debian's packaging tools make this very easy (dpkg-checkbuilddeps and apt-get build-dep among others).
I think the sickening reliance on the public sector would discourage most of those fleeing America.
Frankly, in this area, "UNIX/POSIX" compatibility can go fuck itself. Does POSIX even specify audio output interfaces? Did "UNIX" (System V? BSD?) even ever have sound output?
ALSA is not only desired by high-end audio users. All users want basic features such as the ability for two programs to use the sound card at the same time. ALSA provides this (part of alsa-lib) and OSS does not.
ALSA is not necessarily Linux-specific. As far as application programs are concerned, ALSA is merely a stable program library (libasound.so.2). Nothing stops you from porting alsa-lib to another platform, or implementing another library with the same interface. If would probably be quite easy to get it working today, by configuring alsa-lib to use the pcm plugin that talks to Pulse Audio server, which can output to OSS or many other sound systems/devices/interfaces.
Finally, if you bothered to do the most basic research about the i386 GNU/Linux Flash player, you would have found out that it is Adobe's plan to separate out the GNU/Linux-specific parts of the player into a separate library with a stable interface. Anyone (who uses i386) would then be able to implement their own platform-specific replacement and thus get the Flash player running on their platform.
I think you should have stayed with your distribution-supplied kernels...
Why wouldn't you just get the module included upstream?
s/web browser/propritary browser plugin that uses an obsolete/deprecated audio output system/
Fortunately Flash 9 is now available (at least for i386) and so this particular piece of config-file cargo-culting can by forgotten, and sink back to the depths of the Pit from whence it came.