From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Deus Max Newsgroups: gmane.emacs.devel Subject: Re: Tramp and crypted files Date: Thu, 28 May 2020 16:05:09 +0300 Message-ID: <87367kfbwa.fsf@aia00820.aia.gr> References: <865zd1h3ru.fsf@duenenhof-wilhelm.de> <875zd15rze.fsf@gmx.de> <87wo5gjfbr.fsf@gmx.de> <87eermkdov.fsf@gmx.de> <87r1vlipg4.fsf@gmx.de> <86lflrttxn.fsf@duenenhof-wilhelm.de> <874ksdhdmp.fsf_-_@gmx.de> <87h7wcwbn9.fsf@aia00820.aia.gr> <87lfloou9y.fsf@gmx.de> <874ksbvwn0.fsf@aia00820.aia.gr> <871rn7rgtv.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="17505"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 28 15:08:22 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jeIGk-0004R0-Fe for ged-emacs-devel@m.gmane-mx.org; Thu, 28 May 2020 15:08:22 +0200 Original-Received: from localhost ([::1]:51742 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jeIGi-0002mg-W2 for ged-emacs-devel@m.gmane-mx.org; Thu, 28 May 2020 09:08:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38292) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeIDr-0001Xd-KW for emacs-devel@gnu.org; Thu, 28 May 2020 09:05:23 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:34551) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jeIDp-0006Y4-MG for emacs-devel@gnu.org; Thu, 28 May 2020 09:05:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1590671118; bh=SbSE9sZeYvZFJhD5ZdkmVu0j78DQ85N8/q4z/nbtOYA=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=ismPyVLfr1y7k8WHcW3ZmON1PyMuqoz7vQBYPtNf0DIgszUqTwIo8DFJTZrKj2KyL wsXvgBIxV7asO4AudzoNPLhbDo4Bia8DxSKKcVD1d60C9U5B9ARtP4wIIJbdMFJjKw 3TBQJzcOtYPc4j5bPleVBDia6SD0DdyIOn9BdqDw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from aceraspire5 ([46.176.158.134]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Mlf4S-1jDAgJ2Okk-00imiP; Thu, 28 May 2020 15:05:17 +0200 In-Reply-To: <871rn7rgtv.fsf@gmx.de> (Michael Albinus's message of "Mon, 25 May 2020 20:48:44 +0200") X-Provags-ID: V03:K1:vrSwbsBlvnvfKwEIKrqVIZh4a8lvSYH8gRRqA/yQoz8tZYz/MTO SLgiS0Pa5ufTQy9JAgy5Y2yvybpFZ73ttGR68iyfrnARwa40KL+qKkQYc0eRo8hwdGgxHNs F4+9tPsQ1hZv3xIPJmX8va0O9n8KIhdS3quUwv9EC00ZdGLOlPYR5IVF4/CB+scPm5tydtR KahQc0Pi1MuZTlQxnBqKg== X-UI-Out-Filterresults: notjunk:1;V03:K0:xv4wi98FORY=:7SJ8UWf6FUfwUhwOMmtmCG +d/CixVAwetx4a93DVyw6CW35jOmJ5bbRFOJ9vuY+j+Z56S6aigCXmWSrEKkJ2wz3jK6oJf/C A4DaWkat+8KUF0NVUPAuWgFeK3GPTqh/O+VefyjNclQlui70B2vnsT4iJ2Mm0CQfLysMoxFh5 x3rw1zZHNmT9HqRPjTPfmz0mP8IsOSPqAfyFB6jOzM4DENwTUDCUHdbIFkhkb5khmaN9v7sAl EXhtjOo+5dznpg+d/XD3uqFNAuCP+pXzpxHMLiOF52K5bwC7/J5ngBjFXb+YLRuaDWCEyDxIu mnRCTw7C8isyaiI8iVYvtDF2oDmv5du8VR+nvqe9zJYIicjMvgWs7OUSKi2KPJMQh6maQRQM5 iltH+lK9rBT3sPdh7IUvYoFrtUfGVpFEBTZxMGaT/KUK9i4b8k57WDOSVfF9dghfmSZsjWVtY 0vIesMcrb68UnmzpvGkhpNSXf9O18hsB6bYASCzV323upJp/wLYugiQrzsOePQpMH7X1conzH aJhu0VryzpSJFxh0qFz+Z35thC7miOmcQs4ygzaKmGdKFuVy12XiiC8vdswUwIBwgTZl2evUW LYxzhum5qVyuKD7WK+/RR++S8LoflMIrt8pPNhjPgIM8hc3nJNMtcFPFHFQxfokgij0UUa/9P M9xWVrAxq5ty58aI8vDgYnrv2Lb6uFi4Ebl6HN2rb3c8cRRDoTzOLmdBXD/sg9+yw1XQQZZgs t9ZDkAPXclQd42Q3llP+UrpYPOXleO+Z4poyHzwrzHb2S6wq8ADSd1Er3wLMpJDWaMYixv2N Received-SPF: pass client-ip=212.227.15.19; envelope-from=deusmax@gmx.com; helo=mout.gmx.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/28 09:05:18 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251543 Archived-At: On Mon, May 25 2020, Michael Albinus wrote: > Deus Max writes: > > Hi, > >>> As written in my other messages, I don't believe (anymore) we shall mix >>> the en-/decryption part with Tramp implementation. This shall be >>> implemented in another file name handler, working over local >>> files. Tramp with whatever backend would be responsible then for copying >>> the encrypted files from/to the remote side. >> >> Agree. >> Encfs handles the encryption. >> The actual files are encrypted, encfs defines a mount-point where the >> files are displayed decrypted. >> >> Having an easy to use Tramp method for encrypting cloud data would be a >> good plus for privacy. > > I have played with encfs and your script as well as with first snippets > of a Tramp implementation. Just for discussion, here are my conclusions > so far: > > - Encryption of files and file names shall be possible for *every* > remote connection. This means, that the approach will be different > from what you have done in your script (where you work over webdav > based cloud servers). > OK. > - Encryption of files and file names shall be separated from vanilla > Tramp. It is optional, and a user must enable it explicitly for a > given remote directory. This is because of performance, and because of > implementation simplicity. As a result, there shall be almost no > change of existing Tramp; all encrytion functionality will be > cumulated in a new tramp-crypt.el file. > Good. > Of course, encryption can be activated for several remote directories > in parallel. But they must not be subdirectories of each other. > > - As a consequence, there will be an additional file name handler, which > reacts on the same file name syntax as Tramp. It is arranged to be > called before the vanilla Tramp file name handler. All of its > functions will check, whether a user has activated encryption for a > given remote directory. In that case, if an argument of a function is > a file name which belongs to such a directory, that file name will be > transformed into its crypted counterpart, and the native Tramp file > name handler is activated for this function with encrypted file > names. If the function returns file names, the reverse action is > applied: if a file name is encrypted, the result will be adapted to > contain the corresponding decrypted file name. > > - For file copying, the file itself is either encrypted (when copying > to remote) or decrypted (when copying from remote). Together with the > encryption/decryption of the file name, the copy operation will be > applied by vanilla Tramp operation. > > - There will be *no* mounted encfs file system. File name > encryption/decryption will be performed by "encfsctl encode ..." and > "encfsctl decode ..." process calls. File encryption happens via > "encfsctl cat ..." and "encfsctl cat --reverse ...". > EncFS is not needed for the this setup. Vanilla gpg encryption could be used for the above. Without hidding the filename (with .gpg extension). only encrypt the content. EncFs adds file name encryption and obsfucation, making in hard to guess the encrypted file, even if you know the file name. So you have to temporarily mount somewhere, in order to see the decrypted filenames. > - The local rootdir of a crypted remote directory will be created temporarily > when needed. It is always rearrangeable via its config file > .encfs6.xml, which contains the filesystem information. Only this > config file will be kept persistently, one file per activated crypted > remote directory, somewhere in ~/.emacs.d/. Optionally, it will be > kept also in the crypted remote directory as well. > Yes, the .encfs6.xml is very importantf for EncFS. I think encfs needs a temprorary mount point, to function. This can be a weakness in a network situation, as any interruption could leave the files open or in a strange state, inviting the case to be compromised. > With this, encrypted files from remote can be accessed by different > Emacs sessions running from different host, by different users. All > what they need to know is the remote directory name (in Tramp syntax), > and the password the encryption/decryption is protected with. That's > what "cloudy servers" are good for. > Correct me if I'm wrong, but I don't think the webdav protocol behaves well for multi-user editing. It simple saves the last edit. without comparing for merge conflicts. It is a last save takes all. For access from different hosts, the user should take care to use strict sequential access. DeusMax