mailing list of musl libc
 help / color / Atom feed
* [musl] Re: Outgoing DANE not working
       [not found] ` <49RN803wcfzJrNv@spike.porcupine.org>
@ 2020-05-19 20:08   ` Rich Felker
  0 siblings, 0 replies; 8+ messages in thread
From: Rich Felker @ 2020-05-19 20:08 UTC (permalink / raw)
  To: Postfix users; +Cc: musl

On Tue, May 19, 2020 at 01:25:52PM -0400, Wietse Venema wrote:
> Rich Felker:
> > On Tue, May 19, 2020 at 11:11:56AM -0400, Wietse Venema wrote:
> > > Rich Felker:
> > > > On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> > > > > Rich Felker:
> > > > > > The is fundamentally no build-time test possible for this. Even if we
> > > > > > were willing to make flags for each bug (or missing feature) that was
> > > > > > ever fixed indicating the change, that would only tell you whether the
> > > > > > version present at build time had the property, not whether the
> > > > > > version present at runtime does. With a distro, unless the distro
> > > > > 
> > > > > If you can provide a libc-musl runtime __version variable, then
> > > > > Postfix can at run time determine that the library supports the
> > > > > necessary functionality, and enable/disable DANE accordingly.
> > > > 
> > > > We've been over this countless times from folks requesting version
> > > > numbers. A version number does not tell you what you want to know.
> > > > Distros will patch the functionality into whatever version they're
> > > > shipping. A 1.1.25 (if it ever happens) will likely have the patch
> > > > backported (just applied; no conflict). Querying features has to be
> > > > done on a per-feature basis not based on version numbers. See the
> > > > proposal on libc-coord.
> > > 
> > > Do let us know when libc-musl provides an indication whether a DNS
> > > lookup result is authentic (DNSSEC pass).
> >
> > It is now in master. I've also recommended the patch to Alpine.
> 
> A pointer to how one would use the updated code would be welcome,
> perhaps a pointer to the submit message.

https://git.musl-libc.org/cgit/musl/commit/?id=fd7ec068efd590c0393a612599a4fab9bb0a8633

> I won't comment on distro maintainers who willingly break Postfix's
> security guarantees of DANE, without informing the user.

I'm not encouraging any to do that; rather I've encouraged them to
take measures to both:

(1) ensure that DANE is not silently ignored, by either patching
Postfix to work with old musl (prior to the above commit) or patching
the musl package and adding a dependency from the postfix package on
the updated musl package, and:

(2) not ship Postfix packages with DNSSEC/DANE disabled, because that
would encourage admins to switch DANE off in their config files to
"fix the breakage" after upgrading, then forget to turn it back on
once updated packages are available to make it work.

I haven't been through this with other distros yet, but Alpine folks
were committed to both of these principles.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
  2020-05-19 14:23                                             ` Wietse Venema
@ 2020-05-19 14:28                                               ` Rich Felker
  0 siblings, 0 replies; 8+ messages in thread
From: Rich Felker @ 2020-05-19 14:28 UTC (permalink / raw)
  To: Wietse Venema; +Cc: postfix-users, musl

On Tue, May 19, 2020 at 10:23:18AM -0400, Wietse Venema wrote:
> Rich Felker:
> > The is fundamentally no build-time test possible for this. Even if we
> > were willing to make flags for each bug (or missing feature) that was
> > ever fixed indicating the change, that would only tell you whether the
> > version present at build time had the property, not whether the
> > version present at runtime does. With a distro, unless the distro
> 
> If you can provide a libc-musl runtime __version variable, then
> Postfix can at run time determine that the library supports the
> necessary functionality, and enable/disable DANE accordingly.

We've been over this countless times from folks requesting version
numbers. A version number does not tell you what you want to know.
Distros will patch the functionality into whatever version they're
shipping. A 1.1.25 (if it ever happens) will likely have the patch
backported (just applied; no conflict). Querying features has to be
done on a per-feature basis not based on version numbers. See the
proposal on libc-coord.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
  2020-05-19 14:00                                           ` Rich Felker
@ 2020-05-19 14:23                                             ` Wietse Venema
  2020-05-19 14:28                                               ` Rich Felker
  0 siblings, 1 reply; 8+ messages in thread
From: Wietse Venema @ 2020-05-19 14:23 UTC (permalink / raw)
  To: Rich Felker; +Cc: postfix-users, musl

Rich Felker:
> The is fundamentally no build-time test possible for this. Even if we
> were willing to make flags for each bug (or missing feature) that was
> ever fixed indicating the change, that would only tell you whether the
> version present at build time had the property, not whether the
> version present at runtime does. With a distro, unless the distro

If you can provide a libc-musl runtime __version variable, then
Postfix can at run time determine that the library supports the
necessary functionality, and enable/disable DANE accordingly.

	Wietse

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
       [not found]                                         ` <20200519090610.GO68966@straasha.imrryr.org>
@ 2020-05-19 14:00                                           ` Rich Felker
  2020-05-19 14:23                                             ` Wietse Venema
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-05-19 14:00 UTC (permalink / raw)
  To: postfix-users; +Cc: musl

On Tue, May 19, 2020 at 05:06:10AM -0400, Viktor Dukhovni wrote:
> On Tue, May 19, 2020 at 01:44:30AM -0400, Rich Felker wrote:
> 
> > > This sounds reasonable.  Will there be a way for Postfix to detect the
> > > new library version, so that we don't disable DANE for musl-libc
> > > versions that do set the AD bit?
> > 
> > I'm really disappointed with the detection, which made things much
> > worse by producing postfix builds that won't do DANE even after
> > libc.so is upgraded. It should have just worked after upgrade.
> 
> We have no choice, we can't ship code that silently fails to honour its
> configuration.  I'm not worried about DANE "working", I'm worried about
> DANE *not* working, and the user being none-the-wiser.
> 
> When remote TLSA RRs are published, and DANE is enabled in Postfix, the
> mail must be delivered securely, or the delivery attempt MUST fail.
> 
> > The test is also somewhat broken in that it gets the wrong result if
> > /bin/sh is static-linked, or if you have postfix built against musl on
> > a system where /bin/sh is glibc-based, etc. and I don't even know what
> > happens if you're cross-compiling or if that's even supported at all.
> 
> A better test would be appreciated.  Glibc has GLIBC_PREREQ macros,
> we haven't found anything similar for MUSL.

The is fundamentally no build-time test possible for this. Even if we
were willing to make flags for each bug (or missing feature) that was
ever fixed indicating the change, that would only tell you whether the
version present at build time had the property, not whether the
version present at runtime does. With a distro, unless the distro
manually makes their package file depend on a particular version of
the distro libc package (which they can do very well, since they know
what patches they applied), it's possible for a user to upgrade
postfix but not libc. And for a user building everything from source
manually, that work's on them.

> > There's not really a "test for versions that do set" by version; I
> > would expect once the patch is upstream and tested, distros like
> > Alpine would just apply it to their existing musl package rather than
> > waiting to upgrade to get it. The only real test is a runtime one,
> > calling res_mkquery and observing that it's set.
> 
> Sorry, no such test is possible.  There is no reliable canary domain to
> query, and DANE should in any case also work in domains disconnected
> from the Internet, with locally configured trust-anchors.

Canary domain is not needed for a runtime test. All that's needed is a
call to res_mkquery with a dummy domain and inspection of buf[3]. (Of
course you can also just set the bit at query time in exactly the same
manner, but that only works for replacing res_query not res_search. I
don't understand why you're using res_search at all in mail software
though.)

> > BTW I saw in git master you added an additional musl test of the same
> > form for the res_n* APIs. A simpler way to detect them is just with
> > __RES macro in resolv.h, which indicates the supported API version.
> > AIUI it's provided by all known implementations, though I haven't
> > actually checked that.
> 
> Robust detection of MUSL features at build time would be much
> appreciated.  Precludes any tests that depend on live DNS queries.
> The tests need to *statically* test the features of the platform's
> C library.

This is an area of open cross-implementation effort to provide
something meaningful. See the thread here:
https://www.openwall.com/lists/libc-coord/2020/04/22/1

Note that the "Possibly this should include the semantics for
definition with a value of 0 ("supported for compilation and might or
might not be supported at runtime")..." text applies here since a
static build-time test does not suffice here.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
       [not found]                                     ` <20200519023814.GN68966@straasha.imrryr.org>
@ 2020-05-19  5:44                                       ` Rich Felker
       [not found]                                         ` <20200519090610.GO68966@straasha.imrryr.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-05-19  5:44 UTC (permalink / raw)
  To: postfix-users; +Cc: musl

On Mon, May 18, 2020 at 10:38:14PM -0400, Viktor Dukhovni wrote:
> On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote:
> 
> > > Mostly dig, unbound-host, ... Most of the platform C libraries support
> > > DO=1, which obviates the need for AD=1, so they don't do that, but it is
> > > nevertheless safe.  AD=1 is much cheaper than DO=1, because you get back
> > > just the AD bit without the excess RRSIG baggage, which is not needed
> > > when you're not doing your own validation.
> > 
> > I have a proposed solution expected to go upstream in this release
> > cycle: res_* set AD bit unconditionally in outgoing queries, but the
> > [backend for the] netdb.h functions clears it after calling
> > __res_mkquery.
> > 
> > This ensures that even if there are some broken nameservers/networks
> > still that can't handle AD in queries, the standard, widely-used,
> > high-level lookup APIs will still work, and at worst res_query breaks.
> > 
> > Note that the netdb.h functions have no use for the AD bit and no way
> > to pass it back to the caller, so there is no reduction in
> > functionality by having them clear it.
> 
> This sounds reasonable.  Will there be a way for Postfix to detect the
> new library version, so that we don't disable DANE for musl-libc
> versions that do set the AD bit?

I'm really disappointed with the detection, which made things much
worse by producing postfix builds that won't do DANE even after
libc.so is upgraded. It should have just worked after upgrade. The
test is also somewhat broken in that it gets the wrong result if
/bin/sh is static-linked, or if you have postfix built against musl on
a system where /bin/sh is glibc-based, etc. and I don't even know what
happens if you're cross-compiling or if that's even supported at all.

There's not really a "test for versions that do set" by version; I
would expect once the patch is upstream and tested, distros like
Alpine would just apply it to their existing musl package rather than
waiting to upgrade to get it. The only real test is a runtime one,
calling res_mkquery and observing that it's set.

BTW I saw in git master you added an additional musl test of the same
form for the res_n* APIs. A simpler way to detect them is just with
__RES macro in resolv.h, which indicates the supported API version.
AIUI it's provided by all known implementations, though I haven't
actually checked that.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
       [not found]                                 ` <20200414215951.GJ41308@straasha.imrryr.org>
@ 2020-05-19  1:37                                   ` Rich Felker
       [not found]                                     ` <20200519023814.GN68966@straasha.imrryr.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-05-19  1:37 UTC (permalink / raw)
  To: postfix-users; +Cc: musl

On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote:
> > > That RFC was published in 2013.  That's long enough ago.
> > 
> > We support environments that haven't been touched since 2009 or so,
> > and to a lesser/minimal-support extent ones that haven't been touched
> > since around 2004. Your idea of environments Postfix might be running
> > on musl in is very different from the concept of environments that
> > arbitrary applications binaries linked to musl might be running in.
> 
> Nevertheless, the AD bit is on by default in dig and similar tools, with
> no reports of any issues in a long time.  Do you see dig fail where MUSL
> libc lookups succeed?  I'm asking around the DNS community for any
> evidence of barriers to AD=1, so far nobody knows of any.  I'll try to
> find more compelling evidence, but basically tolerating AD=1 (either
> ignoring or acting on it per the 2013 RFC) is *required* resolver
> behaviour.
> 
> > So if there's any chance of this breaking there almost certainly needs
> > to be a way to turn it off that works even on static binaries.
> 
> Whether and where to place such controls is your call.  If novel
> /etc/resolv.conf options are not a problem for statically linked
> binaries using something other than musl-libc, then you could
> have:
> 
>     options noad ...
> 
> but if that is incompatible with other stub resolver libraries on the
> same machine, you may need a private musl-specific configuration file.
> 
> My money is on this being unnecessary.  I'll let know what I find
> from dns-operations, and if possible perhaps a RIPE ATLAS probe,
> assuming they support enabling AD=1.
> 
> > > In that case, set the AD bit unconditionally, or provide a documented
> > > mechanism to do so via a suitable configuration file.
> > 
> > Putting it in resolv.conf on an options line is probably the best. The
> > main remaining question is just which default to use, and where to
> > apply it (at res_mkquery or at res_send).
> 
> Your call.
> 
> > > Find me a resolver that fails when the AD bit is set.  Stub resolvers
> > > that always set it have been around for some time now.
> >
> > Do you know if the usual Windows, Android, iOS, etc. ones always set
> > it? If so it's almost surely safe to do so and this might not even
> > need to be an option (which would really be my favorite coarse of
> > action -- making it unconditional so there's no new configuration to
> > invent).
> 
> Mostly dig, unbound-host, ... Most of the platform C libraries support
> DO=1, which obviates the need for AD=1, so they don't do that, but it is
> nevertheless safe.  AD=1 is much cheaper than DO=1, because you get back
> just the AD bit without the excess RRSIG baggage, which is not needed
> when you're not doing your own validation.

I have a proposed solution expected to go upstream in this release
cycle: res_* set AD bit unconditionally in outgoing queries, but the
[backend for the] netdb.h functions clears it after calling
__res_mkquery.

This ensures that even if there are some broken nameservers/networks
still that can't handle AD in queries, the standard, widely-used,
high-level lookup APIs will still work, and at worst res_query breaks.

Note that the netdb.h functions have no use for the AD bit and no way
to pass it back to the caller, so there is no reduction in
functionality by having them clear it.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
       [not found]                                     ` <878siucvqd.fsf@mid.deneb.enyo.de>
@ 2020-04-17 16:07                                       ` Rich Felker
  0 siblings, 0 replies; 8+ messages in thread
From: Rich Felker @ 2020-04-17 16:07 UTC (permalink / raw)
  To: Florian Weimer; +Cc: musl

On Fri, Apr 17, 2020 at 11:22:34AM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> > On Wed, Apr 15, 2020 at 08:27:08PM +0200, Florian Weimer wrote:
> >> >> I don't understand your PTR example.  It seems such a fringe case that
> >> >> people produce larger PTR responses because they add all virtual hosts
> >> >> to the reverse DNS zone.  Sure, it happens, but not often.
> >> >
> >> > I think it's probably more a matter of the concurrent lookups from
> >> > multiple nameservers (e.g. local, ISP, and G/CF, where local has
> >> > fastest round-trip but not much in cache, G/CF has nearly everything
> >> > in cache but slowest round trip, and ISP is middle on both) than lack
> >> > of tcp fallback that makes netstat etc. so much faster.
> >> 
> >> The question is: Why would you get a TC bit response?  Is the musl
> >> resolver code triggering some anti-spoofing measure that tries to
> >> validate source addresses over TCP?  (I forgot about this aspect of
> >> DNS.  Ugh.)
> >
> > TC bit is for truncation, and means that the complete response would
> > have been larger than 512 bytes and was truncated to whatever number
> > of whole RRs fit in 512 bytes.
> 
> You mentioned that TC processing added observable latency to the
> netstat tool.  netstat performs PTR queries.  Non-DNSSEC responses to
> PTR queries are rarely larger than 512 bytes.  (The only exception I
> have seen occur when people list all their HTTP virtual hosts in PTR
> records, but again, that's very rare.)  Typically, they are less than
> 150 bytes.  Non-minimal responses can be larger, but the additional
> data is removed without setting the TC bit.
> 
> This is why something very odd must have happened during your test.
> One explanation would be a middlebox that injects TC queries to
> validate source addresses.

I think this was just a misunderstanding. What I said was that things
like netstat run a lot faster in practice with musl than with other
resolvers in a range of typical setups, and the two potential factors
are concurrent requests to multiple nameservers and non-fallback to
TCP, and that I didn't have evidence for which it was. It sounds like
you have a good hypothesis that TCP is not the cause here.

> >> > However it's not clear how "fallback to tcp" logic should interact
> >> > with such concurrent requests -- switch to tcp for everything and
> >> > just one nameserver as soon as we get any TC response?
> >> 
> >> It's TCP for this query only, not all subsequent queries.  It makes
> >> sense to query the name server that provided the TC response: It
> >> reduces latency because that server is more likely to have the large
> >> response in its cache.
> >
> > I'm not talking about future queries but other unfinished queries that
> > are part of the same operation (presently just concurrent A and AAAA
> > lookups).
> 
> If the second response has TC set (but not the first), you can keep
> the first response.  Re-querying both over TCP increases the
> likelihood that you get a response from the same cluster node (so more
> consistency), but you won't get that over UDP, ever, so I don't think
> it matters.
> 
> If the first response has TC set, you have an open TCP connection you
> could use for the second query as well.  Pipelining of DNS requests
> has compatibility issues because there is no application-layer
> connection teardown (an equivalent to HTTP's Connection: close).  If
> the server closes the connection after sending the response to the
> first query, without reading the second, this is a TCP data loss
> event, which results in an RST segment and potentially, loss of the
> response to the first query.  Ideally, a client would wait for the
> second UDP response and the TCP response to arrive.  If the second UDP
> response is TC as well, the TCP query should be delayed until the
> first TCP response came back.
> 
> (We should move this discussion someplace else.)

Yes. I just took postfix-users off the CC and added musl. Discussing
it further on postfix-users does not seem constructive as the
arguments are mostly ideological (about what the roles of different
components "should be") vs practical (can we reasonably improve
behavior here?).

Indeed it sounds like one TCP connection would be needed per request,
so switchover would just be per-request if done.

My leaning is probably not to do fallback at all (complex logic,
potential for unexpected slowness, not needed by vast majority of
users) and just add TCP support with option use-vc for users who
really want complete replies. All of this would be contingent anyway
on making internal mechanisms able to handle variable result size
rather than fixed-size 512 bytes so it's not happening right away.
Doing it carelessly would create possibly dangerous bugs.

I'm still also somewhat of the opinion that users who want a resolver
library (res_* API) with lots of features should just link BIND's, but
it would be nice not to have to do that.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [musl] Re: Outgoing DANE not working
       [not found]                 ` <CECAFB36-DA1B-4EFB-ACD1-294E3B121B2E@dukhovni.org>
@ 2020-04-13 18:35                   ` Rich Felker
       [not found]                     ` <20200413190412.GF41308@straasha.imrryr.org>
  0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2020-04-13 18:35 UTC (permalink / raw)
  To: Postfix users; +Cc: musl

On Mon, Apr 13, 2020 at 02:15:14PM -0400, Viktor Dukhovni wrote:
> > On Apr 13, 2020, at 7:18 AM, Christian <list-christian@web.de> wrote:
> > 
> > FYI: I put your findings forward to the musl-libc mailing list and
> > asked what they now think what should be done.
> 
> The problem can be partly resolved by setting the "AD" bit in the
> outgoing DNS query header sent by the musl-libc stub resolver.  Then
> the local iterative resolver will return the AD bit in its response.
> 
> However, lack of support for retrying truncated responses over TCP
> or support for disabling RES_DEFNAMES and RES_DNSRCH remain as issues.

This has also been discussed some on the musl list already
(https://www.openwall.com/lists/musl/2020/04/13/1) but I'm replying
into this thread as well because I'd like to come to some mutually
acceptable solution.

musl's stub resolver intentionally speaks only rfc1035 udp, and the
intent has always been that DNSSEC validation and policy be the
responsibility of the nameserver running on localhost, not the stub
resolver or the calling application. The resolver is intentionally
stateless. It was probably a mistake to provide the fake _res
definition, and I'm interested in resolving that mistake either by
removing it or adding res_n* API that honor (parts of) it at some
point, but determining the right action here and coordinating with
distros to ensure they have fixes in place for anything that breaks
will take a while.

RES_DEFNAMES and RES_DNSRCH are irrelevant as search is never
performed by the res_* interfaces, and domain/search keywords are used
only by the high-level ones (getaddrinfo/getnameinfo and the old
legacy gethostby*).

What is relevant, as far as I can tell, is that Postfix wants a way to
perform an EDNS0 query that lets it distinguish between a valid signed
result and a valid unsigned result. This is currently not possible,
but would be practical to add based on "options edns0" in resolv.conf.
I'm not sure if or how soon that will happen, but determining that is
something I'd like to have come out of this discussion.

From my perspective, what would work best with what's always been the
intended DNSSEC usage model of musl would be if Postfix supported use
of DANE with smtp_dns_support_level=enabled, i.e. outsourcing all
DNSSEC functionality to the nameserver.

Rich

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, back to index

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20200519154542.GC1079@brightrain.aerifal.cx>
     [not found] ` <49RN803wcfzJrNv@spike.porcupine.org>
2020-05-19 20:08   ` [musl] Re: Outgoing DANE not working Rich Felker
     [not found] <fce05ab0ed102dec10e4163dd4ce5d8095d2ffd7.camel@web.de>
     [not found] ` <20200412211807.GC41308@straasha.imrryr.org>
     [not found]   ` <d64b1b8801cc5350e9d27dd109dd2446e7d4b860.camel@web.de>
     [not found]     ` <20200413024746.GD41308@straasha.imrryr.org>
     [not found]       ` <b38668e94b2781003a14c6dca3d41edf33e347e2.camel@web.de>
     [not found]         ` <A2FE67B5-A9A9-4A0F-A59D-78FF2AB992B7@dukhovni.org>
     [not found]           ` <f79a9f0c369607fc38bef06fec521eaf3ab23d8c.camel@web.de>
     [not found]             ` <6E8A9D4F-18CE-4ADA-A5B4-D14DB30C99E5@dukhovni.org>
     [not found]               ` <25e70f31f0c4629f7a7d3957649d08be06144067.camel@web.de>
     [not found]                 ` <CECAFB36-DA1B-4EFB-ACD1-294E3B121B2E@dukhovni.org>
2020-04-13 18:35                   ` Rich Felker
     [not found]                     ` <20200413190412.GF41308@straasha.imrryr.org>
     [not found]                       ` <20200413193505.GY11469@brightrain.aerifal.cx>
     [not found]                         ` <20200413214138.GG41308@straasha.imrryr.org>
     [not found]                           ` <20200414035303.GZ11469@brightrain.aerifal.cx>
     [not found]                             ` <87v9m0hdjk.fsf@mid.deneb.enyo.de>
     [not found]                               ` <20200415180149.GH11469@brightrain.aerifal.cx>
     [not found]                                 ` <87imi0haf7.fsf@mid.deneb.enyo.de>
     [not found]                                   ` <20200417034059.GF11469@brightrain.aerifal.cx>
     [not found]                                     ` <878siucvqd.fsf@mid.deneb.enyo.de>
2020-04-17 16:07                                       ` Rich Felker
     [not found]                             ` <20200414061620.GI41308@straasha.imrryr.org>
     [not found]                               ` <20200414160641.GC11469@brightrain.aerifal.cx>
     [not found]                                 ` <20200414215951.GJ41308@straasha.imrryr.org>
2020-05-19  1:37                                   ` Rich Felker
     [not found]                                     ` <20200519023814.GN68966@straasha.imrryr.org>
2020-05-19  5:44                                       ` Rich Felker
     [not found]                                         ` <20200519090610.GO68966@straasha.imrryr.org>
2020-05-19 14:00                                           ` Rich Felker
2020-05-19 14:23                                             ` Wietse Venema
2020-05-19 14:28                                               ` Rich Felker

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git