* bug#47828: seccomp test failures
@ 2021-04-16 16:53 Glenn Morris
2021-04-17 18:21 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2021-04-16 16:53 UTC (permalink / raw)
To: 47828; +Cc: phst
Package: emacs
Version: 28.0.50
On CentOS 8.3 at fb9f5501:
Test emacs-tests/bwrap/allows-stdout condition:
Info: Process output:
(ert-test-failed
((should
(eql status 0))
:form
(eql 159 0)
:value nil))
Test emacs-tests/seccomp/allows-stdout condition:
Info: Process output:
(ert-test-failed
((should
(eql status 0))
:form
(eql "Bad system call" 0)
:value nil))
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-16 16:53 bug#47828: seccomp test failures Glenn Morris
@ 2021-04-17 18:21 ` Philipp Stephani
2021-04-17 19:54 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-17 18:21 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am Fr., 16. Apr. 2021 um 19:59 Uhr schrieb Glenn Morris <rgm@gnu.org>:
>
> Package: emacs
> Version: 28.0.50
>
> On CentOS 8.3 at fb9f5501:
>
> Test emacs-tests/bwrap/allows-stdout condition:
> Info: Process output:
> (ert-test-failed
> ((should
> (eql status 0))
> :form
> (eql 159 0)
> :value nil))
>
> Test emacs-tests/seccomp/allows-stdout condition:
> Info: Process output:
> (ert-test-failed
> ((should
> (eql status 0))
> :form
> (eql "Bad system call" 0)
> :value nil))
Thanks for the report, could you check which syscall failed, e.g. by
checking the kernel audit logs or by posting a stacktrace for the
failure?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-17 18:21 ` Philipp Stephani
@ 2021-04-17 19:54 ` Philipp Stephani
2021-04-18 0:01 ` Glenn Morris
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-17 19:54 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am Sa., 17. Apr. 2021 um 20:21 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Fr., 16. Apr. 2021 um 19:59 Uhr schrieb Glenn Morris <rgm@gnu.org>:
> >
> > Package: emacs
> > Version: 28.0.50
> >
> > On CentOS 8.3 at fb9f5501:
> >
> > Test emacs-tests/bwrap/allows-stdout condition:
> > Info: Process output:
> > (ert-test-failed
> > ((should
> > (eql status 0))
> > :form
> > (eql 159 0)
> > :value nil))
> >
> > Test emacs-tests/seccomp/allows-stdout condition:
> > Info: Process output:
> > (ert-test-failed
> > ((should
> > (eql status 0))
> > :form
> > (eql "Bad system call" 0)
> > :value nil))
>
>
> Thanks for the report, could you check which syscall failed, e.g. by
> checking the kernel audit logs or by posting a stacktrace for the
> failure?
FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
to master which attempts to automatically collect this information to
ease debugging such failures.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-17 19:54 ` Philipp Stephani
@ 2021-04-18 0:01 ` Glenn Morris
2021-04-18 8:32 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2021-04-18 0:01 UTC (permalink / raw)
To: Philipp Stephani; +Cc: Philipp Stephani, 47828
[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]
Philipp Stephani wrote:
> FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
> to master which attempts to automatically collect this information to
> ease debugging such failures.
It doesn't report anything in this case since the user account does not
have permission, and I normally disable core dumps (ulimit -c 0):
Test emacs-tests/seccomp/allows-stdout condition:
Info: Process output:
Potentially relevant Seccomp audit events:
Error opening config file (Permission denied)
NOTE - using built-in logs: /var/log/audit/audit.log
Error opening /var/log/audit/audit.log (Permission denied)
Potentially useful coredump information:
[...]
No coredumps found.
-- Notice: 1 systemd-coredump@.service unit is running, output
may be incomplete.
With my root hat on, the audit.log data is attached.
With core dumps enabled:
#0 0x00007f7b661fb967 __mmap (libc.so.6)
#1 0x00007f7b5ff8001e sss_nss_mc_get_ctx (libnss_sss.so.2)
#2 0x00007f7b5ff80770 sss_nss_mc_getpwuid (libnss_sss.so.2)
#3 0x00007f7b5ff7c61e _nss_sss_getpwuid_r (libnss_sss.so.2)
#4 0x00007f7b661cc3cd getpwuid_r@@GLIBC_2.2.5 (libc.so.6)
#5 0x00007f7b661cbb30 getpwuid (libc.so.6)
#6 0x000000000060d1ee init_editfns (emacs)
#7 0x0000000000566801 main (emacs)
#8 0x00007f7b661277b3 __libc_start_main (libc.so.6)
#9 0x0000000000418cde _start (emacs)
[-- Attachment #2: audit.txt --]
[-- Type: text/plain, Size: 3614 bytes --]
type=SECCOMP msg=audit(1618703239.816:666338): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332316 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 arch=c000003e syscall=158 compat=0 ip=0x7f2bf88850f5 code=0x80000000\x1dAUID="someuser" UID="someuser" GID="somegroup" ARCH=x86_64 SYSCALL=arch_prctl
type=ANOM_ABEND msg=audit(1618703239.816:666339): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332316 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 res=1\x1dAUID="someuser" UID="someuser" GID="somegroup"
type=SERVICE_START msg=audit(1618703239.841:666340): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@89-332317-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1618703240.155:666341): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@89-332317-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SECCOMP msg=audit(1618703240.643:666342): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332329 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 arch=c000003e syscall=9 compat=0 ip=0x7fbb09a6a967 code=0x80000000\x1dAUID="someuser" UID="someuser" GID="somegroup" ARCH=x86_64 SYSCALL=mmap
type=ANOM_ABEND msg=audit(1618703240.643:666343): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332329 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 res=1\x1dAUID="someuser" UID="someuser" GID="somegroup"
type=SERVICE_START msg=audit(1618703240.664:666344): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@90-332330-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1618703241.108:666345): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@90-332330-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SECCOMP msg=audit(1618703241.693:666346): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332347 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 arch=c000003e syscall=9 compat=0 ip=0x7f975300d967 code=0x80000000\x1dAUID="someuser" UID="someuser" GID="somegroup" ARCH=x86_64 SYSCALL=mmap
type=ANOM_ABEND msg=audit(1618703241.693:666347): auid=1000 uid=1000 gid=501 ses=4485 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=332347 comm="emacs" exe="/scratch/someuser/emacs/git/master/src/emacs" sig=31 res=1\x1dAUID="someuser" UID="someuser" GID="somegroup"
type=SERVICE_START msg=audit(1618703241.706:666348): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@91-332348-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1618703242.024:666349): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@91-332348-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'\x1dUID="root" AUID="unset"
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-18 0:01 ` Glenn Morris
@ 2021-04-18 8:32 ` Philipp Stephani
2021-04-18 8:36 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-18 8:32 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am So., 18. Apr. 2021 um 02:01 Uhr schrieb Glenn Morris <rgm@gnu.org>:
>
> Philipp Stephani wrote:
>
> > FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
> > to master which attempts to automatically collect this information to
> > ease debugging such failures.
>
> It doesn't report anything in this case since the user account does not
> have permission, and I normally disable core dumps (ulimit -c 0):
>
> Test emacs-tests/seccomp/allows-stdout condition:
> Info: Process output:
>
> Potentially relevant Seccomp audit events:
> Error opening config file (Permission denied)
> NOTE - using built-in logs: /var/log/audit/audit.log
> Error opening /var/log/audit/audit.log (Permission denied)
>
> Potentially useful coredump information:
> [...]
> No coredumps found.
> -- Notice: 1 systemd-coredump@.service unit is running, output
> may be incomplete.
>
> With my root hat on, the audit.log data is attached.
>
> With core dumps enabled:
> #0 0x00007f7b661fb967 __mmap (libc.so.6)
> #1 0x00007f7b5ff8001e sss_nss_mc_get_ctx (libnss_sss.so.2)
Thanks! Looks like the problem is in
https://github.com/SSSD/sssd/blob/cd843dafe63589d0a77145445c454f6fc19dabae/src/sss_client/nss_mc_common.c#L171-L176,
where the code calls mmap with flags that we don't allow yet
(MAP_SHARED).
Does MAP_SHARED have any security implications? Otherwise we can allow
it right away.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-18 8:32 ` Philipp Stephani
@ 2021-04-18 8:36 ` Philipp Stephani
2021-04-18 16:19 ` Glenn Morris
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-18 8:36 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am So., 18. Apr. 2021 um 10:32 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am So., 18. Apr. 2021 um 02:01 Uhr schrieb Glenn Morris <rgm@gnu.org>:
> >
> > Philipp Stephani wrote:
> >
> > > FYI, I've now pushed commit 568ce6826fa0aaa4d5dc95880cbdc0965dc07521
> > > to master which attempts to automatically collect this information to
> > > ease debugging such failures.
> >
> > It doesn't report anything in this case since the user account does not
> > have permission, and I normally disable core dumps (ulimit -c 0):
> >
> > Test emacs-tests/seccomp/allows-stdout condition:
> > Info: Process output:
> >
> > Potentially relevant Seccomp audit events:
> > Error opening config file (Permission denied)
> > NOTE - using built-in logs: /var/log/audit/audit.log
> > Error opening /var/log/audit/audit.log (Permission denied)
> >
> > Potentially useful coredump information:
> > [...]
> > No coredumps found.
> > -- Notice: 1 systemd-coredump@.service unit is running, output
> > may be incomplete.
> >
> > With my root hat on, the audit.log data is attached.
> >
> > With core dumps enabled:
> > #0 0x00007f7b661fb967 __mmap (libc.so.6)
> > #1 0x00007f7b5ff8001e sss_nss_mc_get_ctx (libnss_sss.so.2)
>
> Thanks! Looks like the problem is in
> https://github.com/SSSD/sssd/blob/cd843dafe63589d0a77145445c454f6fc19dabae/src/sss_client/nss_mc_common.c#L171-L176,
> where the code calls mmap with flags that we don't allow yet
> (MAP_SHARED).
> Does MAP_SHARED have any security implications? Otherwise we can allow
> it right away.
Does commit 2822246b5d8154d0166e17ffd28a1d85b57d68aa fix the issue?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-18 8:36 ` Philipp Stephani
@ 2021-04-18 16:19 ` Glenn Morris
2021-04-18 17:16 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2021-04-18 16:19 UTC (permalink / raw)
To: Philipp Stephani; +Cc: Philipp Stephani, 47828
Philipp Stephani wrote:
> Does commit 2822246b5d8154d0166e17ffd28a1d85b57d68aa fix the issue?
emacs-tests/seccomp/allows-stdout now passes (thanks), but
emacs-tests/bwrap/allows-stdout still fails with status 159:
#0 0x00007f683ca650f5 _dl_sysdep_start (/usr/lib64/ld-2.28.so)
#1 0x00007f683ca4d136 _dl_start (/usr/lib64/ld-2.28.so)
#2 0x00007f683ca4c088 _start (/usr/lib64/ld-2.28.so)
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-18 16:19 ` Glenn Morris
@ 2021-04-18 17:16 ` Philipp Stephani
2021-04-18 21:58 ` Glenn Morris
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-18 17:16 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am So., 18. Apr. 2021 um 18:19 Uhr schrieb Glenn Morris <rgm@gnu.org>:
>
> Philipp Stephani wrote:
>
> > Does commit 2822246b5d8154d0166e17ffd28a1d85b57d68aa fix the issue?
>
> emacs-tests/seccomp/allows-stdout now passes (thanks), but
> emacs-tests/bwrap/allows-stdout still fails with status 159:
>
> #0 0x00007f683ca650f5 _dl_sysdep_start (/usr/lib64/ld-2.28.so)
> #1 0x00007f683ca4d136 _dl_start (/usr/lib64/ld-2.28.so)
> #2 0x00007f683ca4c088 _start (/usr/lib64/ld-2.28.so)
What's the failing syscall in this case?
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-18 17:16 ` Philipp Stephani
@ 2021-04-18 21:58 ` Glenn Morris
2021-04-19 8:36 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2021-04-18 21:58 UTC (permalink / raw)
To: Philipp Stephani; +Cc: Philipp Stephani, 47828
Philipp Stephani wrote:
> What's the failing syscall in this case?
IIUC, it's arch_prctl.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-18 21:58 ` Glenn Morris
@ 2021-04-19 8:36 ` Philipp Stephani
2021-04-19 15:49 ` Glenn Morris
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-19 8:36 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am So., 18. Apr. 2021 um 23:58 Uhr schrieb Glenn Morris <rgm@gnu.org>:
>
> Philipp Stephani wrote:
>
> > What's the failing syscall in this case?
>
> IIUC, it's arch_prctl.
What's the subfunction (first argument)? From looking at the glibc
sources it could be ARCH_CET_STATUS (0x3001).
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-19 8:36 ` Philipp Stephani
@ 2021-04-19 15:49 ` Glenn Morris
2021-04-19 16:00 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2021-04-19 15:49 UTC (permalink / raw)
To: Philipp Stephani; +Cc: Philipp Stephani, 47828
Philipp Stephani wrote:
>> IIUC, it's arch_prctl.
>
> What's the subfunction (first argument)? From looking at the glibc
> sources it could be ARCH_CET_STATUS (0x3001).
How do I find that out?
(If it helps, the start of the posted audit log corresponds to this case:
https://debbugs.gnu.org/cgi/bugreport.cgi?filename=audit.txt;att=1;bug=47828;msg=12
)
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-19 15:49 ` Glenn Morris
@ 2021-04-19 16:00 ` Philipp Stephani
2021-04-19 16:03 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-19 16:00 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am Mo., 19. Apr. 2021 um 17:49 Uhr schrieb Glenn Morris <rgm@gnu.org>:
>
> Philipp Stephani wrote:
>
> >> IIUC, it's arch_prctl.
> >
> > What's the subfunction (first argument)? From looking at the glibc
> > sources it could be ARCH_CET_STATUS (0x3001).
>
> How do I find that out?
I've often had success with installing the debug symbols for the
libraries in question (often they are in a separate package) and then
using coredumpctl debug to drop into GDB.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-19 16:00 ` Philipp Stephani
@ 2021-04-19 16:03 ` Philipp Stephani
2021-04-19 16:39 ` Glenn Morris
0 siblings, 1 reply; 15+ messages in thread
From: Philipp Stephani @ 2021-04-19 16:03 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am Mo., 19. Apr. 2021 um 18:00 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Mo., 19. Apr. 2021 um 17:49 Uhr schrieb Glenn Morris <rgm@gnu.org>:
> >
> > Philipp Stephani wrote:
> >
> > >> IIUC, it's arch_prctl.
> > >
> > > What's the subfunction (first argument)? From looking at the glibc
> > > sources it could be ARCH_CET_STATUS (0x3001).
> >
> > How do I find that out?
>
> I've often had success with installing the debug symbols for the
> libraries in question (often they are in a separate package) and then
> using coredumpctl debug to drop into GDB.
Or alternatively, add a rule like
RULE (SCMP_ACT_ALLOW, SCMP_SYS (arch_prctl),
SCMP_A0_32 (SCMP_CMP_EQ, 0x3001));
to line 350 of lib-src/seccomp-filter.c and check whether it fixes the problem.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-19 16:03 ` Philipp Stephani
@ 2021-04-19 16:39 ` Glenn Morris
2021-04-19 19:31 ` Philipp Stephani
0 siblings, 1 reply; 15+ messages in thread
From: Glenn Morris @ 2021-04-19 16:39 UTC (permalink / raw)
To: Philipp Stephani; +Cc: Philipp Stephani, 47828
Philipp Stephani wrote:
> Or alternatively, add a rule like
>
> RULE (SCMP_ACT_ALLOW, SCMP_SYS (arch_prctl),
> SCMP_A0_32 (SCMP_CMP_EQ, 0x3001));
>
> to line 350 of lib-src/seccomp-filter.c and check whether it fixes the
> problem.
Yes, that fixes it, thank you.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#47828: seccomp test failures
2021-04-19 16:39 ` Glenn Morris
@ 2021-04-19 19:31 ` Philipp Stephani
0 siblings, 0 replies; 15+ messages in thread
From: Philipp Stephani @ 2021-04-19 19:31 UTC (permalink / raw)
To: Glenn Morris; +Cc: Philipp Stephani, 47828
Am Mo., 19. Apr. 2021 um 18:39 Uhr schrieb Glenn Morris <rgm@gnu.org>:
>
> Philipp Stephani wrote:
>
> > Or alternatively, add a rule like
> >
> > RULE (SCMP_ACT_ALLOW, SCMP_SYS (arch_prctl),
> > SCMP_A0_32 (SCMP_CMP_EQ, 0x3001));
> >
> > to line 350 of lib-src/seccomp-filter.c and check whether it fixes the
> > problem.
>
> Yes, that fixes it, thank you.
OK, I've pushed commit 27af0a3dc8b6b45879904bbc5d54b0677f84a5ff.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-04-19 19:31 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-04-16 16:53 bug#47828: seccomp test failures Glenn Morris
2021-04-17 18:21 ` Philipp Stephani
2021-04-17 19:54 ` Philipp Stephani
2021-04-18 0:01 ` Glenn Morris
2021-04-18 8:32 ` Philipp Stephani
2021-04-18 8:36 ` Philipp Stephani
2021-04-18 16:19 ` Glenn Morris
2021-04-18 17:16 ` Philipp Stephani
2021-04-18 21:58 ` Glenn Morris
2021-04-19 8:36 ` Philipp Stephani
2021-04-19 15:49 ` Glenn Morris
2021-04-19 16:00 ` Philipp Stephani
2021-04-19 16:03 ` Philipp Stephani
2021-04-19 16:39 ` Glenn Morris
2021-04-19 19:31 ` Philipp Stephani
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.