GNU logs - #58781, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#58781: 28.2; move-file-to-trash may move file across filesystems
Resent-From: Gustavo Barros <gusbrs.2016@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Oct 2022 20:01:02 +0000
Resent-Message-ID: <handler.58781.B.166672805819175 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 58781 <at> debbugs.gnu.org
MIME-Version: 1.0
From: Gustavo Barros <gusbrs.2016@HIDDEN>
Date: Tue, 25 Oct 2022 17:00:37 -0300
Message-ID: <CAM9ALR949FxZK-Eby-_aWZJT7u64S0nUMSJ+Ekk+ed2tugaQug@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::534;
 envelope-from=gtvbrs@HIDDEN; helo=mail-pg1-x534.google.com
X-Spam_score_int: -10
X-Spam_score: -1.1
X-Spam_bar: -
X-Spam_report: (-1.1 / 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_FROM=0.001,
 HK_RANDOM_ENVFROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.3 (-)

Hi All,

I'm trying to investigate bug#58721
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01987.html),
couldn't figure it out yet, but in the process of doing so, I've found
another issue.  Namely, that `move-file-to-trash' may move the file
across filesystems with some undesired implications, including
potential security risk.

This happens because, for the case using the freedesktop.org method,
in setting trash directory, the procedure is the following:

    (xdg-data-dir
     (directory-file-name
      (expand-file-name "Trash"
                        (or (getenv "XDG_DATA_HOME")
                            "~/.local/share"))))

There's no provision to check whether `xdg-data-dir' belongs to the
same filesystem (partition) as the file being moved there.  As a
result, the `move-file-to-trash' may move the file across filesystems.
Indeed, I've tested it and, if you are trashing a file from a
different partition, it ends in "~/.local/share" regardless.

This is a problem for at least two reasons.  First, what should be a
cheap operation, a simple "rename", can become very costly if what is
being trashed is large, because now the file has to be physically
moved.  Second, it may be a security risk.

It certainly is for my setup, for example.  It involves two
partitions, one for the operating system, unencrypted, which includes
"/home/username/", and another one, luks encrypted, where I keep my
user files, and which is symlinked to "/home/username/".  So, trashing
a file from dired, with such a setup, results in the files being
stored unencrypted, when they shouldn't.  I wouldn't say there's
nothing much peculiar in this setup, it is certainly legitimate.

I'm not sure what's the standard expected behavior (I suppose the
freedesktop.org specs for it).  But my distro's file manager (which
happens to be `nemo' from Linux Mint) certainly does not do that.  It
sends such files to a different trash directory at the root of the
other partition's mount point.

Best regards,
Gustavo.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Gustavo Barros <gusbrs.2016@HIDDEN>
Subject: bug#58781: Acknowledgement (28.2; move-file-to-trash may move
 file across filesystems)
Message-ID: <handler.58781.B.166672805819175.ack <at> debbugs.gnu.org>
References: <CAM9ALR949FxZK-Eby-_aWZJT7u64S0nUMSJ+Ekk+ed2tugaQug@HIDDEN>
X-Gnu-PR-Message: ack 58781
X-Gnu-PR-Package: emacs
Reply-To: 58781 <at> debbugs.gnu.org
Date: Tue, 25 Oct 2022 20:01:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 58781 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
58781: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D58781
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#58781: 28.2; move-file-to-trash may move file across filesystems
Resent-From: Gustavo Barros <gusbrs.2016@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Oct 2022 21:59:01 +0000
Resent-Message-ID: <handler.58781.B58781.166673508730295 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 58781 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <CAM9ALR949FxZK-Eby-_aWZJT7u64S0nUMSJ+Ekk+ed2tugaQug@HIDDEN>
In-Reply-To: <CAM9ALR949FxZK-Eby-_aWZJT7u64S0nUMSJ+Ekk+ed2tugaQug@HIDDEN>
From: Gustavo Barros <gusbrs.2016@HIDDEN>
Date: Tue, 25 Oct 2022 18:57:46 -0300
Message-ID: <CAM9ALR9tf8bqHcy7qT4XZaEgyHpDm2GWVQVsDtxOGD8HEm_zUQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi All,

a couple of additions to this report.

First, I did some searching on the freedesktop.org specs, which I
found at: https://specifications.freedesktop.org/trash-spec/trashspec-lates=
t.html.
The relevant bit seems to be:

"A system can have one or more trash directories. The contents of any
trash directory are to be compliant with the same standard, described
below.

For every user a =E2=80=9Chome trash=E2=80=9D directory MUST be available. =
Its name
and location are $XDG_DATA_HOME/Trash; $XDG_DATA_HOME is the base
directory for user-specific data, as defined in the Desktop Base
Directory Specification .

