Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-20 Thread Jonathan Dowland
On Fri May 17, 2024 at 11:56 AM BST, Max Nikulin wrote:
> You may file an issue to the emacs bug tracker.

I didn't realise this was coming straight from upstream. If it were
a Debian-local issue, I'd file something, but I will respectfully
decline to engage with Emacs upstream.

(Interesting to see another user of debbugs out there Today, besides
Debian!)

> However at least one developer was against wrappers:
…

Thank you for sharing these upstream bugs. They make for fascinating
(if occasionally horrifying) reading.

> Finally, I think that s-nail should ignore malformed mailcap entries.

I agree.

> On 16/05/2024 14:48, Jonathan Dowland wrote:
> > Please do not CC me for listmail.
>
> You still decided to add my address to CC despite I joined to the 
> thread, not started it. I expect it is enough to guess that I am able to 
> follow the discussion even not being subscribed.

So I did: Apologies! It seems my new favourite MUA (aerc) does not
handle list replies by default as I would like it to/as I was used
to with mutt. I will be more careful.


-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net



Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-17 Thread Jesper Dybdal

On 2024-05-15 17:51, Max Nikulin wrote:

I have filed
https://bugs.debian.org/1071036
update-mime does not escape semicolon in .desktop Exec entries


Thanks!  I should have done that, but I've postponed it because I felt I 
didn't know enough about the context.  (I just run Emacs on a Debian 
server box, shoving emacs frames on an X server running under Windows.)


--
Jesper Dybdal
https://www.dybdal.dk





Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-17 Thread Max Nikulin

On 16/05/2024 14:48, Jonathan Dowland wrote:

On Wed May 15, 2024 at 4:51 PM BST, Max Nikulin wrote:

https://bugs.debian.org/1071036
update-mime does not escape semicolon in .desktop Exec entries


Re-reading your bug report I'm struck by how hard to reason about
(and test) the emacs .desktop Exec= line is. Personally I'd break
that out to a separate wrapper script, which wouldn't fix the root
issue you've identified, but wouldn't trigger it.


You may file an issue to the emacs bug tracker. I agree that more simple 
Exec entries in .desktop files will be easier to maintain.


However at least one developer was against wrappers:
https://debbugs.gnu.org/57752#8
Lars Ingebrigtsen, Tue, 13 Sep 2022 14:19:47 +0200

I'd prefer to have a .desktop file that works without any helper
scripts.


Later CVE-2023-27985 and CVE-2023-27986 were assigned for quoting in 
emacsclient .desktop files and there was an intermediate step:

https://debbugs.gnu.org/60204

Actually a feature that allows to simplify .desktop files was added to 
the development branch despite strong opposition:

https://debbugs.gnu.org/65902

-Exec=sh -c "u=\\$(echo \\"\\$1\\" | sed 's/[\\"]/&/g'); exec emacsclient --alternate-editor= 
--display=\\"\\$DISPLAY\\" --eval \\"(message-mailto \\"\\$u\\")\\"" sh %u
+Exec=emacsclient --alternate-editor= --eval "(message-mailto (pop 
server-eval-args-left))" %u


From my point of view, the following stance is spectacular:
https://debbugs.gnu.org/65902#79
Eli Zaretskii, Thu, 14 Sep 2023 16:36:06 +0300

Emacs developers make mistakes even in the simple regexps we have in
our code.  That doesn't mean we should abandon regexps.  The solution
for sending Lisp forms to the server exists, and the quoting, although
tricky in some cases, is not rocket science to get right.


emacsclient.desktop still has a complex shell command.

By the way, I have not noticed handling of %f substitutions in Emacs 
code for handling .desktop files, not to mention \n, \t, \s

https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/dired-aux.el#n1364
shell-command-guess-xdg function

Finally, I think that s-nail should ignore malformed mailcap entries.

On 16/05/2024 14:48, Jonathan Dowland wrote:

Please do not CC me for listmail.


You still decided to add my address to CC despite I joined to the 
thread, not started it. I expect it is enough to guess that I am able to 
follow the discussion even not being subscribed.





Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-16 Thread Jonathan Dowland
On Wed May 15, 2024 at 4:51 PM BST, Max Nikulin wrote:
> On 07/05/2024 23:24, Max Nikulin wrote:
> >> On 2024-05-06 17:04, Max Nikulin wrote:
> >>> So doubled backslashes (as in .desktop files) are correct.
> >>>
> >>> What is wrong is lack of backslashes added before ";" and it is a bug.
>
> I have filed
> https://bugs.debian.org/1071036
> update-mime does not escape semicolon in .desktop Exec entries

Thanks for persevering with this!

Re-reading your bug report I'm struck by how hard to reason about
(and test) the emacs .desktop Exec= line is. Personally I'd break
that out to a separate wrapper script, which wouldn't fix the root
issue you've identified, but wouldn't trigger it.


-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net



Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-15 Thread Max Nikulin

On 07/05/2024 23:24, Max Nikulin wrote:

On 2024-05-06 17:04, Max Nikulin wrote:

So doubled backslashes (as in .desktop files) are correct.

What is wrong is lack of backslashes added before ";" and it is a bug.


I have filed
https://bugs.debian.org/1071036
update-mime does not escape semicolon in .desktop Exec entries

This particular bug almost certainly may be fixed by adding an extra 
line of perl code.


However 2 layer of quoting in .desktop files: special rules for Exec and 
general for any strings require more work to get entries properly 
escaped for mailcap in general case.


In the meanwhile I have realized that BASH implementation of parsing 
Exec entries in xdg-open fallback function search_desktop_file is really 
ugly:

https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-open.in?ref_type=heads#L312

I am unsure if it is possible to implement double quotes rule
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html

Since xdg-open usually delegates handling of URIs to the desktop 
environment, this code is active only for those who avoid any DE.




Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-07 Thread Max Nikulin

On 07/05/2024 18:40, Jesper Dybdal wrote:

On 2024-05-06 16:24, Max Nikulin wrote:
2. It does not skip x-scheme-handler/* entries. Are there applications 
that may use such entries?


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291015
mime-support: run‐mailcap to understand URL notation and start 
sensible-browser if required.


A kind of proposal to support x-scheme-handler entries.


On 2024-05-06 17:04, Max Nikulin wrote:

So doubled backslashes (as in .desktop files) are correct.

What is wrong is lack of backslashes added before ";" and it is a bug.


I have now removed the "x-scheme-handler/mailto" entry


I do not think they really hurt, however they are most complex entries, 
so chance that some parser would be confused is higher.



and added backslashes in all the
emacsclient entries in mailcap, and the error messages are gone.


If these edits are outside of user section then entries may be 
regenerated to original form during installing of some package. Please, 
consider filing a bug report.




Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-07 Thread Jesper Dybdal

On 2024-05-06 16:24, Max Nikulin wrote:

On 06/05/2024 20:27, Greg Wooledge wrote:

On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote:

s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
string/command: then exec emacsclient --alternate-editor =
--display=\\"\\$DISPLAY\\" \\"\\$@\\"

...
It seems there are a couple of bugs in update-mime: 

...
2. It does not skip x-scheme-handler/* entries. Are there applications 
that may use such entries?


On 2024-05-06 17:04, Max Nikulin wrote:

So doubled backslashes (as in .desktop files) are correct.

What is wrong is lack of backslashes added before ";" and it is a bug.

I have now removed the "x-scheme-handler/mailto" entry and added 
backslashes in all the

emacsclient entries in mailcap, and the error messages are gone.

Thanks a lot to Max and everybody else who responsed.

Jesper

--
Jesper Dybdal
https://www.dybdal.dk




Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-06 Thread Max Nikulin

On 06/05/2024 21:24, Max Nikulin wrote:

It seems there are a couple of bugs in update-mime:

1. It does not perform an unquote pass that should retain only a half of 
backslashes from Exec field of .desktop file.


I was wrong here. mailcap(5):

(In fact, the backslash can be used to quote any character, including itself.)


So doubled backslashes (as in .desktop files) are correct.

What is wrong is lack of backslashes added before ";" and it is a bug.

grep Exec /usr/share/applications/emacsclient.desktop
Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient 
--alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec 
emacsclient --alternate-editor= --create-frame; fi" sh %F


should be converted to /etc/mailcap entry

application/x-shellscript; sh -c "if [ -n \\"\\$*\\" ]\; then exec 
emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"\; 
else exec emacsclient --alternate-editor= --create-frame\; fi" sh %s; 
test=test -n "$DISPLAY"





Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-06 Thread Max Nikulin

On 06/05/2024 21:41, David Wright wrote:

On Mon 06 May 2024 at 14:53:10 (+0200), Jesper Dybdal wrote:

* In Bookworm:
    mailcap/stable,now 3.70+nmu1 all [installed,automatic]
    j-nail/stable,now 14.9.24-2 amd64 [installed]


  ↑


Has anyone else seen this?


Do you have emacs installed? Rare .desktop files have complex shell 
commands inside. emacsclient treats --display option in a quite specific 
way, so it needs --display="$DISPLAY". Moreover, there is no way to pass 
to emacs "server" arguments like URIs using something similar to argv. 
That is why it is necessary to escape arguments used in lisp expressions


emacsclient --eval "(FUNCTION \"ARGUMENT\")"

Emacs developers are against helper scrips as dedicated files, so there 
are inline script in Exec filed of .desktop files.




Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-06 Thread David Wright
On Mon 06 May 2024 at 14:53:10 (+0200), Jesper Dybdal wrote:

> The package versions involved are:
> * in Bullseye:
>    mailcap/oldstable,now 3.69 all [installed,automatic]
>    s-nail/oldstable,now 14.9.22-1 amd64 [installed]
> * In Bookworm:
>    mailcap/stable,now 3.70+nmu1 all [installed,automatic]
>    j-nail/stable,now 14.9.24-2 amd64 [installed]

 ↑

> Has anyone else seen this?

No.

Cheers,
David.



Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-06 Thread Max Nikulin

On 06/05/2024 20:27, Greg Wooledge wrote:

On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote:

s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
string/command: then exec emacsclient --alternate-editor =
--display=\\"\\$DISPLAY\\" \\"\\$@\\"


The question (one of the questions) is what's putting them there, and I
would guess one of the emacs packages is doing it.


update-mime(8) § DESKTOP ENTRIES

  In addition to the abovementioned mechanism update-mime also
  parses desktop entries in  /usr/share/applications/
  to  generate  mailcap  entries.  These entries are given
  a lower priority than those in /usr/lib/mime/packages.

It seems there are a couple of bugs in update-mime:

1. It does not perform an unquote pass that should retain only a half of 
backslashes from Exec field of .desktop file.
2. It does not skip x-scheme-handler/* entries. Are there applications 
that may use such entries?


Perhaps there is a bug in s-nail as well.



Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-06 Thread Jesper Dybdal

On 2024-05-06 15:27, Greg Wooledge wrote:

On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote:

I use s-nail as my mailx command (selected using the Debian "alternatives"
mechanism).

Since I upgraded from Bullseye to Bookworm, s-nail now shows a bunch of
error messages in connection with viewing messages.  Here is a sample:

s-nail: $MAILCAPS: /etc/mailcap: x-scheme-handler/mailto: ignored
unknown string/command: u = \\${u//\\"/\\"}
s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
string/command: then exec emacsclient --alternate-editor =
--display=\\"\\$DISPLAY\\" \\"\\$@\\"

I don't have lines like this in mine.  Then again, I don't have emacs
installed.

The question (one of the questions) is what's putting them there, and I
would guess one of the emacs packages is doing it.

I have no particular wish to learn about /etc/mailcap.  The only way I've
found to avoid this is to remove the /etc/mailcap file entirely.

I would think deleting any lines containing "emacs" would be slightly
less invasive.  Obviously, make a backup copy of the file first.
That might be an excellent idea.  I've removed all lines with 
"emacsclient" (there were also some with "emacs", but not 
"emacsclient"), and the error messages have disappeared.  Since I only 
use s-nail rarely. it may be a while before I know whether that removal 
also has negative consequences.


Thanks a lot, Greg!

--
Jesper Dybdal
https://www.dybdal.dk




Re: Bookworm's /etc/mailcap seems to break s-nail

2024-05-06 Thread Greg Wooledge
On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote:
> I use s-nail as my mailx command (selected using the Debian "alternatives"
> mechanism).
> 
> Since I upgraded from Bullseye to Bookworm, s-nail now shows a bunch of
> error messages in connection with viewing messages.  Here is a sample:
> > s-nail: $MAILCAPS: /etc/mailcap: x-scheme-handler/mailto: ignored
> > unknown string/command: u = \\${u//\\"/\\"}
> > s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
> > string/command: then exec emacsclient --alternate-editor =
> > --display=\\"\\$DISPLAY\\" \\"\\$@\\"

I don't have lines like this in mine.  Then again, I don't have emacs
installed.

The question (one of the questions) is what's putting them there, and I
would guess one of the emacs packages is doing it.

> I have no particular wish to learn about /etc/mailcap.  The only way I've
> found to avoid this is to remove the /etc/mailcap file entirely.

I would think deleting any lines containing "emacs" would be slightly
less invasive.  Obviously, make a backup copy of the file first.