>> 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- b) that data will be used anyway When you are dealing with the process of managing such relatively large amounts of data, you need something as fast as possible. Debian install already takes some time. It is extremely unlikely (verging on impossibility) that you could corrupt two different signatures of the same data while at the same time keeping the file size intact and on top of that that data will functionally relate to other data and ultimately cross someone's life, mind. Say for example, code (as it is the case of Debian packages) most probably that altered package will not compile and if it does how could it functionally relate to the other pieces of the "system"? >> I like to do baseline checks when I first install an OS base and when >> I upgrade it. >apt install debsums >Every Debian package contains MD5 checksums of the files it provides. >All you need to do is to check them on a routine basis. >If you need a better checksum algorithm, you use IDS, not homegrown >scripts. thank you and yes the MD5 checksums of the file (to which some other checksum could and should be added) could be used to produce a baseline at the end of the installation (as a seamless option to the user), which user could save some place and then when user feels like checking his base installation, user would go to the Debian live initial installation DVD and just run that "data integrity" check utility to the new baseline of the system and compare it to what was kept before. Of course, that could be easily be misused for some nefarious intentions ;-). I am talking here only about data integrity. >> 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. 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? >> 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 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, so if you don't accept them they will not show you pages, let you get to your email account, ... One of the problems of the Internet is that they can lie to "We the people" but we can't lie to them. Imagine a java based (so that it works on most OS) seamless Internet proxy based on already existing technologies such as an HTML parser and Nashorn used to "Yes, sure!" them and send them all kind of well-crafted bogus data. I hate JS for more than one good reason, they slow your Internet experience, dump of all kinds of commercial cr@p on you, ... that utility would take care of that. It would be like reader mode on steroids, they think they are making you view their bsing ads while you arent seeing or being bothered by any of it ... I could imagine some idiots telling me that that would be "against the law", some "user agreement", ... that "capitalism would go down if such a thing existed". If I want to buy some toilet paper I would go and get it I don’t need some so-called "AI"-based bs "reminding me" or, and this is not a figurative joke, that actually happened to me, ask my doctor about a colonoscopy via email (a google "don’t be evil" account) and when the page refreshed they told me all the colonoscopy clinics in my area ;-) . . . no, quite literally, it is not even "your ass" anymore >> Anyway, here is some crappy proof of concept to what I am suggesting. >> That kind of utility could be made part of the installation: > Checkpointing the contents of volatile directories such as /run and /tmp > won't do you any good. thank you I was also having problems with write only files which I should take off the baseline > Checksumming of /lib* /usr and the like is done by every Debian package > already. at installation, right? but, again, this is not what I am talking about. Debian should offer an easy way to baseline its installation on an ongoing basis. > 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 and make a copy of the boot record before and after grub installs >> Any ideas about how that kind of base lining could be improved, >> streamlined? >Did you already evaluate existing IDS like the following ? > https://packages.debian.org/stable/samhain > https://packages.debian.org/stable/systraq > https://packages.debian.org/stable/tiger > https://packages.debian.org/stable/tripwire I see my idea as way simpler than actively having to use and mind IDS > (The game of mutual fooling and spoofing needs lot of experience.) In my case I do what Linus Torvalds does. I never effing ever connect my workhorse computer to the Internet. That does it in the simpler possible way. If they own your attention they own you, but it is still somewhat annoying connecting to the Internet every time with a live DVD. I am just trying to find a less hassling way of dealing with reality and handling that now illusive thing they used to call "security". lbrtchx
