From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id wLWuJvAwhGbD3gAAqHPOHw:P1 (envelope-from ) for ; Tue, 02 Jul 2024 16:55:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id wLWuJvAwhGbD3gAAqHPOHw (envelope-from ) for ; Tue, 02 Jul 2024 18:55:12 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GgNGwxoA; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1719939312; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=KqBNUjLrYz8fuWHo0NoDd8YfQXLT/lcLWRS38XHgy3c=; b=aChTn9bCvM0ly1lpcNgyf/oA1DpQxUeLlWVJiHsq5fojEj6RR+29/pd4WpD0WTxHaFJhLw t9Wwf5t3Nw5Akj/fXLhc95KWIUm3+yh/saccJ6fdjro3ohOj0XN4yfWwjRc5S1MlZpsOCc XD8T4m9bVIrmdIzlKdoMqA0Y4Qx4EiJwfPrY7BwdqWBWKsG3BbWdZLQVuXuls/Y67GRujw DywPIBm1KU87Se4+8DxA1eaMkhcPeElwNI73coHztQ/TS6MC8c3xPA7e2XzDG6Xbn6Zf4m AfaqoGzXiVnvNf+foBlBq1NNwvCfThNwFc9x0T2e11kxNLBwFGTTkO/WCcnoXg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GgNGwxoA; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1719939312; a=rsa-sha256; cv=none; b=TlEanOdkcpNibHSScHOd83FgiXzBJcicufECZAztv853qEmo4zlqqeftAOlOzgnQGDlExm AxEfoqd5DYHLGGtvnorN9II+nrtlM7Ti0+9LxqlO1mEGZ8Vk6am0sP1mOtdpsCc2FLmaHd LeC/y35Jj/rgTEVbQX5SLc6/JukI6eqsKyIgmlH0nruAeP8S8ONjo8ELK+mZCPBIMBucVD qoX2cifwIyhge/KCYxC745WFN9Q/YVMqRMrrkn/EeWL7WA4/+vZH0mordYlocIa5DpkP0q hhhWmjfcxjFccFa0v3GSCkx0CtjIA0Q8BwQZv7X2LpNHE13kW+u7XZGf01TfZA== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 2FFA755DC6 for ; Tue, 2 Jul 2024 18:55:12 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sOgld-0005jm-7Y; Tue, 02 Jul 2024 12:54:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sOglb-0005jV-N7 for emacs-orgmode@gnu.org; Tue, 02 Jul 2024 12:54:07 -0400 Received: from mail-vs1-xe35.google.com ([2607:f8b0:4864:20::e35]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sOglZ-0005bM-WB; Tue, 02 Jul 2024 12:54:07 -0400 Received: by mail-vs1-xe35.google.com with SMTP id ada2fe7eead31-48f48ab80e3so1583764137.1; Tue, 02 Jul 2024 09:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719939243; x=1720544043; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KqBNUjLrYz8fuWHo0NoDd8YfQXLT/lcLWRS38XHgy3c=; b=GgNGwxoAkczyw4SzAO9n3Hy0fEehX1+kmGms43EeKsM+KavxQnTjGSNlNFrCiUyzpZ mbdBKmRGRrCgUbKgu3mfGgu1jwBrnm3BoKBtjO0NN/fk4ja0hgZA97GBx0XufdEYh7AR YsSvwD2tGSq4xHFXoJMQG72Y+3yhpgN93QyhydPy/TCLqYrfrgLgEZSqQMnwjeABKBgM UCA9GiM/8LXMzrc/ueo1gY+J4H7ygddQOLKAxd1tY+3AYhBORgUbPOUiP6/QeWSBhTN2 D9qJl9xiXefgPU5uaJKilLUvV9TaKpLlTgN5UmlQIk65cahaXWZzb9LinvQzoZda0Bix VEdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719939243; x=1720544043; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KqBNUjLrYz8fuWHo0NoDd8YfQXLT/lcLWRS38XHgy3c=; b=o7xZZdc+NtuA54VErFMLuAKYG/O007TCAnzYZBBdjZMI3ZLOFSeK4msMeezaDw4Ceu uxJJZQgciigPnTkZRexzuIRJp9C/b/s3vvdIWJa1sf12a2teNz+hjtSxkjy1epZA+Z5K xVln9t6xMdEYLwrHQDT/J1WaixAB+96go2JB4xbICnqSx6VW48zGgd96cfjTWjdZS6AZ Zdi32hQNyq8S3H4lvJ1B4KlvtiuIgkAAJH87/w8xIwMb4y7VhVcfgQh++0y3vBE/Ysmx ckYvwIa6E6MGREbl5ik6gZKWySSQ4FVZeKcYIWVS3tr7Nt3iUWq+V27wbNkoLVVhUj6u PN/Q== X-Forwarded-Encrypted: i=1; AJvYcCXlM17w6gmv+vB08ohTBW6SzjbyBrX+ag5V+5LU7jG+Ji7MLfKio98z45hFIQgPR8KsdIwFXg7SJWrpnaW79dzMUsXaWvU= X-Gm-Message-State: AOJu0YwdgZI4b+2DFOOuW1f7uh41KPAboFDioNjmjPguNsQVALg9cCT6 k6qVn7tEez4yzWh0BW+S9Vzo0ZC8gZ1wfYB1bCH1SG5uOCiA4JclYo9UkK9zUAcFl70xSjKX1fJ a/wC8HqnZM28Zx+CBmm3MLvkOOzM= X-Google-Smtp-Source: AGHT+IFJNulAWXSOJR0yk1I58OxMpdW6Ndbu44AnAcdVcV56TefEXFiqIQcfVMhGFuPA7iFWu+GeXCAbpHo1uajnocM= X-Received: by 2002:a05:6102:241c:b0:48d:706f:a884 with SMTP id ada2fe7eead31-48faf0aa2c2mr8903605137.20.1719939242526; Tue, 02 Jul 2024 09:54:02 -0700 (PDT) MIME-Version: 1.0 References: <86ed921oxu.fsf@gnu.org> <874j9vllbp.fsf@localhost> <87o781t676.fsf@localhost> <874j9qs0wh.fsf@localhost> <87ed8mtyp0.fsf@localhost> <87msn7kffy.fsf@localhost> <87le2qy8ri.fsf@localhost> In-Reply-To: <87le2qy8ri.fsf@localhost> From: Daniel Clemente Date: Tue, 2 Jul 2024 16:53:33 +0000 Message-ID: Subject: Re: org-crypt leaking data when encryption password is not entered twice (was: Please document the caching and its user options) To: Ihor Radchenko Cc: Eli Zaretskii , emacs-orgmode@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::e35; envelope-from=n142857@gmail.com; helo=mail-vs1-xe35.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Queue-Id: 2FFA755DC6 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.73 X-Spam-Score: -9.73 X-TUID: cgFGOLzAF8eZ > > In addition, =E2=80=9Eleaving some encrypted sections unencrypted for a= short > > amount of time, and closing and reopening the buffer during that time= =E2=80=9C > > isn't a bug, it's a possible user behaviour that we can't control. But > > org-crypt can mention that that behaviour is unsafe when using on-disk > > cache. Or detect it (if it's fast) and warn the user. > > I did not mean that opening/closing buffer is a bug. > And I do not see why this behavior is unsafe, sorry. > Closing a buffer is unsafe when this happens at the same time: 1. you have org-element-cache-persistent set to t (the default) 2. you're using org-crypt and have temporarily decrypted a region but for some reason not reencrypted yet (maybe you plan to reencrypt it some hours later today) 3. the cache directory is in a place which is not as private as the org file. E.g. a network disk, an unencrypted hard drive etc. It's unsafe because closing the buffer triggers saving the org-element cache to disk. > > > > Disabling backups makes sense too, if we decide that unencrypted > > private data shouldn't end up in backups. > > I don't have an absolute opinion. Some people may prefer having > > backups of all data (including private unencrypted data). > > Actually, thinking about it more, I realize that backups may never > contain unencrypted data as long as we never write this unencrypted data > when saving normally. That's because backup is always taken from disk > and never from the buffer contents. > > So, the real problem to solve is how to _reliably_ prevent the > unencrypted data to be saved onto the disk. > If that works, that's good. > > If it's possible to detect whether encryption failed in this buffer, > > there could be a warning saying =E2=80=9ELast encryption failed. Really > > save?=E2=80=9C. > > Yes. In fact, `org-entrypt-entries' throws an error when encryption > fails. However, this error is displayed as a simple message, which is > immediately hidden by "Wrote ..." message emitted a bit later. > > This is because `basic-save-buffer' has > > ;; Don't let errors prevent saving the buffer. > (with-demoted-errors "Before-save hook error: %S" > (run-hooks 'before-save-hook)) > > If we use `write-contents-functions' instead of `before-save-hook', > there should be no such problem. > It seems so. But can you also prevent auto-save from saving it? I randomly found in tar-mode.el line 860 that auto-save doesn't call the write-contents-functions hook. > What I am saying is that "we might have bugs, so be careful" is not > something we need to write in the documentation. The only exception is > when there is a known, long-living bug, that we cannot fix quickly and > must warn users about. > The needed message isn't =E2=80=9Ewe might have bugs, so be careful=E2=80= =9C =E2=80=A6 but =E2=80=9Eif for some reason you keep org-crypt sections unenc= rypted for long periods of time, be careful=E2=80=9C. That situation may come from user behaviour (e.g. not having enabled org-crypt-use-before-save-magic), not from bugs. > > It would be different If we had a third component=E2=80=A6 E.g. imagine= we had > > a component/overlay/text property/=E2=80=A6 in Emacs that could tell wh= ether a > > buffer's region contains very private information or not; then all > > other components could just obey that setting (that section won't be > > backed up, it won't end up in disk cache, =E2=80=A6 It can even be disp= layed > > in a different face). Then org-crypt just needs to set that flag when > > encryption fails. Does something like that exist? Anyway this is a bit > > utopic or overengineered. Simpler ways of improving things are with > > documentation (e.g. =E2=80=9EDon't do this, it's unsafe=E2=80=9C), with= messages > > (=E2=80=9EYou're doing this, which may be unsafe=E2=80=9C), or with que= stions (=E2=80=9EReally > > do this unsafe thing?=E2=80=9C) > > Sounds interesting, but I am afraid that this idea is too abstract. It > is not clear what Emacs is supposed to do with such regions. Maybe Eli > has something better to say. > By the way, there's already reveal-mode which marks some private sections and replaces them with asterisks. For instance if you edit ~/.authinfo and write this machine some_pc login my_user port su password my_password =E2=80=A6then you'll see machine some_pc login my_user port su password ******** unless you position the cursor there. It seems it's a display thing only, using overlays. I thought that maybe unencrypted org-crypt sections could be marked or displayed like that (with * when unfocused), and then org-element could detect them and avoid caching those parts. But I'm not sure if org-persist sees overlays. Anyway this is beyond my Emacs knowledge and I'm speculating. also don't know whether =E2=80=9Eunfocused unencrypted org-crypt sections= =E2=80=9C replaced by asterisks would look nice.