The =E2=80=9Chome trash=E2=80=9D SHOULD function as the user's main trash d=
irectory.
Files that the user trashes from the same file system
(device/partition) SHOULD be stored here (see the next section for the
storage details). A =E2=80=9Chome trash=E2=80=9D directory SHOULD be automa=
tically
created for any new user. If this directory is needed for a trashing
operation but does not exist, the implementation SHOULD automatically
create it, without any warnings or delays.

The implementation MAY also support trashing files from the rest of
the system (including other partitions, shared network resources, and
removable devices) into the =E2=80=9Chome trash=E2=80=9D directory . This i=
s a
=E2=80=9Cfailsafe=E2=80=9D method: trashing works for all file locations, t=
he user can
not fill up any space except the home directory, and as other users
generally do not have access to it, no security issues arise.

However, this solution leads to costly file copying (between
partitions, over the network, from a removable device, etc.) A delay
instead of a quick =E2=80=9Cdelete=E2=80=9D operation can be unpleasant to =
users.

An implementation MAY choose not to support trashing in some of these
cases (notably on network resources and removable devices). This is
what some well known operating systems do.

It MAY also choose to provide trashing in the =E2=80=9Ctop directories=E2=
=80=9D of
some or all mounted resources." Etc.

This means `move-file-to-trash' is technically within specs, since
"The implementation MAY also support trashing files from the rest of
the system (including other partitions, shared network resources, and
removable devices) into the =E2=80=9Chome trash=E2=80=9D directory." I hear=
tily
disagree though with the "no security issues arise" statement. And I
still think it would be better to support trashing to "top
directories". Of course, this makes this report a "feature request"
rather than a "bug".

Second, for anyone else half as concerned with this as I am, you may
be interested in a workaround too. For the time being, I'm using:

    (defun system-move-file-to-trash (filename)
      (if-let ((exec (executable-find "gio")))
          (let ((fn (directory-file-name (expand-file-name filename))))
            (set-process-sentinel
             (start-process "trash-file" nil exec "trash" fn)
             (lambda (_proc event)
               (when (string-match-p "^exited abnormally.*" event)
                 (message "Sorry, couldn't trash the file.")))))
        (error "Executable `gio' not found, can't trash file.")))

This is somewhat ad hoc, using the way `move-file-to-trash' is
constructed to support Windows I suppose, but it gets things done. It
is system dependent too, but it is a matter of finding the right
command line incantation for trashing a file in your system to adjust
things.

Best regards,
Gustavo.

On Tue, 25 Oct 2022 at 17:00, Gustavo Barros <gusbrs.2016@HIDDEN> wrote:
>
> Hi All,
>
> I'm trying to investigate bug#58721
> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01987.html),
> couldn't figure it out yet, but in the process of doing so, I've found
> another issue.  Namely, that `move-file-to-trash' may move the file
> across filesystems with some undesired implications, including
> potential security risk.
>
> This happens because, for the case using the freedesktop.org method,
> in setting trash directory, the procedure is the following:
>
>     (xdg-data-dir
>      (directory-file-name
>       (expand-file-name "Trash"
>                         (or (getenv "XDG_DATA_HOME")
>                             "~/.local/share"))))
>
> There's no provision to check whether `xdg-data-dir' belongs to the
> same filesystem (partition) as the file being moved there.  As a
> result, the `move-file-to-trash' may move the file across filesystems.
> Indeed, I've tested it and, if you are trashing a file from a
> different partition, it ends in "~/.local/share" regardless.
>
> This is a problem for at least two reasons.  First, what should be a
> cheap operation, a simple "rename", can become very costly if what is
> being trashed is large, because now the file has to be physically
> moved.  Second, it may be a security risk.
>
> It certainly is for my setup, for example.  It involves two
> partitions, one for the operating system, unencrypted, which includes
> "/home/username/", and another one, luks encrypted, where I keep my
> user files, and which is symlinked to "/home/username/".  So, trashing
> a file from dired, with such a setup, results in the files being
> stored unencrypted, when they shouldn't.  I wouldn't say there's
> nothing much peculiar in this setup, it is certainly legitimate.
>
> I'm not sure what's the standard expected behavior (I suppose the
> freedesktop.org specs for it).  But my distro's file manager (which
> happens to be `nemo' from Linux Mint) certainly does not do that.  It
> sends such files to a different trash directory at the root of the
> other partition's mount point.
>
> Best regards,
> Gustavo.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#58781: 28.2; move-file-to-trash may move file across filesystems
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 26 Oct 2022 06:23:02 +0000
Resent-Message-ID: <handler.58781.B58781.166676537932069 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Gustavo Barros <gusbrs.2016@HIDDEN>, 58781 <at> debbugs.gnu.org
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CAM9ALR9tf8bqHcy7qT4XZaEgyHpDm2GWVQVsDtxOGD8HEm_zUQ@HIDDEN>
References: <CAM9ALR949FxZK-Eby-_aWZJT7u64S0nUMSJ+Ekk+ed2tugaQug@HIDDEN>
 <CAM9ALR9tf8bqHcy7qT4XZaEgyHpDm2GWVQVsDtxOGD8HEm_zUQ@HIDDEN>
MIME-Version: 1.0
Date: Tue, 25 Oct 2022 23:22:51 -0700
Message-ID: <CADwFkm=cx_ou0xf38S9jdBfJGjafLpU-CW4F425EiK9zdeNgcA@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

tags 58781 + security
thanks

Gustavo Barros <gusbrs.2016@HIDDEN> writes:

> This means `move-file-to-trash' is technically within specs, since
> "The implementation MAY also support trashing files from the rest of
> the system (including other partitions, shared network resources, and
> removable devices) into the =E2=80=9Chome trash=E2=80=9D directory." I he=
artily
> disagree though with the "no security issues arise" statement.

Yes, that argument overlooks what happens when files are moved from
encrypted partitions to unencrypted ones.  That is bad.

Maybe someone should bring this issue to the xdg mailing list?

BTW, I also wonder why there is no "xdg-trash" script that we could use.

> And I still think it would be better to support trashing to "top
> directories". Of course, this makes this report a "feature request"
> rather than a "bug".

Agreed, but I don't think this makes it into a non-bug.

> Second, for anyone else half as concerned with this as I am, you may
> be interested in a workaround too. For the time being, I'm using:
>
>     (defun system-move-file-to-trash (filename)
>       (if-let ((exec (executable-find "gio")))
>           (let ((fn (directory-file-name (expand-file-name filename))))
>             (set-process-sentinel
>              (start-process "trash-file" nil exec "trash" fn)
>              (lambda (_proc event)
>                (when (string-match-p "^exited abnormally.*" event)
>                  (message "Sorry, couldn't trash the file.")))))
>         (error "Executable `gio' not found, can't trash file.")))
>
> This is somewhat ad hoc, using the way `move-file-to-trash' is
> constructed to support Windows I suppose, but it gets things done. It
> is system dependent too, but it is a matter of finding the right
> command line incantation for trashing a file in your system to adjust
> things.

Could you write this up as a proper patch, instead?

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 26 Oct 2022 06:22:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 26 02:22:59 2022
Received: from localhost ([127.0.0.1]:53074 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1onZoZ-0008L3-22
	for submit <at> debbugs.gnu.org; Wed, 26 Oct 2022 02:22:59 -0400
Received: from mail-oa1-f48.google.com ([209.85.160.48]:40941)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1onZoX-0008KX-8u
 for control <at> debbugs.gnu.org; Wed, 26 Oct 2022 02:22:57 -0400
Received: by mail-oa1-f48.google.com with SMTP id
 586e51a60fabf-13bd19c3b68so8143416fac.7
 for <control <at> debbugs.gnu.org>; Tue, 25 Oct 2022 23:22:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:to:subject:message-id:date:mime-version
 :references:in-reply-to:from:from:to:cc:subject:date:message-id
 :reply-to; bh=ZeWpy132U6icfHRVeo3FETvtII+GSOv+uhCjJYjMvf8=;
 b=GsogkgG8Jpa0damOc05qqncu29sViQfudIj7a2M5chx2RwBX7VU5Gb+kztwJhlhiIf
 wjexsv63Ia+NuoqvmY/7yGjY0UAoOpahD95bGmUnxQ2+5Hs3Wa4CPs/xcggPBuFWN8N9
 Dri5KzQ5j4fdJRDauguhRRr7WEaYjhFEp+3BS/2ZquAU9Zm9GsLdHHcYbjhpnRR1ma9s
 0FIxGRc9rWCtgKRl4EDSIavWYdwPNAwL6DduEDeBg4Bvm+br3aqh0kDLGWJXbCsWQHcv
 X+crxQWM4z4GyFbTU9tnZsCxSJ6VtwC93KmZV8bNEby0YtYdHwdVtCmUxsZ42mezrfTg
 4pWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:to:subject:message-id:date:mime-version
 :references:in-reply-to:from:x-gm-message-state:from:to:cc:subject
 :date:message-id:reply-to;
 bh=ZeWpy132U6icfHRVeo3FETvtII+GSOv+uhCjJYjMvf8=;
 b=CX3Q54pnKf1WhJVfVKcxXUvaN5jSZQP7yYI+VRWU4hbp1+E4hRA2qNFhHtwiKYcOLk
 96GxpghpYoQ27pcJryO6pLMqVr/Yt3h2KBIddaPYIOlSYKOq6T9wqHSmJHPiWoc5mGdY
 4ZXnv7so6Wdnzz0XVHOvJn8wQxKzBK4gF2W3I2ojFJjWphBqmBZciu6VBBWlxjW0kVyh
 uDbe999cwgMe33JTpxGqy3blnUwRABrRI0P9GYKrsYhWa0GMWXUR8B1bfptmnDtYqHVs
 VjSeM1GPBRIrybsX81YOmOOgUhbRY7nmTmXa3p3EfzezKlTnUzZeGxUAfEYnyf9lCLft
 TxFw==
X-Gm-Message-State: ACrzQf14RE8di6iVZ6ggvnfEL851yoR2zu1L2dxoBHyDUTJb/NT8wY7B
 xf3QGh1vRK0b1MjBoB5fq9wvmU0H0Wuj0ZyQl+w=
X-Google-Smtp-Source: AMsMyM5U4iCmbdGVcRTAdpojAS0UND14AeGYA0ATGdh+LxyBh4s+XvTGXvA0pxu/GINtaGeGvMa3yD3U5UEY1lb+D3s=
X-Received: by 2002:a05:6870:d79a:b0:136:50d7:faa9 with SMTP id
 bd26-20020a056870d79a00b0013650d7faa9mr1194643oab.92.1666765371660; Tue, 25
 Oct 2022 23:22:51 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Tue, 25 Oct 2022 23:22:51 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <CAM9ALR9tf8bqHcy7qT4XZaEgyHpDm2GWVQVsDtxOGD8HEm_zUQ@HIDDEN>
References: <CAM9ALR949FxZK-Eby-_aWZJT7u64S0nUMSJ+Ekk+ed2tugaQug@HIDDEN>
 <CAM9ALR9tf8bqHcy7qT4XZaEgyHpDm2GWVQVsDtxOGD8HEm_zUQ@HIDDEN>
X-Hashcash: 1:20:221026:58781 <at> debbugs.gnu.org::ZrMpH4JS0uy4TkCx:5OId
MIME-Version: 1.0
Date: Tue, 25 Oct 2022 23:22:51 -0700
Message-ID: <CADwFkm=cx_ou0xf38S9jdBfJGjafLpU-CW4F425EiK9zdeNgcA@HIDDEN>
Subject: Re: bug#58781: 28.2;
 move-file-to-trash may move file across filesystems
To: Gustavo Barros <gusbrs.2016@HIDDEN>, 58781 <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Bcc: control <at> debbugs.gnu.org
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

tags 58781 + security
thanks

Gustavo Barros <gusbrs.2016@HIDDEN> writes:

> This means `move-file-to-trash' is technically within specs, since
> "The implementation MAY also support trashing files from the rest of
> the system (including other partitions, shared network resources, and
> removable devices) into the =E2=80=9Chome trash=E2=80=9D directory." I he=
artily
> disagree though with the "no security issues arise" statement.

Yes, that argument overlooks what happens when files are moved from
encrypted partitions to unencrypted ones.  That is bad.

Maybe someone should bring this issue to the xdg mailing list?

BTW, I also wonder why there is no "xdg-trash" script that we could use.

> And I still think it would be better to support trashing to "top
> directories". Of course, this makes this report a "feature request"
> rather than a "bug".

Agreed, but I don't think this makes it into a non-bug.

> Second, for anyone else half as concerned with this as I am, you may
> be interested in a workaround too. For the time being, I'm using:
>
>     (defun system-move-file-to-trash (filename)
>       (if-let ((exec (executable-find "gio")))
>           (let ((fn (directory-file-name (expand-file-name filename))))
>             (set-process-sentinel
>              (start-process "trash-file" nil exec "trash" fn)
>              (lambda (_proc event)
>                (when (string-match-p "^exited abnormally.*" event)
>                  (message "Sorry, couldn't trash the file.")))))
>         (error "Executable `gio' not found, can't trash file.")))
>
> This is somewhat ad hoc, using the way `move-file-to-trash' is
> constructed to support Windows I suppose, but it gets things done. It
> is system dependent too, but it is a matter of finding the right
> command line incantation for trashing a file in your system to adjust
> things.

Could you write this up as a proper patch, instead?

Last modified: Wed, 26 Oct 2022 06:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.