Hi Panu,
On Wed, Jun 05, 2024 at 09:26:14AM +0300, Panu Matilainen wrote:
> On 6/4/24 21:43, Frank Ch. Eigler wrote:
> >dvlasenk wrote:
> >
> >>[...] Do you understand how many fetches of debuginfo will be
> >>attempted by e.g. a kernel build tooling when it runs readelf on 8000
> >>freshly built
On 6/4/24 21:43, Frank Ch. Eigler wrote:
Hi, Denys -
dvlasenk wrote:
[...]
Now readelf, annobin and hell knows what else started to talk to
REMOTE SERVERS, deep out of internals of complicated build infrastructure
running on presumably secure build machines of various IT corporations
and wha
Hi, Denys -
dvlasenk wrote:
> [...]
> Now readelf, annobin and hell knows what else started to talk to
> REMOTE SERVERS, deep out of internals of complicated build infrastructure
> running on presumably secure build machines of various IT corporations
> and whatnot!
(It may not be appropriate
On 4/7/21 22:32, 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 debugging data and source code,
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 w
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 worthwhile
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 s
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 time
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 client-side
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 each
* 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 cod
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 discusses
"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 t
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, and
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 w
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:
https://docs.fedoraproject.org/en-US
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" giv
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 hashes
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 -- devel@lists.fedorap
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 $DEBUGINFOD_TIM
"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 th
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 sepa
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 protection
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 /lib64/libbrotlicommon.so.1
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:
https://sour
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 concept:
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:
https:
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 --share=ne
> 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 have
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 ~]$
DEBUGINFOD_UR
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 links
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 and
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 they
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 f
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 making
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 being
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 debugg
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 dnf`
44 matches
Mail list logo
