Some ideas for process improvements/changes

[Frank Ch. Eigler]

Hi -


> > > - Get rid of ChangeLog files and trivial ChangeLog entries
> > >   [...]
> > 
> > Yes please!
> 
> So sad, on irc people are also enthousiastic about this. O well. :)

I hereby call for elfutils contributors to periodically send Mark some
gift ChangeLog messages (in private email) to cheer him up! :-)


> > Sounds like a sourceware infrastructure RFE.
> 
> Yes, but if I RFE that then it often just comes back to me to add it
> :) So I mention it here in the hope someone says "O, but that is easy,
> this is exactly how to do it..."

Yeah.  This sounds like someone(tm) ought to have done before, letting
patchwork monitor git traffic, and likely not a quick/small hack.


> > (No strong opinion on this one, except that a declaration that is this
> > informal would have little weight, should it ever be relied upon in
> > legal proceedings.)
> 
> Do you feel this weakens our Developer's Certificate of Origin
> process? 

(I'm not a lawyer, but ISTM the process is mostly perfunctory anyway.)

> My point is that we shouldn't judge what is a "real name" or
> not. But the name shouldn't misrepresent who someone is. 

Understood.  Operationally, we have no way of verifying anything
beyond an email address, if even that.


> > > - "Security" bug guidance
> > >   [...]
> > 
> > Yeah, a brief SECURITY file would be nice.
> 
> Any suggestions about what to put in such a section or file.  My main
> concern is that people are filing things we regard as simple bugs as
> "security" issues [...]


Yeah, that's a pain.  How about:

"""

The elfutils library and utilities aim to be generally robust and
reliable.  However, elfutils routinely processes complex binary
structured data.  This makes the code intricate and sometimes brittle.
While elfutils developers use a variety of static and dynamic checker
software (valgrind, sanitizers) in testing, bugs may remain.  Some of
these bugs may have security-related implications.


While many errors are cleanly detected at runtime, it is possible that
vulnerabilities exist that could be exploitable.  These may arise from
crafted / fuzzed / erroneous inputs, or perhaps even from valid inputs
with unforseen characteristics.  Therefore, to minimize risks, users
of elfutils tools and libraries should consider measures such as:

- avoiding running complex elfutils analysis on untrustworthy inputs
- avoiding running elfutils tools as privileged processes
- applying common platform level protection mechanisms such as
  selinux, syscall filtering, hardened compilation, etc.

Since most elfutils tools are run in short-lived, local, interactive,
development context rather than remotely "in production", we generally
treat malfunctions as ordinary bugs rather than security vulnerabilities.


Elfutils includes one network client/server: debuginfod.  The
debuginfod man page contains a SECURITY section outlining the general
risks.  tl;dr: many classes of server problems are delegated to
front-end proxies and curated elf/dwarf archives of the operator;
others to careful configuration of the debuginfod client.  These are
not generally reportable as security vulnerabilities.  However, we are
likely to accept security vulnerability reports related to:

- availability: e.g., remotely exploitable server crash, but not
  routine resource exhaustion or overload; client crash due to
  unexpected valid traffic from trusted server

- confidentiality: e.g., allowing the server to expose one client's
  traffic to another client

- integrity: e.g., causing the server to send erroneous
  elf/dwarf/source data across the webapi; causing the client to
  corrupt its cache to lose file integrity

We welcome reports that are tangential to any of these subjects.

Please report bugs via any of:
- email to <elfutils-devel@sourceware.org>
- https://sourceware.org/bugzilla/enter_bug.cgi?product=elfutils

After considering the above exclusions, please report suspected
security vulnerabilities confidentially via any of:

- email to <mark@klomp.org>
- email to <fche@elastic.org>
- email to <secalert@redhat.com>

"""


- FChE