Re: RFE: Could crc32 be included in the debian live/installation disk?
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.
> >> 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.
Now if you *do* trust the OS, there are some interesting possibilities,
starting with filesystem snapshots.
> No, you do not own your computers or any networked device you use,
> but you have an easy way to check if the data in it has been changed,
> when and how. I have been noticing all along how data has been left in
> my computer (definitely more than cookies) and how my file systems
> have been altered. Even the idea of an encrypted hard drive is a joke
> once you open a browser.
>
> >> 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.
> >> 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.
> >> I would like to remove all cookies
>
> >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.
> so if you don't accept them they will not show you pages,
And if a site implements such policy it's not worth your time.
> 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 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?
> > Checksumming of /lib* /usr and the like is done by every Debian package
> > already.
>
> at installation, right?
Nope. Every package you install has checksums. It does not matter if
it's a freshly installed package or it's an updated one. Checksums are
there. Waiting.
> but, again, this is not what I am talking
> about. Debian should offer an easy way to baseline its installation on
> an ongoing basis.
An install media is signed.
An installation process is reproducible and deterministic.
Hence the OS that comes from the process is initially deterministic too.
But prove me wrong. File a wishlist bug report and share its number with
the list.
> > Checksumming of /boot is an interesting idea (AFAIK you can validate
> > the kernel only, but that's it), but I'd use something like dm-integrity
> > for this.
>
> Heck I would even dump the BIOS
But they do not let you dump the full content of the BIOS ("pwned", see
above). Ever heard of Intel ME? Or AMD PSP?
You can do it with SPI programmer, of course (I did, several times). And
maybe even flash it back without bricking your motherboard.
Reco
Reply to: