On Sat, Oct 10, 2015 at 10:59 AM, Timothy Gu <timothyg...@gmail.com> wrote: > On Sat, Oct 10, 2015 at 7:20 AM Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > >> On Thu, Oct 8, 2015 at 8:37 AM, Michael Niedermayer >> <mich...@niedermayer.cc> wrote: >> > Hi >> > >> > ill make 2.8.1 soon from release/2.8 >> > if you want something backported push it to release/2.8 soon! >> > (or ask me to pull from your git tree, or if its trivial without >> > conflicts then the commit hash to cherry pick is fine too) >> >> Can someone direct me to a doc on what should and should not be >> backported? > > > https://www.ffmpeg.org/developer.html#Criteria-for-Point-Releases-1
Thanks for the link. Note that what constitutes a security issue has different meanings for different people. More concretely, consider some of the patches I sent recently regarding integer overflows. A few I am almost sure can't really be exploited. Others I can't tell since I am not a security expert. Nevertheless, to feel safe, I would personally always backport them. Similar thing goes for static analyzers, e.g Coverity. > > In my simplistic view, although e.g not all undefined behaviors are >> exploitable, I still consider such things worthy of a backport as they >> don't introduce any new features, and fix bugs. Similarly, I consider >> all clean, simple bug fixes worthy of a backport. >> > > I would agree with this view. > > Timothy > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
