# Is there a program like ccleaner and bleachbit for FreeBSD?



## unbalancedskunk (Nov 19, 2022)

I need a program like this.


----------



## Partmedia (Nov 19, 2022)

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 (Nov 19, 2022)

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 (Nov 19, 2022)

Alain De Vos 
for example
 last opened documents etc.


----------



## angry_vincent (Nov 19, 2022)

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


----------



## Alain De Vos (Nov 19, 2022)

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


----------



## CuatroTorres (Nov 19, 2022)

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









						About FreeBSD Ports
					

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.




					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 (Nov 19, 2022)

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


----------



## Alain De Vos (Nov 19, 2022)

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


----------



## unbalancedskunk (Nov 19, 2022)

Alain De Vos said:


> Last documents using which application?


Right.


----------



## zirias@ (Nov 19, 2022)

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 (Nov 19, 2022)

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


----------



## CuatroTorres (Nov 19, 2022)

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 (Nov 19, 2022)

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 (Nov 19, 2022)

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@ (Nov 19, 2022)

quakerdoomer said:


> 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.


quakerdoomer said:


> 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 (Nov 19, 2022)

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 (Nov 19, 2022)

zirias@ said:


> 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 (Nov 19, 2022)

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 (Nov 19, 2022)

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


----------



## zirias@ (Nov 19, 2022)

Alain De Vos said:


> 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)


Alain De Vos said:


> 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).


Alain De Vos said:


> 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@ (Nov 19, 2022)

quakerdoomer said:


> 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 (Nov 21, 2022)

quakerdoomer said:


> 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


----------

