On Thu, 2020-01-02 at 11:44 -0500, Frank Ch. Eigler wrote:
> Hi -
>
> > > That suggests one timeout could be sufficient - the progress
> > > timeout
> > > you the one you found - just not too short and not too fast.
> >
> > How about the attached (untested) patch?
I finally tested it in various
Hi -
> > That suggests one timeout could be sufficient - the progress timeout
> > you the one you found - just not too short and not too fast.
>
> How about the attached (untested) patch?
That looks good, though I'd bump up the 60s -> 120s to give it a big
margin over already-observed latencies.
Hi Frank,
On Sun, Dec 22, 2019 at 08:38:59PM -0500, Frank Ch. Eigler wrote:
> Yeah, a connection timeout per se is probably not really worth having.
> A URL having unreasolvable hosts will fail immediately. A reachable
> http server that is fairly busy will connect, just take time. The
> only co
Hi -
> There is of course some i/o delay involved. But the majority of the
> time is cpu bound because the file needs to be decompressed.
> Not that it would help us now, but I wonder if it would be worth it to
> look at parallel compression/decompression to speed things up.
Yeah, maybe.
> pick
Hi Frank,
On Wed, 2019-12-18 at 19:47 -0500, Frank Ch. Eigler wrote:
> [...]
> > I would add something like:
> >
> > /* Make sure there is at least some progress,
> > try to get at least 1K per progress timeout seconds. */
> > curl_easy_setopt(curl, CURLOPT_LOW_SPEED_TIME, 5 * 1024L);
>
Hi -
> The code looks good in general, do note that if you rebase/squash to
> onto master there is a slight conflict with the curl_res/curlm_res
> fixlet. Since GCC10 isn't out yet, just yell if this gives you trouble
> and I do/test it for you.
I'll figure it out and merge.
> [...]
> I would a
Hi -
> > That's not that serious a category of concern. Environment variables
> > are not under control of untrusted agents. FWIW, $DEBUGINFOD_CACHE is
> > considerably more dangerous in that regard (cache cleaning!).
>
> You have a way to make me even more scared of security issues than less
>
Hi Frank,
On Fri, 2019-12-13 at 11:57 -0500, Frank Ch. Eigler wrote:
> Pushed the following additional patch to fche/debuginfod-progress-env.
> Hand-tested on a ginormous download with various length timeouts; hard
> to test reliably within the elfutils testsuite (esp after removal of
> that induc
Hi Frank,
On Thu, 2019-12-12 at 12:18 -0500, Frank Ch. Eigler wrote:
> > I like this idea but have a bit of a security concern about the ability
> > to set it to any file. If someone manages to set it then they can
> > overwrite anything a process using the library can write to.
>
> That's not t
Hi -
Pushed the following additional patch to fche/debuginfod-progress-env.
Hand-tested on a ginormous download with various length timeouts; hard
to test reliably within the elfutils testsuite (esp after removal of
that induced debuginfod-side wait).
commit beb09f4aa0634e89cf3ed513c66abec6bc6500
Hi -
> > debuginfod: usability tweaks, incl. $DEBUGINFOD_PROGRESS client
> > support
> >
> > This facility allows a default progress-printing function
> > to be installed if the given environment variable is set.
>
> I like this idea but have a bit of a security concern about the
Hi Frank,
On Wed, 2019-12-04 at 16:10 -0500, Frank Ch. Eigler wrote:
> debuginfod: usability tweaks, incl. $DEBUGINFOD_PROGRESS client
> support
>
> This facility allows a default progress-printing function
> to be installed if the given environment variable is set.
I like this i
12 matches
Mail list logo
