Hi -
On Tue, Nov 19, 2019 at 09:15:20PM +0100, Mark Wielaard wrote:
> > That's what the doc says. What the code does, as far back as the year
> > 2001, is have a static flag/counter in curl_global_init() that
> > prevents multiple initialization.
>
> But the warning isn't about multiple initiali
Hi -
> [...] What I want is simply make it easy for the user to say where
> they expect the sources are. So there is no surprises.
If this were a mandate, it would be a hassle, for any build that's
more than one directory wide.
> > The -F mode is suitable for sharing build trees. By definitio
Hi Frank,
On Tue, Nov 19, 2019 at 11:20:34AM -0500, Frank Ch. Eigler wrote:
> > > Doing a redundant initialization later is not a problem; there is a
> > > counter in there. The problematic case would be
> > > - a multithreaded application
> > > - loading debuginfod.so multiply concurrently someh
Hi Frank,
On Tue, Nov 19, 2019 at 11:13:48AM -0500, Frank Ch. Eigler wrote:
> > > > This does keep me slightly worried. Even "trustworthy binaries" could
> > > > be produced by buggy compilers.
> > >
> > > Those would be untrustworthy binaries.
> > But then every binary could be untrustworthy :)
https://sourceware.org/bugzilla/show_bug.cgi?id=22288
--- Comment #4 from Josh Stone ---
Here's my rustc PR to enable aranges by default:
https://github.com/rust-lang/rust/pull/66532
--
You are receiving this mail because:
You are on the CC list for the bug.
Hi -
> > Doing a redundant initialization later is not a problem; there is a
> > counter in there. The problematic case would be
> > - a multithreaded application
> > - loading debuginfod.so multiply concurrently somehow
> > - and calling the solib ctor concurrently somehow
> > - and all of this
Hi,
On Mon, 2019-11-18 at 11:47 -0500, Frank Ch. Eigler wrote:
> > > > > +control. The \fI/metrics\fP webapi endpoint is probably not
> > > > > +appropriate for disclosure to the public.
> > > >
> > > > So, should there be an option to turn it off?
> > >
> > > IMHO not necessary. The security
Hi -
> > > This does keep me slightly worried. Even "trustworthy binaries" could
> > > be produced by buggy compilers.
> >
> > Those would be untrustworthy binaries.
> But then every binary could be untrustworthy :)
If we have legitimate concerns about the correctness of toolchains
that the bui
Hi,
On Mon, 2019-11-18 at 15:33 -0500, Frank Ch. Eigler wrote:
> > > > Do you know how other libraries that use libcurl deal with this?
> > >
> > > I looked over some other libcurl users in fedora. Some don't worry
> > > about the issue at all, relying on implicit initialization, which is
> > >
Hi,
On Mon, 2019-11-18 at 13:41 -0500, Frank Ch. Eigler wrote:
> > > I see where you're going with it, it's a reasonable concern. For now,
> > > we can consider it covered by the "debuginfod should be given
> > > trustworthy binaries" general rule.
> >
> > This does keep me slightly worried. Eve
Hi,
On Sun, 2019-11-17 at 21:50 -0500, Frank Ch. Eigler wrote:
> > Attached is a variant that adds debuginfod_begin and debuginfo_end
> > (names matching elf/dwarf_begin/end) and adds a debuginfod_client
> > handle to each other function.
>
> Sure, if you like.
OK, I rebased on the debuginfod-su
11 matches
Mail list logo
