From: Alexei Starovoitov <email@example.com> To: "Eric W. Biederman" <firstname.lastname@example.org> Cc: Tetsuo Handa <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, Kees Cook <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Alexei Starovoitov <email@example.com>, David Miller <firstname.lastname@example.org>, Al Viro <email@example.com>, bpf <firstname.lastname@example.org>, linux-fsdevel <email@example.com>, Daniel Borkmann <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, Masahiro Yamada <firstname.lastname@example.org>, Gary Lin <GLin@suse.com>, Bruno Meneguele <email@example.com> Subject: Re: [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained Date: Thu, 11 Jun 2020 16:31:34 -0700 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Wed, Jun 10, 2020 at 04:12:29PM -0500, Eric W. Biederman wrote: > Alexei Starovoitov <firstname.lastname@example.org> writes: > > > On Tue, Jun 09, 2020 at 03:02:30PM -0500, Eric W. Biederman wrote: > >> Alexei Starovoitov <email@example.com> writes: > >> > >> > bpf_lsm is that thing that needs to load and start acting early. > >> > It's somewhat chicken and egg. fork_usermode_blob() will start a process > >> > that will load and apply security policy to all further forks and > >> > execs. > >> > >> What is the timeframe for bpf_lsm patches wanting to use > >> fork_usermode_blob()? > >> > >> Are we possibly looking at something that will be ready for the next > >> merge window? > > > > In bpf space there are these that want to use usermode_blobs: > > 1. bpfilter itself. > > First of all I think we made a mistake delaying landing the main patches: > > https://lore.kernel.org/patchwork/patch/902785/ > > https://lore.kernel.org/patchwork/patch/902783/ > > without them bpfilter is indeed dead. That probably was the reason > > no one was brave enough to continue working on it. > > So I think the landed skeleton of bpfilter can be removed. > > I think no user space code will notice that include/uapi/linux/bpfilter.h > > is gone. So it won't be considered as user space breakage. > > Similarly CONFIG_BPFILTER can be nuked too. > > bpftool is checking for it (see tools/bpf/bpftool/feature.c) > > but it's fine to remove it. > > I still think that the approach taken was a correct one, but > > lifting that project off the ground was too much for three of us. > > So when it's staffed appropriately we can re-add that code. > > > > 2. bpf_lsm. > > It's very active at the moment. I'm working on it as well > > (sleepable progs is targeting that), but I'm not sure when folks > > would have to have it during the boot. So far it sounds that > > they're addressing more critical needs first. "bpf_lsm ready at boot" > > came up several times during "bpf office hours" conference calls, > > so it's certainly on the radar. If I to guess I don't think > > bpf_lsm will use usermode_blobs in the next 6 weeks. > > More likely 2-4 month. > > > > 3. bpf iterator. > > It's already capable extension of several things in /proc. > > See https://firstname.lastname@example.org/ > > Cat-ing bpf program as "cat /sys/fs/bpf/my_ipv6_route" > > will produce the same human output as "cat /proc/net/ipv6_route". > > The key difference is that bpf is all tracing based and it's unstable. > > struct fib6_info can change and prog will stop loading. > > There are few FIXME in there. That is being addressed right now. > > After that the next step is to make cat-able progs available > > right after boot via usermode_blobs. > > Unlike cases 1 and 2 here we don't care that they appear before pid 1. > > They can certainly be chef installed and started as services. > > But they are kernel dependent, so deploying them to production > > is much more complicated when they're done as separate rpm. > > Testing is harder and so on. Operational issues pile up when something > > that almost like kernel module is done as a separate package. > > Hence usermode_blob fits the best. > > Of course we were not planning to add a bunch of them to kernel tree. > > The idea was to add only _one_ such cat-able bpf prog and have it as > > a selftest for usermode_blob + bpf_iter. What we want our users to > > see in 'cat my_ipv6_route' is probably different from other companies. > > These patches will likely be using usermode_blob() in the next month. > > > > But we don't need to wait. We can make the progress right now. > > How about we remove bpfilter uapi and rename net/bpfilter/bpfilter_kern.c > > into net/umb/umb_test.c only to exercise Makefile to build elf file > > from simple main.c including .S with incbin trick > > and kernel side that does fork_usermode_blob(). > > And that's it. > > net/ipv4/bpfilter/sockopt.c and kconfig can be removed. > > That would be enough base to do use cases 2 and 3 above. > > Having such selftest will be enough to adjust the layering > > for fork_usermode_blob(), right? > > If I understand correctly you are asking people to support out of tree > code. I see some justification for this functionality for in-tree code. > For out of tree code there really is no way to understand support or > maintain the code. It's just like saying that sys_finit_module() is there to support out of tree code. There are in- and out- tree modules and there will be in- and out- of tree bpf programs, but the focus is on those that are relevant for the long term future of the kernel. The 1 case above is in-tree only. There is nothing in bpfilter that makes sense out of tree. The 2 case (bpf_lsm) is primarily in-tree. Security is something everyone wants its own way, but majority of bpf_lsm functionality should live in-tree. The 3 case is mostly out-of-tree. If there was obvious way to extend /proc it could have been in-tree, but no one will agree. > We probably also need to have a conversation about why this > functionality is a better choice that using a compiled in initramfs, > such as can be had by setting CONFIG_INITRAMFS_SOURCE. I explained it several times already. I don't see how initramfs solves 1 and 2. > Even with this write up and the conversations so far I don't understand > what problem fork_usermode_blob is supposed to be solving. Is there > anything kernel version dependent about bpf_lsm? For me the primary > justification of something like fork_usermode_blob is something that is > for all practical purposes a kernel module but it just happens to run in > usermode. that's what it is. It's a kernel module that runs in user space. > From what little I know about bpf_lsm that isn't the case. So far all It is. > you have mentioned is that bpf_lsm needs to load early. That seems like > something that could be solved by a couple of lines init/main.c that > forks and exec's a program before init if it is present. Maybe that > also needs a bit of protection so the bootloader can't override the > binary. > > The entire concept of a loadable lsm has me scratching my head. Last > time that concept was seriously looked at the races for initializing per > object data were difficult enough to deal with modular support was > removed from all of the existing lsms. I'm not sure what races you're talking about. usermode_blob will interact with kernel via syscalls and other standard communication mechanism. > Not to mention there are places where the lsm hooks are a pretty lousy > API and will be refactored to make things better with no thought of any > out of tree code. I don't see how refactoring LSM hooks is relevant in this discussion. > > > If I understood you correctly you want to replace pid_t > > in 'struct umh_info' with proper 'struct pid' pointer that > > is refcounted, so user process's exit is clean? What else? > > No "if (filename)" or "if (file)" on the exec code paths. No extra case > for the LSM's to have to deal with. Nothing fork_usermode_blob does is > something that can't be done from userspace as far as execve is > concerned so there is no justification for any special cases in the core > of the exec code. Adding getname_kernel() instead of filename==NULL is trivial enough and makes sense as a cleanup. But where do you see 'if (file)' ? The correct 'file' pointer is passed from shmem_kernel_file_setup() all the way to exec. > Getting the deny_write_count and the reference count correct on the file > argument as well as getting BPRM_FLAGS_PATH_INACCESSIBLE set. There is no fd because there is no task, but there is a file. I think do_execve should assume BINPRM_FLAGS_PATH_INACCESSIBLE in this case. > Using the proper type for argv and envp. I guess that's going to be a part of other cleanup. > Those are the things I know of that need to be addressed. > > > Getting the code refactored so that the do_open_execat can be called > in do_execveat_common instead of __do_execve_file is enough of a > challenge of code motion I really would rather not do that. Unfortunately that is > the only way I can see right now to have both do_execveat_common and > do_execve_file pass in a struct file. The 'struct file' is there. Please take another look at the code. > Calling deny_write_access and get_file in do_execve_file and probably > a bit more is the only way I can see to cleanly isoloate the special > cases fork_usermode_blob brings to the table. > > > Strictly speaking I am also aware of the issue that the kernel has to > use set_fs(KERNEL_DS) to allow argv and envp to exist in kernel space > instead of userspace. That needs to be fixed as well, but for all > kernel uses of exec. So any work fixing fork_usermode_blob can ignore > that issue. well, this is the problem of usermodehelper_exec. usermode_blob doesn't use argv/envp. They could be NULL for all practical purpose.
next prev parent reply index Thread overview: 193+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20200329005528.xeKtdz2A0email@example.com> [not found] ` <firstname.lastname@example.org> [not found] ` <202006051903.C44988B@keescook> 2020-06-06 19:20 ` Eric W. Biederman 2020-06-06 20:19 ` Alexei Starovoitov 2020-06-06 22:33 ` Linus Torvalds 2020-06-07 1:49 ` Alexei Starovoitov 2020-06-07 2:19 ` Linus Torvalds 2020-06-07 16:09 ` Eric W. Biederman 2020-06-08 16:20 ` Alexei Starovoitov 2020-06-08 16:40 ` Greg KH 2020-06-08 18:35 ` Kees Cook 2020-06-09 1:26 ` Alexei Starovoitov 2020-06-09 15:37 ` Kees Cook 2020-06-09 19:51 ` Eric W. Biederman 2020-06-07 2:31 ` Tetsuo Handa 2020-06-08 16:23 ` Alexei Starovoitov 2020-06-08 23:22 ` Tetsuo Handa 2020-06-09 1:28 ` Alexei Starovoitov 2020-06-09 5:29 ` Tetsuo Handa 2020-06-09 22:32 ` Alexei Starovoitov 2020-06-09 23:30 ` Tetsuo Handa 2020-06-10 0:05 ` Alexei Starovoitov 2020-06-10 3:08 ` Tetsuo Handa 2020-06-10 3:32 ` Alexei Starovoitov 2020-06-10 7:30 ` Tetsuo Handa 2020-06-10 16:24 ` Casey Schaufler 2020-06-09 20:02 ` Eric W. Biederman 2020-06-09 23:56 ` Alexei Starovoitov 2020-06-10 21:12 ` Eric W. Biederman 2020-06-11 23:31 ` Alexei Starovoitov [this message] 2020-06-12 0:57 ` Tetsuo Handa 2020-06-13 3:38 ` Alexei Starovoitov 2020-06-13 4:22 ` Tetsuo Handa 2020-06-13 14:08 ` Eric W. Biederman 2020-06-13 15:33 ` Alexei Starovoitov 2020-06-13 16:14 ` Alexei Starovoitov 2020-06-14 14:51 ` Eric W. Biederman 2020-06-16 1:55 ` Alexei Starovoitov 2020-06-16 16:21 ` Alexei Starovoitov 2020-06-23 18:04 ` Eric W. Biederman 2020-06-23 18:35 ` Alexei Starovoitov 2020-06-23 18:53 ` Eric W. Biederman 2020-06-23 19:40 ` Alexei Starovoitov 2020-06-24 1:51 ` Tetsuo Handa 2020-06-24 4:00 ` Alexei Starovoitov 2020-06-24 4:58 ` Tetsuo Handa 2020-06-24 6:39 ` Alexei Starovoitov 2020-06-24 7:05 ` Tetsuo Handa 2020-06-24 15:41 ` Casey Schaufler 2020-06-24 17:54 ` Alexei Starovoitov 2020-06-24 19:48 ` Casey Schaufler 2020-06-24 6:05 ` Alexei Starovoitov 2020-06-24 14:18 ` Alexei Starovoitov 2020-06-24 12:13 ` Eric W. Biederman 2020-06-24 14:26 ` Alexei Starovoitov 2020-06-24 23:14 ` Tetsuo Handa 2020-06-25 1:35 ` Alexei Starovoitov 2020-06-25 6:38 ` Tetsuo Handa 2020-06-25 9:57 ` Greg KH 2020-06-25 11:03 ` Tetsuo Handa 2020-06-25 12:07 ` Greg KH 2020-06-25 14:21 ` Tetsuo Handa 2020-06-25 19:34 ` David Miller 2020-06-26 1:36 ` Linus Torvalds 2020-06-26 1:51 ` Alexei Starovoitov 2020-06-26 4:58 ` Tetsuo Handa 2020-06-26 5:41 ` Alexei Starovoitov 2020-06-26 6:20 ` Tetsuo Handa 2020-06-26 6:39 ` Alexei Starovoitov 2020-06-26 12:51 ` [PATCH 00/14] Make the user mode driver code a better citizen Eric W. Biederman 2020-06-26 12:53 ` [PATCH 01/14] umh: Capture the pid in umh_pipe_setup Eric W. Biederman 2020-06-26 12:53 ` [PATCH 02/14] umh: Move setting PF_UMH into umh_pipe_setup Eric W. Biederman 2020-06-26 12:54 ` [PATCH 03/14] umh: Rename the user mode driver helpers for clarity Eric W. Biederman 2020-06-26 12:54 ` [PATCH 04/14] umh: Remove call_usermodehelper_setup_file Eric W. Biederman 2020-06-26 12:55 ` [PATCH 05/14] umh: Separate the user mode driver and the user mode helper support Eric W. Biederman 2020-06-26 16:22 ` Tetsuo Handa 2020-06-26 16:45 ` Eric W. Biederman 2020-06-27 1:26 ` Tetsuo Handa 2020-06-27 4:21 ` Eric W. Biederman 2020-06-27 4:36 ` Tetsuo Handa 2020-06-26 12:55 ` [PATCH 06/14] umd: For clarity rename umh_info umd_info Eric W. Biederman 2020-06-26 15:37 ` Kees Cook 2020-06-26 16:31 ` Eric W. Biederman 2020-06-26 12:56 ` [PATCH 07/14] umd: Rename umd_info.cmdline umd_info.driver_name Eric W. Biederman 2020-06-26 12:56 ` [PATCH 08/14] umd: Transform fork_usermode_blob into fork_usermode_driver Eric W. Biederman 2020-06-26 12:57 ` [PATCH 09/14] umh: Stop calling do_execve_file Eric W. Biederman 2020-06-26 12:57 ` [PATCH 10/14] exec: Remove do_execve_file Eric W. Biederman 2020-06-26 12:58 ` [PATCH 11/14] bpfilter: Move bpfilter_umh back into init data Eric W. Biederman 2020-06-26 12:58 ` [PATCH 12/14] umd: Track user space drivers with struct pid Eric W. Biederman 2020-06-26 12:59 ` [PATCH 13/14] bpfilter: Take advantage of the facilities of " Eric W. Biederman 2020-06-26 12:59 ` [PATCH 14/14] umd: Remove exit_umh Eric W. Biederman 2020-06-26 13:48 ` [PATCH 00/14] Make the user mode driver code a better citizen Eric W. Biederman 2020-06-29 19:55 ` [PATCH v2 00/15] " Eric W. Biederman 2020-06-29 19:56 ` [PATCH v2 01/15] umh: Capture the pid in umh_pipe_setup Eric W. Biederman 2020-06-29 19:57 ` [PATCH v2 02/15] umh: Move setting PF_UMH into umh_pipe_setup Eric W. Biederman 2020-06-29 19:57 ` [PATCH v2 03/15] umh: Rename the user mode driver helpers for clarity Eric W. Biederman 2020-06-29 19:59 ` [PATCH v2 04/15] umh: Remove call_usermodehelper_setup_file Eric W. Biederman 2020-06-29 20:00 ` [PATCH v2 05/15] umh: Separate the user mode driver and the user mode helper support Eric W. Biederman 2020-06-30 16:58 ` Linus Torvalds 2020-07-01 17:18 ` Eric W. Biederman 2020-07-01 17:42 ` Alexei Starovoitov 2020-06-29 20:01 ` [PATCH v2 06/15] umd: For clarity rename umh_info umd_info Eric W. Biederman 2020-06-29 20:02 ` [PATCH v2 07/15] umd: Rename umd_info.cmdline umd_info.driver_name Eric W. Biederman 2020-06-29 20:03 ` [PATCH v2 08/15] umd: Transform fork_usermode_blob into fork_usermode_driver Eric W. Biederman 2020-06-29 20:03 ` [PATCH v2 09/15] umh: Stop calling do_execve_file Eric W. Biederman 2020-06-29 20:04 ` [PATCH v2 10/15] exec: Remove do_execve_file Eric W. Biederman 2020-06-30 5:43 ` Christoph Hellwig 2020-06-30 12:14 ` Eric W. Biederman 2020-06-30 13:38 ` Christoph Hellwig 2020-06-30 14:28 ` Eric W. Biederman 2020-06-30 16:55 ` Alexei Starovoitov 2020-06-29 20:05 ` [PATCH v2 11/15] bpfilter: Move bpfilter_umh back into init data Eric W. Biederman 2020-06-29 20:06 ` [PATCH v2 12/15] umd: Track user space drivers with struct pid Eric W. Biederman 2020-06-29 20:06 ` [PATCH v2 13/15] bpfilter: Take advantage of the facilities of " Eric W. Biederman 2020-06-29 20:07 ` [PATCH v2 14/15] umd: Remove exit_umh Eric W. Biederman 2020-06-29 20:08 ` [PATCH v2 15/15] umd: Stop using split_argv Eric W. Biederman 2020-06-29 22:12 ` [PATCH v2 00/15] Make the user mode driver code a better citizen Alexei Starovoitov 2020-06-30 1:13 ` Eric W. Biederman 2020-06-30 6:16 ` Tetsuo Handa 2020-06-30 12:29 ` Eric W. Biederman 2020-06-30 13:21 ` Tetsuo Handa 2020-07-02 13:08 ` Eric W. Biederman 2020-07-02 13:40 ` Tetsuo Handa 2020-07-02 16:02 ` Eric W. Biederman 2020-07-03 13:19 ` Tetsuo Handa 2020-07-03 22:25 ` Eric W. Biederman 2020-07-04 6:57 ` Tetsuo Handa 2020-07-08 4:46 ` Eric W. Biederman 2020-06-30 16:52 ` Alexei Starovoitov 2020-07-01 17:12 ` Eric W. Biederman 2020-07-02 16:40 ` [PATCH v3 00/16] " Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 01/16] umh: Capture the pid in umh_pipe_setup Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 02/16] umh: Move setting PF_UMH into umh_pipe_setup Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 03/16] umh: Rename the user mode driver helpers for clarity Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 04/16] umh: Remove call_usermodehelper_setup_file Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 05/16] umh: Separate the user mode driver and the user mode helper support Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 06/16] umd: For clarity rename umh_info umd_info Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 07/16] umd: Rename umd_info.cmdline umd_info.driver_name Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 08/16] umd: Transform fork_usermode_blob into fork_usermode_driver Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 09/16] umh: Stop calling do_execve_file Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 10/16] exec: Remove do_execve_file Eric W. Biederman 2020-07-08 6:35 ` Luis Chamberlain 2020-07-08 12:41 ` Luis Chamberlain 2020-07-08 13:08 ` Eric W. Biederman 2020-07-08 13:32 ` Luis Chamberlain 2020-07-12 21:02 ` Pavel Machek 2020-07-02 16:41 ` [PATCH v3 11/16] bpfilter: Move bpfilter_umh back into init data Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 12/16] umd: Track user space drivers with struct pid Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 13/16] exit: Factor thread_group_exited out of pidfd_poll Eric W. Biederman 2020-07-03 20:30 ` Alexei Starovoitov 2020-07-03 21:37 ` Eric W. Biederman 2020-07-04 0:03 ` Alexei Starovoitov 2020-07-04 15:50 ` Christian Brauner 2020-07-07 17:09 ` Eric W. Biederman 2020-07-08 0:05 ` Daniel Borkmann 2020-07-08 3:50 ` Eric W. Biederman 2020-07-04 16:00 ` Christian Brauner 2020-07-02 16:41 ` [PATCH v3 14/16] bpfilter: Take advantage of the facilities of struct pid Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 15/16] umd: Remove exit_umh Eric W. Biederman 2020-07-02 16:41 ` [PATCH v3 16/16] umd: Stop using split_argv Eric W. Biederman 2020-07-02 23:51 ` [PATCH v3 00/16] Make the user mode driver code a better citizen Tetsuo Handa 2020-07-09 22:05 ` [merged][PATCH " Eric W. Biederman 2020-07-14 19:42 ` Alexei Starovoitov 2020-07-08 5:20 ` [PATCH v2 00/15] " Luis Chamberlain 2020-06-26 14:10 ` [PATCH 00/14] " Greg Kroah-Hartman 2020-06-26 16:40 ` Alexei Starovoitov 2020-06-26 17:17 ` Eric W. Biederman 2020-06-26 18:22 ` Alexei Starovoitov 2020-06-27 11:38 ` Tetsuo Handa 2020-06-27 12:59 ` Eric W. Biederman 2020-06-27 13:57 ` Tetsuo Handa 2020-06-28 19:44 ` Alexei Starovoitov 2020-06-29 2:20 ` Tetsuo Handa 2020-06-29 20:19 ` Eric W. Biederman 2020-06-30 6:28 ` Tetsuo Handa 2020-06-30 12:32 ` Eric W. Biederman 2020-06-30 16:48 ` Alexei Starovoitov 2020-06-30 21:54 ` Tetsuo Handa 2020-06-30 21:57 ` Alexei Starovoitov 2020-06-30 22:58 ` Tetsuo Handa 2020-06-25 12:56 ` [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained Stephen Smalley 2020-06-25 13:25 ` Greg Kroah-Hartman 2020-06-25 14:26 ` Stephen Smalley 2020-06-25 14:36 ` Stephen Smalley 2020-06-25 15:21 ` Tetsuo Handa 2020-06-25 16:03 ` Stephen Smalley 2020-06-25 16:06 ` Casey Schaufler 2020-06-26 11:30 ` Eric W. Biederman 2020-06-07 5:58 ` Eric W. Biederman 2020-06-07 11:56 ` Eric W. Biederman 2020-06-08 16:35 ` Alexei Starovoitov 2020-06-08 16:33 ` Alexei Starovoitov 2020-06-06 20:43 ` Matthew Wilcox 2020-06-07 15:51 ` Eric W. Biederman 2020-06-07 1:13 ` Tetsuo Handa
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --cc=GLin@suse.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-Fsdevel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \ email@example.com public-inbox-index linux-fsdevel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git