You are not logged in.
These should always be inspected before ‘extracting’ as whilst not a virus,
malicious code could be lurking there:
"I always open the debs and check for suspicious post-install scripts
This is how to do that. …
Listing the files from a debian package using dpkg -c
dpkg is the package manager for debian. So using dpkg command you can list
and extract the packages, as shown below.
To view the content of *.deb file:
:
$ dpkg -c ovpc_1.06.94-3_i386.deb
dr-xr-xr-x root/root
0 2010-02-25 10:54 ./
dr-xr-xr-x root/root
0 2010-02-25 10:54 ./ovpc/
dr-xr-xr-x root/root
0 2010-02-25 10:54 ./ovpc/pkg/
dr-xr-xr-x root/root
0 2010-02-25 10:54 ./ovpc/pkg/lib/
dr-xr-xr-x root/root
0 2010-02-25 10:48 ./ovpc/pkg/lib/header/
-r-xr-xr-x root/root
130 2009-10-29 17:06 ./ovpc/pkg/lib/header/libov.so
.
.
.
-r-xr-xr-x root/root
131 2009-10-29 17:06 ./ovpc/pkg/etc/conf
dr-xr-xr-x root/root
0 2010-02-25 10:54 ./ovpc/pkg/etc/conf/log.conf
Extracting the files from a debian package using dpkg -x
Use dpkg -x to extract the files from a deb package as shown below.
:
$ dpkg -x ovpc_1.06.94-3_i386.deb /tmp/ov
$ ls /tmp/ov
ovpc
DEB files are ar archives, which always contains the three files — debian-binary,
control.tar.gz, and data.tar.gz. We can use ar command and tar command to
extract and view the files from the deb package, as shown below.
First, extract the content of *.deb archive file using ar command.
:
$ ar -vx ovpc_1.06.94-3_i386.deb
x - debian-binary
x - control.tar.gz
x - data.tar.gz
$
Next, extract the content of data.tar.gz file as shown below.
:
$ tar -xvzf data.tar.gz
./
./ovpc/
./ovpc/pkg/
./ovpc/pkg/lib/
./ovpc/pkg/lib/header/
./ovpc/pkg/lib/header/libov.so
.
.
./ovpc/pkg/etc/conf
./ovpc/pkg/etc/conf/log.con
"
[With acknowledgement to Blackwolf on ultimateeditionoz.com forum – sadly
the forum is no more].
There was an instance of a GNU/Linux theme uploaded to gnome-look.org
called Ubundows that had not been checked by Admin for that site; the file
once extracted executed ‘Unix’ commands to wipe the hard drive clean of all
content - YOU HAVE BEEN WARNED!
Offline
As a Cinnamon user I use GDebi if I want to install and view, for audit purposes, off-package Debs (including viewing their install scripts).
Much simpler.
Last edited by Marjorie (2020-11-11 00:02:54)
Offline
Well this is one of the (many) reasons installing packages from random websites / PPAs / blindly pasting commands from blog posts is considered a bad idea. Doubly so if you do it as root... But then if you're installing random .debs as root you are entirely responsible for your own mess.
the file once extracted executed ‘Unix’ commands
Orly, "Unix commands"... As opposed to some other kind of commands, or is that just to sound extra scary?
On a more constructive note, a great many archive utilities can open .deb archives in memory, such as KDE's ark or the good old midnight commander. Personally I find browsing .debs with mc a lot nicer than using dpkg to print the contents, unless I want to pipe the output of course.
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
Well this is one of the (many) reasons installing packages from random websites / PPAs / blindly pasting commands from blog posts is considered a bad idea. Doubly so if you do it as root... But then if you're installing random .debs as root you are entirely responsible for your own mess.
swarfendor437 wrote:the file once extracted executed ‘Unix’ commands
Orly, "Unix commands"... As opposed to some other kind of commands, or is that just to sound extra scary?
On a more constructive note, a great many archive utilities can open .deb archives in memory, such as KDE's ark or the good old midnight commander. Personally I find browsing .debs with mc a lot nicer than using dpkg to print the contents, unless I want to pipe the output of course.
I avoid posting the code here to discourage miscreants but it was the code used to remove all contents of the hard drive akin to removing a directory. When I was a moderator on another forum we had spammers posting the same code who had circumvented the phpBB forum as it then was with the heading 'How to speed up your Linux install'.
And bearing in mind opendesktop.org and all its offshoots (Pling.com, KDEdesktop, gnome-look.org all have themes which people may look at and install without deference to any PPA. Any other safe sources for themes?
Last edited by swarfendor437 (2020-11-11 17:03:27)
Offline
Instead of installing binary debs compiled elsewhere, build that stuff from its deb-sources on your target system or even better, do it on a throw away VM.
Last edited by yeti (2020-11-11 20:37:02)
Online
I extract .deb's with the right mouse button menu dialog using Dolphin file manager, It allows me to check out all the parts if I am having trouble, especially when the bin file gets put in a distant galaxy. or something is deleted when I don't know why.
pic from 1993, new guitar day.
Offline
I avoid posting the code here to discourage miscreants
Presumably just some variation on rm -rf /* or an obfuscation of such then. IMO if you execute commands from some random post as root without understanding what they do, you deserve what you get.
If I instructed you to set your PC on fire, you'd rightly ignore that as well, would you not?
opendesktop.org and all its offshoots (Pling.com, KDEdesktop, gnome-look.org all have themes which people may look at and install without deference to any PPA.
Themes are pretty much always installable without root privileges (and so cannot wipe the whole drive and can be tested with a throwaway account), rarely have any call at all to be packaged as a .deb, and are usually either human-readable to begin with or come with source code you can inspect.
Most theme engines have an explicitly non-executable format anyway, so if something is packaged as a .deb or an installer script, you'd be wise to ask yourself why that is...
In general, the only "safe" source for any precompiled binary software is the distro maintained repository, and that's exactly as safe as the maintainers are vigilant. Any "user contributed" stuff is usually completely unchecked, because when it comes to FOSS in general it's anticipated that the user can and will inspect the source code.
Instead of installing binary debs compiled elsewhere, build that stuff from its deb-sources on your target system or even better, do it on a throw away VM.
That is indeed the better option, not only do you get a chance to see the source, you also ensure the resulting binary is linked against the correct libs.
Personally I'd consider a VM overkill (though useful for building packages for other distros), fakeroot and the debian packaging tools do a pretty good job of ensuring you only need root for the final installation, so you can do all building etc. as a dedicated unprivileged user.
All those people who hose their systems messing with sources.list or installing .debs from random places could have avoided that pain by spending the 10 minutes to learn how to rebuild a package from source, it's not difficult.
Last edited by steve_v (2020-11-12 00:06:34)
Once is happenstance. Twice is coincidence. Three times is enemy action. Four times is Official GNOME Policy.
Offline
extract the content of data.tar.gz file
The control.tar.gz (or control.tar.xz) should also be extracted to examine the contents of any installation scripts. Note that tar auto-extracts these days so only xf is needed to unpack any tarball regardless of the compression paradigm.
Brianna Ghey — Rest In Power
Offline