Re: debcheckroot v1.0 released
Elmar Stellnberger:
>>> As Debian package headers do not use to be signed
>> I think you are mistaken here or maybe I misunderstand. When you have a
>> Debian medium you trust (such as a Live DVD from a trusted source), we
>> can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as
>> trusted.
>> For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and
>> http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed
>> by the Debian archive key.
> Ah, many thanks for that advice. I had just looked at the Release file
> which was and still is not signed (am I right?! - have just checked this
> file).
You can either directly use InRelease or what I find cleaner, verify
Release using Release.gpg.
> However the InRelease file is signed and should contain all the
> relevant information: a signature for every Packages.gz which in turn
> does contain checksums for every package.
I think the goal is to keep (In)Release as small as possible to save
server load. But that is okay.
The (In)Release file authenticates the Packages (ex:
main/binary-i386/Packages). And the Packages file therefore contains a
signed [indirectly, but sufficient!] signature [sha sum] of all packages.
Ex:
Package: python-stem
...
Filename: pool/main/p/python-stem/python-stem_1.1.0-1_all.deb
...
SHA256: 4cdf5d54f230390452181007b0619fe7123328c95373feb73c7c4138a347a34e
...
And after extracting for example python-stem_1.1.0-1_all.deb, you can
create sha sums of it. Then compare. Sure, having a shasums file
downloadable and listed inside Packages file is a missing feature.
As far I can see, there are currently no breaches in the verification
chain. Sure, there is room for improvements, such as also checking
signatures against the maintainer, not just Debian archive key,
reproducible builds, random rebuilds checking against distributed
community (DHT) and more. Anyway, for purposes of debcheckroot, the
current verification methods should suffice.
>
>> This approach seemed futile to me. At least for now. There are too many
>> files, that are automatically generated created by postinst scripts. For
>> example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically
>> generated. Even worse, the file is non-deterministic.
> Well, of course debcheckroot is not a 'silver bullet' nor an ultimate
> remedy.
Sure. This wasn't meant as a criticism. I applaud you for writing this
tool! Because I already do imagine the future. When OEM mode and
reproducible builds become standard features, these are components and
debcheckroot is one component. debcheckroot will then become the 'silver
bullet'.
> However I have already used it to spot rootkits on some core binaries
> and the glibc which did not hide in *.pyc or other files generated on
> the fly.
Sure.
> As far
> as that would only concern *.pyc one could even consider to remove all
> these files
That will be difficult without OEM mode. There are loads of auto
generated files and loads of non-deterministic auto-generated files.
Anyway. This issue will be solved, when dpkg gets a "reset to prestine"
/ OEM feature.
> Yes, perhaps you are right. However most people whom I know have not got
> that, yet ('...').
I know. :) Because I once raised the question, if a tool such as
debcheckroot exists in Debian and debsums was recommended.
Reply to: