Hi -
>> > [...] Most of these libraries are nothing I care about. [...] but
>> > could it be possible to not download anything at this point and only
>> > download debuginfos when they are really used [...]
>>
>> This sounds like a worthwhile suggestion for upstream gdb. We will
>> follow up
Frank Ch. Eigler wrote on Tue, May 25, 2021 at 02:57:54PM -0400:
> > [...] Most of these libraries are nothing I care about. [...] but
> > could it be possible to not download anything at this point and only
> > download debuginfos when they are really used [...]
>
> This sounds like a
Hi -
asmadeus wrote:
> - My usecase admitedly wasn't a very nice one (graphical application,
> info dll says I have 265 linked libraries...), but it felt very slow.
Yes, a first-time download series for such a program is going to take
time. (Afterwards, it's cached.)
> Looking at iftop the
Björn Persson wrote on Thu, Apr 22, 2021 at 04:26:22PM +0200:
> It is however a good illustration of how a network problem can destroy
> the user experience. Five minutes is a long wait. I'm glad that we now
> have this information.
This is an old post but I just used debuginfod for the first
f...@redhat.com (Frank Ch. Eigler) writes:
> The purpose of this Change is to configure this environment variable by
> default, pointing to the forthcoming production version of the server
> at https://debuginfod.fedoraproject.org/.
With elfutils-0.184-4.fc35, this is now active for rawhide. If
Frank Ch. Eigler wrote:
> Björn Persson writes:
> > And as you noted yourself, an attacker who can manipulate cached files
> > client-side has already taken over the user account anyway.
>
> Yes and no, and so I must disagree with your "won't improve ... for
> anyone". The proposed
Frank Ch. Eigler wrote:
> "Sampson Fung" writes:
>
> > The first run, giving my "Try"s, takes much longer than the second run,
> > which gives no "Trys".
> > Just from impression:
> > 1st run: From run to download finish, I will say it takes about 5+ minutes.
> > 2nd run: ~1 minute
> > For
* Frank Ch. Eigler:
> Unfortunately, in the absence of per-file signatures generated by the
> build system, and securely distributed out-of-band, I can't think of any
> way to provide client-side verifiability of a debuginfod type service.
> That's independent of any particular level of server
On Wed, Apr 21, 2021 at 4:09 PM Frank Ch. Eigler wrote:
> A direct way would be for someone to koji-download the given rpm, and
> hand-extract/compare the files. (It's obviously not economical.)
>
> > Thus, the debuginfod server becomes a juicy target.
>
> Yes. The Changes FAQ section
"Sampson Fung" writes:
> The first run, giving my "Try"s, takes much longer than the second run, which
> gives no "Trys".
> Just from impression:
> 1st run: From run to download finish, I will say it takes about 5+ minutes.
> 2nd run: ~1 minute
> For each "Try" given, the delay is not obvious
Zbigniew Jędrzejewski-Szmek writes:
> OTOH, the debuginfo files distributed through the debuginfod server
> are not signed and there is no direct way to verify that they match
> the (signed) contents of the debuginfo package.
A direct way would be for someone to koji-download the given rpm,
On Wed, Apr 21, 2021 at 03:15:23PM -0400, Frank Ch. Eigler wrote:
>
> Björn Persson writes:
>
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=27758
> >
> > The design you propose there won't improve anything for anyone. If the
> > hash is computed on the debuginfo server, then an attacker
IP addresses sent by gmail.
Thanks for the reminder for the new URL.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
I have run the same debug session using two different machines.
The first run, giving my "Try"s, takes much longer than the second run, which
gives no "Trys".
Just from impression:
1st run: From run to download finish, I will say it takes about 5+ minutes.
2nd run: ~1 minute
For each "Try"
Björn Persson writes:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=27758
>
> The design you propose there won't improve anything for anyone. If the
> hash is computed on the debuginfo server, then an attacker who can make
> the server serve malicious debuginfo can also make it serve
It is just a short delay then the "Try" suggestion is given.
My first run using my Notebook takes quite some time.
A few hours later, I run again using my Desktop, this time is very fast and no
"Try" given.
___
devel mailing list --
Björn Persson writes:
> I was wondering what the user experience would be like in such a
> situation. Could you estimate how long you had to wait in total? Was
> there a long delay before each "Timer expired" message, or only one
> delay?
Each outright-hung request could entail a
"FUNG Chi Chuen Sampson" writes:
> Downloading separate debug info for /lib64/liblzma.so.5...
> Download failed: Timer expired. Continuing without debug info for
> /lib64/libbrotlicommon.so.1.
> Missing separate debuginfo for /lib64/libbrotlicommon.so.1
> [...]
By the way, if you were using
sampsonfung wrote:
> While trying to collect a backtrace for org.gnome.Tetravex, I got this in gdb:
> [...]
> Download failed: Timer expired. Continuing without debug info for
> /lib64/libzstd.so.1.
> Missing separate debuginfo for /lib64/libzstd.so.1
> Try: dnf --enablerepo='*debug*' install
On Wed, Apr 21, 2021 at 11:26:10AM +0200, Björn Persson wrote:
> Frank Ch. Eigler wrote:
> > Björn Persson writes:
> >
> > > · How is it verified that files received from debuginfo servers have not
> > > been tampered with?
> >
> > Following up further to this, we're planning to add optional
FUNG Chi Chuen Sampson wrote:
> While trying to collect a backtrace for org.gnome.Tetravex, I got this in gdb:
>
> ===
>
> Downloading separate debug info for /lib64/liblzma.so.5...
> Download failed: Timer expired. Continuing without debug info for
> /lib64/libbrotlicommon.so.1.
> Missing
Frank Ch. Eigler wrote:
> Björn Persson writes:
>
> > · How is it verified that files received from debuginfo servers have not
> > been tampered with?
>
> Following up further to this, we're planning to add optional client-side
> hash-verification of cached content, to provide some
While trying to collect a backtrace for org.gnome.Tetravex, I got this in gdb:
===
Downloading separate debug info for /lib64/liblzma.so.5...
Download failed: Timer expired. Continuing without debug info for
/lib64/libbrotlicommon.so.1.
Missing separate debuginfo for
Hi -
Björn Persson writes:
> · How is it verified that files received from debuginfo servers have not
> been tampered with?
Following up further to this, we're planning to add optional client-side
hash-verification of cached content, to provide some protection against
tampering:
On Sun, Apr 11, 2021 at 1:52 PM Owen Taylor wrote:
>
>
> On Sat, Apr 10, 2021 at 9:55 AM Michael Catanzaro
> wrote:
>
>> On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor
>> wrote:
>> > Did you notice that it also works for the Fedora Flatpaks (thanks,
>> > Frank!) - basic proof of
Bjorn wrote:
>> https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
>
> The change page lacks a discussion of security implications. An informed
> decision requires answers to questions such as: [...]
Thank you for your questions. Added a section and placed initial
answers there:
On Sat, Apr 10, 2021 at 9:55 AM Michael Catanzaro
wrote:
> On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor
> wrote:
> > Did you notice that it also works for the Fedora Flatpaks (thanks,
> > Frank!) - basic proof of concept:
> >
> > $ flatpak run --command=sh --filesystem=home
> https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
The change page lacks a discussion of security implications. An informed
decision requires answers to questions such as:
· What kinds of attacks might be possible with malicious debuginfo files?
(For example debugging tools might
On Sat, Apr 10 2021 at 08:03:09 AM -0400, Owen Taylor
wrote:
Did you notice that it also works for the Fedora Flatpaks (thanks,
Frank!) - basic proof of concept:
$ flatpak run --command=sh --filesystem=home --share=network --devel
org.gnome.Aisleriot
[ org.gnome.Aisleriot ~]$
On Fri, Apr 9, 2021 at 11:01 AM Michael Catanzaro wrote:
>
> On Fri, Apr 9 2021 at 04:19:31 PM +0200, Lars Seipel
> wrote:
> > Really cool. Thanks for making it happen.
>
> I started testing the staging server yesterday. It seems a little slow
> -- I worry for anyone debugging anything that
On Fri, Apr 9 2021 at 04:20:16 PM -0400, David Malcolm
wrote:
Back in Fedora 13 with:
https://fedoraproject.org/wiki/Features/EasierPythonDebugging
I added python scripts to python-debuginfo and python3-debuginfo so
that if you install them, gdb becomes gains type-specific pretty-
printers
dmalcolm wrote:
> [...]
> Something that occurred to me about this change is that as well as
> sources and DWARF data, some of our debuginfo files contain python
> scripts.
Because these files are stand-alone .py files rather than elf/dwarf
files, debuginfod has no way of serving those. If
On Thu, 2021-04-08 at 11:19 -0400, Frank Ch. Eigler wrote:
>
> ngompa13 wrote:
>
> > Woohoo! I'm excited for this!
>
> Thanks!
>
> > I got a chance to use debuginfod to do some debugging of DNF on
> > openSUSE last Saturday and the experience was fantastic.
> >
> > I'm looking forward to this
mcatanzaro wrote:
> I started testing the staging server yesterday. It seems a little slow
> -- I worry for anyone debugging anything that links to WebKit, which
> on the desktop is a lot -- but otherwise it works *very* well. I'm
> impressed. Very nice.
It'd be good to get a sense of what you
On Fri, Apr 9 2021 at 04:19:31 PM +0200, Lars Seipel
wrote:
Really cool. Thanks for making it happen.
I started testing the staging server yesterday. It seems a little slow
-- I worry for anyone debugging anything that links to WebKit, which on
the desktop is a lot -- but otherwise it works
On Thu, Apr 08, 2021 at 11:19:59AM -0400, Frank Ch. Eigler wrote:
Hey, it already is there in most tools, try it.
% export DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/
and shortly all F32+ packages/versions/architectures will be debuggable
that way.
Really cool. Thanks for
On Thu, Apr 8, 2021 at 11:20 AM Frank Ch. Eigler wrote:
>
>
> ngompa13 wrote:
>
> > Woohoo! I'm excited for this!
>
> Thanks!
>
> > I got a chance to use debuginfod to do some debugging of DNF on
> > openSUSE last Saturday and the experience was fantastic.
> >
> > I'm looking forward to this
ngompa13 wrote:
> Woohoo! I'm excited for this!
Thanks!
> I got a chance to use debuginfod to do some debugging of DNF on
> openSUSE last Saturday and the experience was fantastic.
>
> I'm looking forward to this being wired up into GDB, ABRT, and
> everything else
Hey, it already is there in
On Wed, Apr 7, 2021 at 4:33 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
>
> == Summary ==
> Fedora users / developers who need to debug/trace distro binaries can
> make use of the recently activated elfutils-debuginfod servers to
> automatically fetch
https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
== Summary ==
Fedora users / developers who need to debug/trace distro binaries can
make use of the recently activated elfutils-debuginfod servers to
automatically fetch debugging data and source code, instead of having
to use `# sudo
https://fedoraproject.org/wiki/Changes/DebuginfodByDefault
== Summary ==
Fedora users / developers who need to debug/trace distro binaries can
make use of the recently activated elfutils-debuginfod servers to
automatically fetch debugging data and source code, instead of having
to use `# sudo
41 matches
Mail list logo
