Eraser 6 RC2

Status
Not open for further replies.
Joel

Joel

Active Member
Eraser 6 Release Candidate 2 is released, bringing with it about a dozen fixes (a few of them major!). The list of the changes can be found on the announcement.

Of course, some of the old features missing still have not been implemented in rc2 are:
  • Erasures of Encrypted/Compressed/Sparse NTFS files (unlikely to be implemented, low-level undocumented APIs required)
  • FAT32 FAT erasures (unlikely to be implemented, low-level APIs required)

The main reason both are not done is because the method employed in v5 to erase such files will not work on Vista (even with UAC disabled). Until a solution to erase these on Vista (with/without UAC on) surfaces these will not be implemented (for safety reasons: we don't want to corrupt drives.)

I'm certain the rc-1 beta testers were generally happy with it (thank you for helping, all 2393 of you!) and I wish all rc-2 testers the same! If you currently hold onto rc-1, the above list should give you even more reason to upgrade (it's free and painless, anyway.)

Disclaimer: The security of the erasures has not been verified by internal or external entities. The code is still of beta quality and may not remove all traces of files with the confidence of Version 5. If you have security concerns, do use Version 5 while the security aspects of Version 6 are ironed out. It is however noteworthy that v6 uses only documented APIs for erasure and therefore the risk of corrupting your drives is lower than Version 5.

If you have read the disclaimer, follow the instructions about installing betas then Download it now.
 
Missing Shell Integration with RC2

Just installed RC2 on a brand new WinXP installation. This machine has never had Eraser on it before.

I've checked the box for "Integrate Eraser into Windows Explorer" and restarted my machine, but I'm not able to see Eraser in the right-click context menu. Since that's the feature I use most in Eraser I'm hopeful it did not go away . . . is there something else I need to do for Shell integration?

Thanks!

--Jason
 
It would be nice if the maintainer(s) provided some hashes, so everyone knows for certain that what they use is actually what they intended to use. For example : "Eraser 6.0.2.813 Setup.exe" = SHA-512 8126ad5927a752fc8f945c55cf353d6251cdcec96e0cabbee3c684c4e360382a836825cd7945fa05a7a5c2aadad6d354f6f129b401bb973fff5a356836f52769
or a smaller MD5 string so it fits on the page, although it has been weakened due to some collisions "Eraser 6.0.2.813 Setup.exe" = 98ed0ea8a3e109d7262b5cdf336450c3 -Thanks for this superior tool
 
I'm looking into Shell Integration, jbs, but time's rather short this week.

Txv, if you have installed the certificates as instructed in Installing Betas in Trac, all binaries are signed (even betas, installer, every single file inside actually: just that it is signed under my name) and therefore will be verified by Windows automatically. Providing hashes are therefore redundant. However, if you did not follow those instructions I will not be able to guarantee that the files will be verified by Windows.

Joel
 
Hi Joel.

FAT32 FAT erasures (unlikely to be implemented, low-level APIs required)
Click to expand...

This would be a massive step backwards for Eraser if it was unable to wipe FAT or FAT32 properly. :shock:

It would mean Eraser V6 could not be recommended to users for wiping floppy disks, flash drives, SD cards and some hard drives !!!

I am stunned that you of all people are having trouble with this, it must be really complicated if you can’t do it ! Can you explain a little of what you are stuck with (in a simple way) and I will try to find an answer for you as I know you are time limited. I will ask around some programming forums etc to try to help.

Have you asked Svante ? I know I promised him we would only ask him about the crypto but this is so important to V6.
 
It's not about being stuck code-wise. I could port the C++ code to C#, however the maintenance cost associated with the code is too high. How v5 erases FAT and FAT32 is by implementing it (as in, implementing the whole FAT system) inside Eraser, locking the drive using Windows, then erasing the file entries.

At step 1, Implementing a system-level service is dangerous (I've seen quite a few FAT bugs previously, a more recent one regarding FAT12 erasures) because there are many details associated with implementing such low-level systems which normal testing may not expose. It is even more dangerous now that it's in C# - the same code will be used in 32- and 64- bit which will be catastrophic if the FAT structures are damaged by a 64-bit OS because of certain (false) assumptions made during development.

At step 2, v6 is meant for Vista and Vista doesn't allow locking of drives unless you are an administrator; if you are trying to lock the system drive you'll just be turned down (regardless).

The locking issue is really touchy - coupled with the portability issue I've got a compelling reason not to open a can full of worms by implementing FAT. A suggestion by Garrett is to just bridge the v5 FAT code into v6, let FAT die out and then remove FAT support.

Having said that, I am personally of the opinion to finish remaining bits and bugs in v6 because fixing such large nightmares (for reasons stated above) will take time which may otherwise be used to fix other bugs which have more relevance as of today. I've got no hard statistics, but I believe NTFS is taking over as the dominant file system on Windows. You can't install Vista on a FAT drive (unless it has been pre-formatted with FAT) because the installer won't let you format a drive as FAT. Solid-state memory like thumbdrives are increasing in capacity: FAT16 will be obsolete soon (it's maximum disk size is 2GB). It's been years since I last used a floppy disk. These observations lead me to believe that the number of people who will benefit from FAT cleanups will be lesser than those who will benefit from other v6 fixes.

I hope I don't incur the wrath of the community for this decision. In summary: I'm just trying to derive the most benefit for as many people in the community as possible. My belief is that FAT isn't used by many and therefore it is lower in priority than other bugs.

Joel
 
On top of that - I've not got any evidence for this claim - but based on my knowledge of how FAT works deleting directories and doing a free space erase will get rid of the residual entries, because unlike NTFS, FAT directories are standalone files and files cannot be resident in the FAT like they can in the MFT. Perhaps Sami or other more experienced file-system level developers could fill me in on this and on what disk structures need to be wiped for effective erasure.

Joel
 
Excellent post Joel, well done. :D

I understand FAT will die out but I was mainly concerned about flash drives etc. But as you say these will eventually get big enough to use NTFS.

However this bit.

On top of that - I've not got any evidence for this claim - but based on my knowledge of how FAT works deleting directories and doing a free space erase will get rid of the residual entries, because unlike NTFS, FAT directories are standalone files and files cannot be resident in the FAT like they can in the MFT.
Click to expand...

Gives me hope, I know just the person to ask about this sort of thing ! I will get back to you. If in the meantime you learn any more on this or have any more questions let me know.
 
Joel said:
I'm looking into Shell Integration, jbs, but time's rather short this week.

Txv, if you have installed the certificates as instructed in Installing Betas in Trac, all binaries are signed (even betas, installer, every single file inside actually: just that it is signed under my name) and therefore will be verified by Windows automatically. Providing hashes are therefore redundant. However, if you did not follow those instructions I will not be able to guarantee that the files will be verified by Windows.

Joel
Click to expand...


I was already aware of this, but I suppose it would not hurt to use both, a checksum for the exe and that whats already being used. So everyone can use its personal preference. This would be the first or one of the few open source projects, that relies mainly on a root certificate, depending on a root certificate is more something for proprietary software, instead of a hash or GPG signature or both.
 
Yeah, we use certificates because our plugin architecture relies on Authenticode signatures. I figured that since we're already using those we could use it all the way. OK i'll release hashes again.

Joel
 
Status
Not open for further replies.
Back
Top