Re: RFE: Could crc32 be included in the debian live/installation disk?
Hi.
On Wed, Oct 09, 2019 at 04:26:05PM +0200, Albretch Mueller wrote:
> On 10/8/19, Reco <recoverym4n@enotuniq.net> wrote:
> > On Tue, Oct 08, 2019 at 04:34:17PM +0200, Albretch Mueller wrote:
> >> >> this is a hash algorithm that is implemented of the chips anyway, it
> >> >> is the fastest of them all, used by synch (is it?) and it is crucially
> >> >> helpful when data integrity is very important.
> >>
> >> >And it's also one of those broken checksum algorithms which makes it
> >> >easy to replace a part of file while keeping a checksum intact.
> >>
> >> Well, I wasn't claiming CRC32 was fail-safe, what I actually meant is
> >> that data integrity would be based on:
> >>
> >> a) two -fast- and "reasonably" safe signature utilities which are
> >> based on -different algorithms-
> >
> > CRC32 fails here. Key is "reasonably" safe.
> > If you'd propose MD5 and SHA256 (Debian does it for the every package in
> > repostory) - that would be considered OK.
>
> OK, great! MD5 and SHA256 would it then be. They don't even need to
> be computed, so, right after installation Debian should:
>
> 1) give users the option to keep a first baseline, including the
> hardware on which the installation was made, saved into files which
> would be tar'ed and compressed in a well-defined, standard way;
>
> 2) whenever users feel like checking their device, the same DVD live
> used for the initial installation could be used to check the current
> "moment" of the OS and check the difference with previous diff deltas;
>
> 3) if differences are detected where and if they matter (not just a
> new file), but, say inside a critical directory or file (all those
> should be declaratively set), a hexviewer would be launched showing
> the differences between the two files. Probably, that could be
> implemented out of the box with IDS what I am pushing for is making it
> an integral and optional part of Debian installation
No objections here.
> >> >> Does Debian internally have the kind of check pointing that Windows
> >> >> does with which you could revert the state of an OS to a operating
> >> >> "moment" you can manage?
> >
> >> >Sure. And it's called "off-host backup", a concept which predates both
> >> >Linux and Windoze. As you helpfully mention below, "you do not own your
> >> >computer", so "in-host" checkpoints are untrusted by your very own
> >> >definition.
> >>
> >> I think you are twisting a bit my point here in a confusing way.
> >
> > Nope. If you need an immutable OS state (be it a backup, a snapshot or
> > whatever), you do not store it on the same host. If you do not trust the
> > OS (or the hardware), there's no reason to trust a snapshot of its state.
>
> I meant you would keep that file in a pen drive you never connect to
> the Internet adn that baselining utility should be part of the Debian
> installation DVDs.
Unsure if it still on the first installation DVD, but let's take good
old rkhunter. Using it for its primary purpose (i.e. searching for
rootkits) is overly optimistic these days. But it's secondary purpose is
IDS. So, take a look at this (file goes on and on and on):
# head /var/lib/rkhunter/db/rkhunter.dat
Version:2019100800
Host:xxx
Arch:x86_64
OS:Debian GNU/Linux 10 (buster)
Prelinked:No
Hash:/usr/bin/sha256sum
Pkgmgr:
Attributes:Stored
FormatVersion:1
File:0:/usr/sbin/adduser:f13ad85950859c760c12b090241c723103a9ce9c1034b03db695a4b39fa5623c:394033:0755:0:0:34518:1537038759::0::
Here you have a file contents checksum, last modification date, file
attributes and everything else to answer if the file was modified in any
way after the last rkhunter run.
As I wrote earlier - if you need it done, use an IDS. There's no need to
implement your own.
> >> >> the reason why I push for the crc32 algo is because instead of using
> >> >> sha?sums which are much slower, I would rely on both crc32 and md5sum,
> >> >> when I have to baselines the 200+K files included in the base install
> >> >> that comes with the installation disk.
> >>
> >> >A noble if misguided effort. Surely you're aware that Debian project
> >> >provides both install media and LiveDVDs along with checksums of them?
> >> >They did this job for you already.
> >>
> >> Yes, but where is the GUI based data integrity check?
> >
> > Never felt the need for one.
> > I fail to see what's so hard in running:
> >
> > md5sum -c <checksumfile>
> > sha256sum -c <checksumfile>
> >
> > But maybe some other list participant can help you here.
>
> I never said it was hard I am talking about running such utilities on
> hundreds of thousands of files, but you clarified to me this is not
> even necessary, since such sums are included in the deb file.
>
> By the way, if you were to recommend the best/most exhaustive and
> reproducible documentation about how Debian's packaging system works,
> that would be?
Barebone basics:
apt(8), aptitude(8), dpkg(8).
Something that every maintainer should know (same as maint-guide package):
https://www.debian.org/doc/manuals/maint-guide/
For enlightened ones among us (I don't pretend to be one):
https://wiki.debian.org/ReproducibleBuilds
> Also, the mindset/"philosophy" behind it.
That's harder. Maybe apt manual and aptitude manual?
apt is a software with decades of history, I suspect that the original
design document (if it's even existed) is either lost or transformed
numerous times.
> Maybe I could find the time to do a more elaborate "proof of concept"
> and submit it for your consideration or heck even start yet another
> Debian knock off.
Wishing you luck.
> >> >> Nowadays you can safely assume that you do not own your computer
> >>
> >> > And refraining from using certain processor architectures and non-free
> >> > operating systems ...
> >>
> >> Your joke is beside my point
> >
> > I'm dead serious. If you're using x86 newer than Pentium the First,
> > consider yourself pwned, because you do not control the hardware, they
> > do. The only question is whenever it's a good, democratic US control, or
> > totalitarian Chinese one.
>
> Did you just say: "The only question is whenever it's a 'good,
> democratic US control', or totalitarian Chinese one."?
>
> That was some side sarcasm to keep the conversation a bit livelier,
> amusing, right?!?
I admit that my choice of epithets was poor. What I meant to say is that
if you're using x86 you do not control the hardware - someone else does.
Whenever this someone is working for US or Chinese government is hardly
relevant to the further discussion.
> >> >Why accept them in the first place then?
> >>
> >> because "cookies" have been turned into an all encompassing black
> >> mail and tracking mechanism,
> >
> > Spare me the usual scarytales, please. Whichever browser you're using
> > should allow you to set a whitelist policy on cookies (as opposed do
> > brain-dead blacklist policy by default).
> > It may break some authentication, sure, so whitelist domains until it
> > ain't.
>
> Here you are just talking about cookies way more pernicious is
> javascript. Managing javascript code without pages containing them
> manifestly offering a "flight letter" (kind of the way java web start
> does it with their manifests) would take away your life
It did not so far.
> >> let you get to your email account, ...
> >
> > LOL. Why exactly should I deny myself the access to my own e-mail on my
> > server? Also, both SMTP and IMAP do not use cookies last time I've
> > checked.
>
> I was talking about my gmail account
Back in the day then I had one I did not use a browser for that.
> >> I hate JS for more than one good reason, they slow your Internet
> >> experience, dump of all kinds of commercial cr@p on you,
> >
> > ... But you do not disable it because?
>
> I do, but there is not a way to disable its functionality in a
> detailed way,
Noscript, ScriptSafe, Ublock - from inside the browser.
Squid, e2guardian - from the outside.
Reco
Reply to: