Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 00:33 schrieb Al Viro: On Tue, Feb 03, 2015 at 07:01:50PM +0100, Alexander Holler wrote: Yeah, as I've already admitted in the bug, I never should have use the word secure, because everyone nowadays seems to end up in panic when reading that word. So, if I would be able

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 15:52 schrieb Lukáš Czerner: On Wed, 4 Feb 2015, Alexander Holler wrote: I'm happy for all the feedback. But it doesn't help me. I'm not going to spend the necessary time unpaid. Right, you'd much rather have someone else to spend the time on your request unpaid. That's

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 17:25 schrieb Lukáš Czerner: On Wed, 4 Feb 2015, Alexander Holler wrote: Am 04.02.2015 um 15:52 schrieb Lukáš Czerner: On Wed, 4 Feb 2015, Alexander Holler wrote: I'm happy for all the feedback. But it doesn't help me. I'm not going to spend the necessary time unpaid

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 17:45 schrieb Alexander Holler: Am 04.02.2015 um 17:25 schrieb Lukáš Czerner: On Wed, 4 Feb 2015, Alexander Holler wrote: Am 04.02.2015 um 15:52 schrieb Lukáš Czerner: On Wed, 4 Feb 2015, Alexander Holler wrote: I'm happy for all the feedback. But it doesn't help me. I'm

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
better. Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 00:33 schrieb Al Viro: On Tue, Feb 03, 2015 at 07:01:50PM +0100, Alexander Holler wrote: Yeah, as I've already admitted in the bug, I never should have use the word secure, because everyone nowadays seems to end up in panic when reading that word. So, if I would be able

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
to the the 's' bit, possible. Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 13:42 schrieb Alexander Holler: Am 04.02.2015 um 13:22 schrieb Alexander Holler: Am 04.02.2015 um 13:07 schrieb Lukáš Czerner: The fact is that the current patches are useless for anything other than proof-of-concept. Now you know more that needs to be done or That's wrong

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 13:22 schrieb Alexander Holler: Am 04.02.2015 um 13:07 schrieb Lukáš Czerner: The fact is that the current patches are useless for anything other than proof-of-concept. Now you know more that needs to be done or That's wrong. The patches already work. If you delete a file

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 14:06 schrieb Michael Kerrisk: Alexander, On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 04.02.2015 um 13:07 schrieb Lukáš Czerner: The fact is that the current patches are useless for anything other than proof-of-concept. Now you know more

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 13:50 schrieb Alexander Holler: Am 04.02.2015 um 13:42 schrieb Alexander Holler: Am 04.02.2015 um 13:22 schrieb Alexander Holler: Am 04.02.2015 um 13:07 schrieb Lukáš Czerner: The fact is that the current patches are useless for anything other than proof-of-concept. Now you

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 14:21 schrieb Alexander Holler: I tell you that discussions of APIs should CC linux-api, which I am now CCing into this thread, again, because, again, you're not listening to feedback. Please don't confuse not listening with unable to fulfill Linux kernel maintainer requests

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-04 Thread Alexander Holler
Am 04.02.2015 um 14:29 schrieb Alexander Holler: Am 04.02.2015 um 14:21 schrieb Alexander Holler: I tell you that discussions of APIs should CC linux-api, which I am now CCing into this thread, again, because, again, you're not listening to feedback. Please don't confuse not listening

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
0x2000 in include/uapi/linux/fcntl.h for using the old unlinkat() with that new flag. That's much easier to handle than a new syscall which likely never will end up in the kernel and makes my silly patches even more simple. Regards, Alexander Holler -- To unsubscribe from this list: send the line

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 18:48 schrieb Theodore Ts'o: On Tue, Feb 03, 2015 at 01:48:56PM +0100, Alexander Holler wrote: E.g. my parents are stull successfully using contact lists on paper. These are still more readable, easier to handle and smaller than any available electronic replacement

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 16:41 schrieb Lukáš Czerner: On Tue, 3 Feb 2015, Alexander Holler wrote: I'm already spending a lot of time trying to convince the developers here, that this a feature most people expect from any filesystem. And I've written these patches, for which now, even after I've

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 16:41 schrieb Lukáš Czerner: I'll give up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

