Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:First off, this is why I will never live in the UK. Secondly, this is why if it's something that you don't want to store for a long time (that is, longer than the system will be powered on), you use an ephemeral encryption key. Thirdly, if there is some chance you can lose the key, you make a secure backup (or do like I do and algorithmically generate passwords/encryption keys in a reproducible manner (which is itself secure if you do it right, and of course tell no-one the algorithm you use to generate them)).
On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:
Perhaps not so surprisingly, over a decade later, it is not currently
at the top of the priority list of any of the current file system or
VFS developers, as far as I know. One of the reasons for that is that
there are a number of other ways of achieving the same functionality.
These include using tmpfs, or using file system level encryption.
They require a bit more system administrator setup than just being
able to set the FS_SECR_FL flag, true, but just because it's more
convenient doesn't mean that it's worth doing.
Again, I don't think that encryption is an alternative. Besides that
there is always the thread that strong encrytion will become regulated,
there is also the very real thread that someone might end up in jail
when using encryption and throwing away the key to delete stuff. E.g.,
as to my knowledge, in the UK you might end up in jail if you don't hand
out a password. So what happens if you've deleted the key and are really
unable to hand it out and the people which have an interest in what
you've once stored don't believe you?
The problem I see with this argument is:So.... this is a feature request. It's a reasonable feature request,
in that if someone would like to pay $$$ for some consultant to
implement it in a way that is bug-free, I suspect it could go
upstream. Someone who was very motivated and with the sufficient
skills could also invest their own effort to make a patch that can go
upstream too. You've elected not, to because you believe it would
take you months of "unpaid time". That's purely within your rights to
do. But you don't have the right to try to tell other people what
work to do on their behalf --- not unless you are paying their salary.
First I haven't request that someone implements it for me. Besides that
what you're describing is what maintainers do all the time. Of course,
it's their job to request quality, but, in my humble opinion, very often
they are requesting stuff just to request something.
And that "month of unpaid time" was for sure a cynical exaggeration I'veDiscard has never really worked properly in BTRFS, although it is being worked on. If you actually care about security though, you shouldn't be using discard except when re-provisioning your storage (there are numerous papers about why on the web), trying to use that for secure deletion is creating a false sense of security.
done while having been angry. In fact I believe the way I've outlined
with the ugly code (proof of concept) could be implemented by someone
like you in a weekend. For me it needs quiet some more time because I
had and still have almost zero knowledge about all locks and whatever
else is used in the filesystem code. But nevertheless I was able to fix
up a lot of stuff during another afternoon. E.g. I've added checks if a
file is in use or if AT_WIPE was called on a directory and then returned
errors in those cases. Unfortunately the code changed in 4.2 and that
patch doesn't apply anymore and now, because I don't really need those
implementation details (I'm aware of the problems of my patch), I've
thrown the patch into the waste bin. Besides that my concept doesn't
work on BTRFS what I'm currently using for various reasons (mainly
compression) on most of my systems. And I have no idea if it ever will
(because I don't know why discard on BTRFS doesn't really discard what I
think it should discard. ;) ).
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature