guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemo


From: Eli Zaretskii
Subject: Re: [Nicolas Graves] [PATCH v6 01/10] rde: emacs: Start emacs in --daemon mode, with shepherd and pid-file
Date: Sun, 12 May 2024 12:36:46 +0300

> From: Nicolas Graves <ngraves@ngraves.fr>
> Cc: monnier@iro.umontreal.ca, ludo@gnu.org, emacs-devel@gnu.org,
>  andrew@trop.in, guix-devel@gnu.org, bjorn.bidar@thaodan.de,
>  rudi@constantly.at, felix.lechner@lease-up.com
> Date: Sun, 12 May 2024 09:50:06 +0200
> 
> On 2024-05-12 09:29, Eli Zaretskii wrote:
> 
> > Thanks.  What was the motivation for this, again?
> 
> A light summary (all is in the preceding exchanges in the mailing list):
> 
> - Ludovic Courtès suggested this change because linking with systemd is
> unnecessary (very light usage), and increases the attack surface.
> 
> - Rudolf Schlatte highlights that Lennart Poettering says that the
> notify protocol is stable and independent of libsystemd.
>           https://mastodon.social/@pid_eins/112202687764571433
>           https://mastodon.social/@pid_eins/112202696589971319
>   This mastondon thread itself contains a lot of info/answers about
>   this, including examples of similar work on other projects:
>   - https://github.com/FRRouting/frr/pull/8508
>   - https://github.com/OISF/suricata/pull/10757
>   Lennart Poettering also says that the protocol has been stable for a
>   decade and will surely be for at least another decade.
> 
> This should also answer the worry about significant maintenance.

I'm sorry, but I'm wary of believing such assertions, especially when
systemd is involved.  E.g., what's to prevent people from asking us to
support the various forks of systemd as well?

Reimplementing everything in-house doesn't scale, definitely not in a
project as large as Emacs.  So the argument about smaller attack
surface doesn't really convince me.  Emacs uses quite a lot of
external libraries to the benefit of our users, and that will not
change any time soon.

> What I'm less confident about is edge cases as I highlighted earlier
> (are there cases where systemd's safe_atoi is necessary compared to
> strtol ? Is it fine if LISTEN_FDS is set but LISTEN_PID unset, or
> should be check for LISTEN_PID definition too ?)

This is exactly the kind of maintenance burden I'm concerned about:
who will help us answer these questions, now and in the future?  We
cannot rely on having systemd experts on board at all times.

> >> > - The sd_notify code is taken from
> >> > https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
> >
> > I'm not sure what would be the legal aspects of such code borrowing.
> 
> The code is given as MIT-0, hence also the two different licenses for
> the two functions sd_notify and sd_is_socket. Not an expert on licenses
> either, but with a proper flag about what this function's license is, I
> guess it should be fine, since other projects also do that.

The license is only half of the problem.  Every non-trivial
contribution to Emacs must have its copyright assigned to the FSF,
because the FSF is in charge of protecting the Emacs sources,
something that only the copyright holder can do, at least in some
countries.  You will need to assign the copyright as well (a
relatively simple procedure of filling a form and emailing it), but if
the code is not yours, you cannot assign its copyright.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]