2015-02-03 Thread Alexander Holler
be happy if at least the most trivial cases to recover deleted contents could be avoided. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 16:13 schrieb Alexander Holler: Am 03.02.2015 um 15:50 schrieb Alexander Holler: Maybe I should request removal of shred from Fedora/RH instead. According to you it's one of the most misleading and useless tools. So why still confuse people with it and still ship

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 15:50 schrieb Alexander Holler: Maybe I should request removal of shred from Fedora/RH instead. According to you it's one of the most misleading and useless tools. So why still confuse people with it and still ship it? At least it should be documented that it doesn't delete

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 14:50 schrieb Lukáš Czerner: On Mon, 2 Feb 2015, Alexander Holler wrote: Date: Mon, 2 Feb 2015 18:05:11 +0100 From: Alexander Holler To: linux-fsde...@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Alexander Holler Subject: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 13:48 schrieb Alexander Holler: E.g. my parents are stull successfully using contact lists on paper. These are still more readable, easier to handle and smaller than any available electronic replacement. And they have absolutely no problem to destroy an old one when

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 10:23 schrieb Alexander Holler: Or to give another more common example: If you delete your contact list, I likely might find again by just searching for 0x6f726956 at the device level (assuming you've stored a contact in that list with the same surname as yours. And, because

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 09:51 schrieb Alexander Holler: Am 03.02.2015 um 08:56 schrieb Al Viro: On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote: Charming. Now, what exactly happens if two such syscalls overlap in time? What do you think will happen? I assume you haven't looked

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 08:56 schrieb Al Viro: On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote: Charming. Now, what exactly happens if two such syscalls overlap in time? What do you think will happen? I assume you haven't looked at how I've implemented set_secure_delete

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 09:10 schrieb Al Viro: On Tue, Feb 03, 2015 at 09:01:36AM +0100, Alexander Holler wrote: Am 03.02.2015 um 08:56 schrieb Al Viro: While we are at it, "overwrite with zeroes" is too weak if the attacker might get hold of the actual hardware. Google for details - it

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 08:56 schrieb Al Viro: While we are at it, "overwrite with zeroes" is too weak if the attacker might get hold of the actual hardware. Google for details - it's far too long story for l-k posting. Look for data recovery and secure data erasure... You might read

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 14:50 schrieb Lukáš Czerner: On Mon, 2 Feb 2015, Alexander Holler wrote: Date: Mon, 2 Feb 2015 18:05:11 +0100 From: Alexander Holler hol...@ahsoftware.de To: linux-fsde...@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Alexander Holler hol...@ahsoftware.de Subject: [PATCH

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 15:50 schrieb Alexander Holler: Maybe I should request removal of shred from Fedora/RH instead. According to you it's one of the most misleading and useless tools. So why still confuse people with it and still ship it? At least it should be documented that it doesn't delete

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 16:13 schrieb Alexander Holler: Am 03.02.2015 um 15:50 schrieb Alexander Holler: Maybe I should request removal of shred from Fedora/RH instead. According to you it's one of the most misleading and useless tools. So why still confuse people with it and still ship

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 08:56 schrieb Al Viro: On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote: Charming. Now, what exactly happens if two such syscalls overlap in time? What do you think will happen? I assume you haven't looked at how I've implemented set_secure_delete

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 09:10 schrieb Al Viro: On Tue, Feb 03, 2015 at 09:01:36AM +0100, Alexander Holler wrote: Am 03.02.2015 um 08:56 schrieb Al Viro: While we are at it, overwrite with zeroes is too weak if the attacker might get hold of the actual hardware. Google for details - it's far too

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 08:56 schrieb Al Viro: While we are at it, overwrite with zeroes is too weak if the attacker might get hold of the actual hardware. Google for details - it's far too long story for l-k posting. Look for data recovery and secure data erasure... You might read

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 16:41 schrieb Lukáš Czerner: I'll give up. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 16:41 schrieb Lukáš Czerner: On Tue, 3 Feb 2015, Alexander Holler wrote: I'm already spending a lot of time trying to convince the developers here, that this a feature most people expect from any filesystem. And I've written these patches, for which now, even after I've

Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

2015-02-03 Thread Alexander Holler
be happy if at least the most trivial cases to recover deleted contents could be avoided. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 10:23 schrieb Alexander Holler: Or to give another more common example: If you delete your contact list, I likely might find again by just searching for 0x6f726956 at the device level (assuming you've stored a contact in that list with the same surname as yours. And, because

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 13:48 schrieb Alexander Holler: E.g. my parents are stull successfully using contact lists on paper. These are still more readable, easier to handle and smaller than any available electronic replacement. And they have absolutely no problem to destroy an old one when

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 18:48 schrieb Theodore Ts'o: On Tue, Feb 03, 2015 at 01:48:56PM +0100, Alexander Holler wrote: E.g. my parents are stull successfully using contact lists on paper. These are still more readable, easier to handle and smaller than any available electronic replacement

Re: [PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-03 Thread Alexander Holler
0x2000 in include/uapi/linux/fcntl.h for using the old unlinkat() with that new flag. That's much easier to handle than a new syscall which likely never will end up in the kernel and makes my silly patches even more simple. Regards, Alexander Holler -- To unsubscribe from this list: send the line

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-03 Thread Alexander Holler
Am 03.02.2015 um 09:51 schrieb Alexander Holler: Am 03.02.2015 um 08:56 schrieb Al Viro: On Tue, Feb 03, 2015 at 07:58:50AM +0100, Alexander Holler wrote: Charming. Now, what exactly happens if two such syscalls overlap in time? What do you think will happen? I assume you haven't looked

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-02 Thread Alexander Holler
Am 03.02.2015 um 07:05 schrieb Al Viro: On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote: + if (inode) { + // TODO: + // if (inode is file and 's' flag is set) + // secure = true; + if (!secure

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-02 Thread Alexander Holler
Am 03.02.2015 um 07:05 schrieb Al Viro: > On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote: >> +if (inode) { >> +// TODO: >> +// if (inode is file and 's' flag is set) >> +// secure = true;

[PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-02 Thread Alexander Holler
Signed-off-by: Alexander Holler --- fs/ext4/ext4.h| 2 ++ fs/ext4/mballoc.c | 25 +++-- fs/ext4/super.c | 12 3 files changed, 37 insertions(+), 2 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index c55a1fa..e66507c 100644 --- a/fs/ext4/ext4.h

[PATCH 4/5] WIP: Add patch for coreutils to support unlinkat_s (x86_64 only)

2015-02-02 Thread Alexander Holler
You have to build the new rm yourself Signed-off-by: Alexander Holler --- ...ion-s-to-rm-to-support-unlinkat_s-current.patch | 111 + 1 file changed, 111 insertions(+) create mode 100644 0001-WIP-Add-option-s-to-rm-to-support-unlinkat_s-current.patch diff --git a/0001-WIP

[PATCH 2/5] WIP: fs: fat: support unlinkat_s() for secure deletion of files

2015-02-02 Thread Alexander Holler
Signed-off-by: Alexander Holler --- fs/fat/fat.h| 1 + fs/fat/fatent.c | 20 fs/fat/inode.c | 13 + 3 files changed, 34 insertions(+) diff --git a/fs/fat/fat.h b/fs/fat/fat.h index e0c4ba3..b9febda 100644 --- a/fs/fat/fat.h +++ b/fs/fat/fat.h @@ -81,6

[PATCH 5/5] WIP: Add test for unlinkat_s

2015-02-02 Thread Alexander Holler
Simple test, needs the new rm with option -s. Signed-off-by: Alexander Holler --- test_unlinkat_s.sh | 27 +++ 1 file changed, 27 insertions(+) create mode 100755 test_unlinkat_s.sh diff --git a/test_unlinkat_s.sh b/test_unlinkat_s.sh new file mode 100755 index 000

[PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-02 Thread Alexander Holler
Signed-off-by: Alexander Holler --- arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + fs/namei.c| 38 ++- include/asm-generic/audit_dir_write.h | 1 + include/linux/fs.h| 1

[PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

2015-02-02 Thread Alexander Holler
rebase them myself (thanks to git). - Don't be disappointed because the patches are that simple. The idea counts. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majo

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-02 Thread Alexander Holler
Am 03.02.2015 um 07:05 schrieb Al Viro: On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote: +if (inode) { +// TODO: +// if (inode is file and 's' flag is set) +// secure = true; +if (!secure) +iput

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-02 Thread Alexander Holler
Am 03.02.2015 um 07:05 schrieb Al Viro: On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote: + if (inode) { + // TODO: + // if (inode is file and 's' flag is set) + // secure = true; + if (!secure

[PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

2015-02-02 Thread Alexander Holler
Signed-off-by: Alexander Holler hol...@ahsoftware.de --- arch/x86/syscalls/syscall_32.tbl | 1 + arch/x86/syscalls/syscall_64.tbl | 1 + fs/namei.c| 38 ++- include/asm-generic/audit_dir_write.h | 1 + include/linux/fs.h

[PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

2015-02-02 Thread Alexander Holler
rebase them myself (thanks to git). - Don't be disappointed because the patches are that simple. The idea counts. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http

[PATCH 5/5] WIP: Add test for unlinkat_s

2015-02-02 Thread Alexander Holler
Simple test, needs the new rm with option -s. Signed-off-by: Alexander Holler hol...@ahsoftware.de --- test_unlinkat_s.sh | 27 +++ 1 file changed, 27 insertions(+) create mode 100755 test_unlinkat_s.sh diff --git a/test_unlinkat_s.sh b/test_unlinkat_s.sh new file mode

[PATCH 2/5] WIP: fs: fat: support unlinkat_s() for secure deletion of files

2015-02-02 Thread Alexander Holler
Signed-off-by: Alexander Holler hol...@ahsoftware.de --- fs/fat/fat.h| 1 + fs/fat/fatent.c | 20 fs/fat/inode.c | 13 + 3 files changed, 34 insertions(+) diff --git a/fs/fat/fat.h b/fs/fat/fat.h index e0c4ba3..b9febda 100644 --- a/fs/fat/fat.h +++ b/fs/fat

[PATCH 3/5] WIP: fs: ext4: support unlinkat_s() for secure deletion of files

2015-02-02 Thread Alexander Holler
Signed-off-by: Alexander Holler hol...@ahsoftware.de --- fs/ext4/ext4.h| 2 ++ fs/ext4/mballoc.c | 25 +++-- fs/ext4/super.c | 12 3 files changed, 37 insertions(+), 2 deletions(-) diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index c55a1fa..e66507c 100644

[PATCH 4/5] WIP: Add patch for coreutils to support unlinkat_s (x86_64 only)

2015-02-02 Thread Alexander Holler
You have to build the new rm yourself Signed-off-by: Alexander Holler hol...@ahsoftware.de --- ...ion-s-to-rm-to-support-unlinkat_s-current.patch | 111 + 1 file changed, 111 insertions(+) create mode 100644 0001-WIP-Add-option-s-to-rm-to-support-unlinkat_s-current.patch

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-29 Thread Alexander Holler
Am 25.01.2015 um 11:32 schrieb Alexander Holler: Am 25.01.2015 um 03:43 schrieb Alexander Holler: Am 25.01.2015 um 03:13 schrieb Pádraig Brady: On 24/01/15 12:29, Alexander Holler wrote: Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-29 Thread Alexander Holler
Am 25.01.2015 um 11:32 schrieb Alexander Holler: Am 25.01.2015 um 03:43 schrieb Alexander Holler: Am 25.01.2015 um 03:13 schrieb Pádraig Brady: On 24/01/15 12:29, Alexander Holler wrote: Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 19:42 schrieb Steven Rostedt: Hey, if you end up doing it, it could help with your resume. Oh, young padovan, I'm writing SW since 30a and it just would make it even longer, which already seems to be a problem for many HR people. Alexander Holer -- To unsubscribe from this

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
piece of (imho) interesting information. Happy frameworking and sorry for disturbing. Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 18:48 schrieb Steven Rostedt: On Tue, 27 Jan 2015 18:38:36 +0100 Alexander Holler wrote: Anyway, I like(d) Linux because it didn't had a splash screen and used to spit out all types of information on the screen where it could be easily seen or found (in contrast other OS

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
that the kernel does a lot of things. ;) I don't want that ftrace stuff appears in dmesg, but I like to do dmesg | grep -i mmc (or whatever is of interest) instead of grep -Rsi mmc /sys/ or something like find /sys -iname '*mmc*' -exec \; Alexander Holler -- To unsubscribe from this list: send

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
because grep doesn't connect the file name with the content, so you need more complicated stuff to combine both in order to search for and find something in sysfs. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 15:21 schrieb Borislav Petkov: On Tue, Jan 27, 2015 at 01:44:15PM +0100, Alexander Holler wrote: Yes. Sorry, but I had so many bad experiences with maintainers. Well, I can't comment on your experience for the simple reason that I haven't followed those discussions

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
settings) instead of a desastrous memory corruption which (hard-) reseted the machine (and might have done even more bad things) and so on. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 13:08 schrieb Borislav Petkov: On Tue, Jan 27, 2015 at 01:02:49PM +0100, Alexander Holler wrote: Look at the source at the message which is printed just before and decide which one you find more informational / useful. I find such a message absolutely useless. Also

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 12:55 schrieb Richard Weinberger: On Tue, Jan 27, 2015 at 12:48 PM, Alexander Holler wrote: It's an interesting detail, so inform the user about it. Signed-off-by: Alexander Holler --- drivers/mmc/core/bus.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers

[PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
It's an interesting detail, so inform the user about it. Signed-off-by: Alexander Holler --- drivers/mmc/core/bus.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c index 8a1f124..4a60028 100644 --- a/drivers/mmc/core/bus.c +++ b/drivers

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
settings) instead of a desastrous memory corruption which (hard-) reseted the machine (and might have done even more bad things) and so on. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 18:48 schrieb Steven Rostedt: On Tue, 27 Jan 2015 18:38:36 +0100 Alexander Holler hol...@ahsoftware.de wrote: Anyway, I like(d) Linux because it didn't had a splash screen and used to spit out all types of information on the screen where it could be easily seen or found

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 19:42 schrieb Steven Rostedt: Hey, if you end up doing it, it could help with your resume. Oh, young padovan, I'm writing SW since 30a and it just would make it even longer, which already seems to be a problem for many HR people. Alexander Holer -- To unsubscribe from this

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
piece of (imho) interesting information. Happy frameworking and sorry for disturbing. Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 13:08 schrieb Borislav Petkov: On Tue, Jan 27, 2015 at 01:02:49PM +0100, Alexander Holler wrote: Look at the source at the message which is printed just before and decide which one you find more informational / useful. I find such a message absolutely useless. Also

[PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
It's an interesting detail, so inform the user about it. Signed-off-by: Alexander Holler hol...@ahsoftware.de --- drivers/mmc/core/bus.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c index 8a1f124..4a60028 100644 --- a/drivers/mmc/core

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 12:55 schrieb Richard Weinberger: On Tue, Jan 27, 2015 at 12:48 PM, Alexander Holler hol...@ahsoftware.de wrote: It's an interesting detail, so inform the user about it. Signed-off-by: Alexander Holler hol...@ahsoftware.de --- drivers/mmc/core/bus.c | 4 1 file changed

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
Am 27.01.2015 um 15:21 schrieb Borislav Petkov: On Tue, Jan 27, 2015 at 01:44:15PM +0100, Alexander Holler wrote: Yes. Sorry, but I had so many bad experiences with maintainers. Well, I can't comment on your experience for the simple reason that I haven't followed those discussions

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
because grep doesn't connect the file name with the content, so you need more complicated stuff to combine both in order to search for and find something in sysfs. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH] mmc: print message if a card supports secure erase/trim

2015-01-27 Thread Alexander Holler
complications \; Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:36 schrieb Alexander Holler: Am 25.01.2015 um 13:24 schrieb Alexander Holler: Am 25.01.2015 um 13:08 schrieb Richard Weinberger: Or add support for the "s" chattr to major filesystems. (...) So maybe shred should first set the 's' attribute before call

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:28 schrieb Richard Weinberger: Am 25.01.2015 um 13:24 schrieb Alexander Holler: Am 25.01.2015 um 13:08 schrieb Richard Weinberger: On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler wrote: Now, after I ended up into flaming a lot (sorry again, but this topic made me angry

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:24 schrieb Alexander Holler: Am 25.01.2015 um 13:08 schrieb Richard Weinberger: Or add support for the "s" chattr to major filesystems. And change the manpage for the 's' attribute to change the "overwriting with zero" with some other wording. But th

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:08 schrieb Richard Weinberger: On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler wrote: Now, after I ended up into flaming a lot (sorry again, but this topic made me angry for so long and I had to spent too much time to get rid of unwanted content and answering other

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 12:42 schrieb Alexander Holler: Now, after I ended up into flaming a lot (sorry again, but this topic made me angry for so long and I had to spent too much time to get rid of unwanted content and answering other peoples question in regard to that topic), I should offer something

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
ny black magic involved in offering the user a simple way to really delete files. Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majord

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 11:32 schrieb Alexander Holler: So we are now at the point that the only way to keep some information private (forever) is to not store it on any computer. That should be written "any electronic device (including phones, tablets, cameras, TVs and clouds)" inste

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 03:43 schrieb Alexander Holler: Am 25.01.2015 um 03:13 schrieb Pádraig Brady: On 24/01/15 12:29, Alexander Holler wrote: Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am 24.01.2015 um 11:45 schrieb Alexander Holler

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
in offering the user a simple way to really delete files. Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 11:32 schrieb Alexander Holler: So we are now at the point that the only way to keep some information private (forever) is to not store it on any computer. That should be written any electronic device (including phones, tablets, cameras, TVs and clouds) instead of any

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 03:43 schrieb Alexander Holler: Am 25.01.2015 um 03:13 schrieb Pádraig Brady: On 24/01/15 12:29, Alexander Holler wrote: Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am 24.01.2015 um 11:45 schrieb Alexander Holler

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:24 schrieb Alexander Holler: Am 25.01.2015 um 13:08 schrieb Richard Weinberger: Or add support for the s chattr to major filesystems. And change the manpage for the 's' attribute to change the overwriting with zero with some other wording. But thanks for the hint. I

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:08 schrieb Richard Weinberger: On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler hol...@ahsoftware.de wrote: Now, after I ended up into flaming a lot (sorry again, but this topic made me angry for so long and I had to spent too much time to get rid of unwanted content

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:36 schrieb Alexander Holler: Am 25.01.2015 um 13:24 schrieb Alexander Holler: Am 25.01.2015 um 13:08 schrieb Richard Weinberger: Or add support for the s chattr to major filesystems. (...) So maybe shred should first set the 's' attribute before calling unlink

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 12:42 schrieb Alexander Holler: Now, after I ended up into flaming a lot (sorry again, but this topic made me angry for so long and I had to spent too much time to get rid of unwanted content and answering other peoples question in regard to that topic), I should offer something

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-25 Thread Alexander Holler
Am 25.01.2015 um 13:28 schrieb Richard Weinberger: Am 25.01.2015 um 13:24 schrieb Alexander Holler: Am 25.01.2015 um 13:08 schrieb Richard Weinberger: On Sun, Jan 25, 2015 at 12:42 PM, Alexander Holler hol...@ahsoftware.de wrote: Now, after I ended up into flaming a lot (sorry again

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-24 Thread Alexander Holler
Am 25.01.2015 um 03:13 schrieb Pádraig Brady: On 24/01/15 12:29, Alexander Holler wrote: Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am 24.01.2015 um 11:45 schrieb Alexander Holler: It uses shred, in the hope it will somedays learn how

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-24 Thread Alexander Holler
Am 24.01.2015 um 13:09 schrieb Alexander Holler: Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am 24.01.2015 um 11:45 schrieb Alexander Holler: It uses shred, in the hope it will somedays learn how to shred stuff on FLASH based devices securely too, once that has become possible. BTW

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-24 Thread Alexander Holler
Am 24.01.2015 um 12:37 schrieb Alexander Holler: Am 24.01.2015 um 11:45 schrieb Alexander Holler: It uses shred, in the hope it will somedays learn how to shred stuff on FLASH based devices securely too, once that has become possible. BTW: This is a good example where technology failed

Re: [PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-24 Thread Alexander Holler
Am 24.01.2015 um 11:45 schrieb Alexander Holler: It uses shred, in the hope it will somedays learn how to shred stuff on FLASH based devices securely too, once that has become possible. BTW: This is a good example where technology failed to keep the needs of users in mind. It should

[PATCH v2] modsign: use shred to overwrite the private key before deleting it

2015-01-24 Thread Alexander Holler
This is for the more paranoid people, also it's questionable what paranoid nowadays means. It uses shred, in the hope it will somedays learn how to shred stuff on FLASH based devices securely too, once that has become possible. Signed-off-by: Alexander Holler --- Makefile | 2 +- 1 file

<    1   2   3   4   5   6   7   8   9   10   >