Is there a program like ccleaner and bleachbit for FreeBSD?

[unbalancedskunk]

I need a program like this.

 

[Partmedia]

No, not really. Unlike Other Operating Systems (TM) where you need this though, you don't really need this on FreeBSD.

If you install/upgrade a lot of packages, a periodic:

sudo pkg clean

Will suffice.

 

[Alain De Vos]

Interesting question.

Which temporary/removable data do you want to remove ?
I can think of:

rm -vfR /tmp/*
rm -vfR /var/tmp/*
rm -vfR  /usr/home/myuser/.cache/*
pkg clean -a

 

[unbalancedskunk]

Alain De Vos
for example
last opened documents etc.

 

[angry_vincent]

maybe, https://qarmin.github.io/czkawka/
it is available in ports and as pkg

 

[Alain De Vos]

I don't find czkawka usefull unless you have many "duplicate documents".
A log of last opened documents can exist per application...
You don't want to automatic delete last opened files, because you might need them.
The following command will show last modified files,

gfind . -printf "%T@ ||| %Tc ||| %p\n" | sort -rn | less

you can take " head" & pipe to "rm" to remove them.

To find duplicate files there is,

FreshPorts -- sysutils/fdupes: Program for identifying or deleting duplicate files

FDUPES is a program for identifying or deleting duplicate files residing within specified directories.

www.freshports.org

 

[YYY__]

Ccleaner contains tools that are too tied to the underlying system.

FreeBSD Ports Search

ports.freebsd.org

Searching for "sweeper" I get a cleaning tool for KDE, and a generic one with the word "wipe". Another for "clean" in sysutils.

Will /var/spool and /usr/var/spool contain sensitive information?

 

[unbalancedskunk]

Alain De Vos i wanted to mean log of last documents and things like that.

 

[Alain De Vos]

Last documents using which application?
[PS: I know KDE-Ubuntu-Linux is able to log many things. Even those you don't want...]

 

[unbalancedskunk]

Last documents using which application?

Right.

 

[zirias@]

On a system with a sane pkg(8) management and following a standard filesystem hier(7)archy, such tools are a whole lot less useful. Things to look at on the system level are temporary files (just use tmpfs(5) for /tmp, or enable automatic cleanup on boot), and maybe left-over databases and other transient files (/var/db and other locations below /var) or configurations (/usr/local/etc) for software you removed. These are simple enough to find yourself if you really want to delete them.

So, all that's left is your user's home directory. It's much more accessible than e.g. the user part of Windows' "registry", just look out for dotfiles.

 

[Alain De Vos]

Cleaning windows can be diffucult.
Cleaning Linux easy.
Cleaning FreeBSD super easy, because the places files are written are known.

 

[YYY__]

Something like:

~/.local/share/RecentDocuments for KDE5
and
~/.recently-used for Xfce

Applications like LibreOffice, Gimp, etc., can store their own list.

 

[Alain De Vos]

For firefox there is .cache.
For chrome there are many directories. I even don't know them. It's just to collect information about you.

 

[quakerdoomer]

Also, always use srm with Guttman wipe instead of plain bland rm
Now-a-days you can safely do that on SSDs as well.
For 100% peace of mind maintain access to large powerful magnets, an acid vat, a drill machine, heavy boulders and a thaumaturge on a retainer.

 

[zirias@]

Also, always use srm with Guttman wipe instead of plain bland rm
Now-a-days you can safely do that on SSDs as well.

No. Although it's very likely to overwrite all data, in presence of a wear-balancing drive firmware (also using spare cells), there can never be a guarantee.

For 100% peace of mind maintain access to large powerful magnets, an acid vat, a drill machine, heavy boulders and a thaumaturge on a retainer.

For 100% peace of mind, always apply full-disk encryption before ever using the drive. With spinning disks, overwrites with random data (no excessive passes needed) works, with SSDs with wear-balancing firmware, you can never be sure. But encrypted data without the key is just random noise for sure.

 

[quakerdoomer]

FDE goes without saying. Was discussing a scenario wherein someone already has access and is digging through your now unlocked disk.
About FDE - it's a shame the default FBSD installer only supports full-disk encryption and not full custom partition encryption using the guided installation wizard. That would really come handy for those who dual boot other OSes. BTW if what is the inode (UFS) equivalent for ZFS?

 

[Alain De Vos]

No. Although it's very likely to overwrite all data, in presence of a wear-balancing drive firmware (also using spare cells), there can never be a guarantee.

For 100% peace of mind, always apply full-disk encryption before ever using the drive. With spinning disks, overwrites with random data (no excessive passes needed) works, with SSDs with wear-balancing firmware, you can never be sure. But encrypted data without the key is just random noise for sure.

I don't agree. Even without disk-ecryption there is boot-time without encryption.
This means disk-encryption is as vulnerable.
So just put encryption on your vulnerable data.

 

[quakerdoomer]

You are talking about evil-maid attack? Using /boot from the disk you encrypted is not wise.. must use an external medium.

Follow-up question regarding UEFI.

".. Ideally each step of this process would involve a cryptographic handshake; boot1.efi would verify loader.efi which would in turn verify the kernel, thereby ensuring that only authorized code is run. Currently there is no support for these verifications. However, the goal of securely booting the kernel can still be achieved. "

FreeBSD UEFI Secure Boot | FreeBSD Foundation

1. Introduction Secure boot provides a way to ensure that only authorized EFI binaries are loaded by a computer's firmware. This ensures that no malicious code can run before the operating system is loaded. This document describes one method of securing FreeBSD's boot process. FreeBSD's regular...

freebsdfoundation.org

Is this still the situation?

 

[quakerdoomer]

If the above is still true then what does UEFI for FreeBSD solve??

 

[zirias@]

I don't agree. Even without disk-ecryption there is boot-time without encryption.

Uhm what? You probably mean you'll (normally) have an unencrypted bootloader on the disk. On a modern FreeBSD system, that would be an ESP containing nothing but (stock) loader.efi(8)

This means disk-encryption is as vulnerable.

That makes no sense, unless you talk about offline attacks with physical access fiddling with that boot loader. A whole different topic (and even worse with just some encrypted files on your disk).

So just put encryption on your vulnerable data.

A running system offers tons of possible leaks (swap, temporary files, ...). Only with FDE, you close them all. Apart from that, the topic was "wiping", which isn't reliably possible with modern SSDs. Throwing away the encryption key is reliable.

 

[zirias@]

If the above is still true then what does UEFI for FreeBSD solve??

Uhm, booting?

Yes, "CSM" will vanish eventually, there are already systems not supporting it.

 

[bob2112]

Also, always use srm with Guttman wipe instead of plain bland rm
Now-a-days you can safely do that on SSDs as well.

Gutmann's patterns were designed for drives that were being decommissioned in the 1990's; they are not relevant to modern drives. Gutmann himself recommended one or two passes with random data for later drives.

I don't follow what you mean about SSDs. When you overwrite a logical sector on an SSD you write into a different physical block for each pass. If you Gutmann erase an entire SSD the chances are that you would erase everything. For an individual file the chances are that the original data is still there