PR25369 slice 3/3: debuginfod header relay

[Mark Wielaard]

Hi Frank,

On Fri, 2020-03-27 at 09:59 -0400, Frank Ch. Eigler wrote:
> I don't think it is a scare story to explicitly say: "Note that the
> > current implementation uses libcurl, but you shouldn't rely on that
> > fact. The only supported usage of this method is for adding an
> > optional header which might or might not be passed through to the
> > server."
> 
> OK, please feel free to add any such text that makes you feel more
> comfortable.

Done, as attached.

> > Sure. It is simple to write your own client code using libcurl if you
> > want to. And it might be too hard to sanity check the input. If it is,
> > too bad. But if it is easy to check then I think we should simply do
> > that to catch user mistakes.
> 
> We were talking about people who read the code to work around the
> documented pattern.  These would not be user mistakes.  We're
> proposing protecting someone not from their mistakes, but their
> deliberate reverse-engineering.

It is indeed too hard to know exactly which standard headers libcurl
adds. But we can at least sanity check the header string form is
correct. I added a simple check to the function to see it is at least
somewhat plausible, so that a user won't be surprised if a wrongly
formatted string accidentally removes a header instead of adding one.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-debuginfod-Document-and-sanity-check-debuginfod_add_.patch
Type: text/x-patch
Size: 3585 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/elfutils-devel/attachments/20200330/b4accc8e/attachment.bin>