Re: Why back-porting patches to stable instead of releasing a new package.
On Sat, Aug 16, 2003 at 12:45:20PM -0400, Andrew Pimlott wrote:
> On Sat, Aug 16, 2003 at 11:05:02AM -0400, Matt Zimmerman wrote:
> > One bug was fixed accidentally in a code reorganization. The old code was
> > simply replaced with something else which happened not to have the bug. The
> > other was fixed because it was a bug, but the security impact was not
> > realized until later. This happens sometimes.
>
> I estimate that this happens often.
Based on what? Certainly, any code which is removed may have bugs, and code
is removed all the time in favour of new code. New code also introduces
bugs. New code is not a security feature, in fact quite the opposite.
> > I still don't understand what you are suggesting. Get rid of stable, so
> > that everyone must use the very latest maintainer upload of every
> > package? Push every maintainer upload which includes a new upstream
> > release into stable?
>
> Make it easier to get bug-fixes into stable in a timely fashion. If you
> have a system where bug-fixes have a "smooth" route into stable, the
> security bugs get fixed along with them.
If you want the point release process to be faster, then I suggest that you
volunteer to help review uploads to proposed-updates. If you are suggesting
that the "smooth" process is one which does not involve review, then I
absolutely disagree.
> If you have a "security-fixes-only" policy[...]
We don't.
> My main point is that the current system overlooks a large class of
> security holes, and that these holes are relatively easy for the bad guys
> to find by browsing changelogs. To improve this, one approach is to tell
> everyone, "look harder for security fixes". I believe this approach is
> not effective, and that a better approach is a policy of fixing bugs in
> stable, even if they are not known to be exploitable.
Fixing bugs in stable is one thing, and this is encouraged. It is quite
another thing to push new software into stable in the hope that it fixes
bugs that you do not even know exist. If you think that, in general, having
newer software in stable results in fewer security bugs, then the answer is
to release more often. Of course, I think that newer software often has the
opposite effect.
> I admit, I don't know for sure how well this works because I haven't
> seen it in action.
Subscribe to bugtraq, full-disclosure, debian-security-announce, etc. for a
front-row seat.
> Who is everyone? The security team? Does the security team promise that
> they will investigate every potential hole and either issue an advisory,
> or determine definitively that the bug is not exploitable?
Every line of code changed is a potential hole, and even Debian as a whole
does not come close to having the resources to audit at that level. So, no,
the security team does not promise that they will investigate every
potential hole. The best we can do is to focus on public announcements and
suspicious changes, or to do smaller, more manageable audits (such as Steve
Kemp has been doing).
However, when a maintainer brings an issue to the attention of the security
team, if they have reason to believe that it represents a security exposure,
the security team will investigate. Of course, the more review that can be
done by individual maintainers, the better the system scales.
> If so, great, you just need to make sure every developer knows and takes
> advantage of this service for every change they are not sure is benign.
Let's return to postfix as an example. One module of source code is
replaced with a different module of source code to implement similar
functionality. Is the maintainer sure the old code was benign? Are they
sure that the new code is benign? There is no way to tell without a
thorough audit. Surely we cannot assume that the new code is automatically
safer. Replacement code will contain vulnerabilities approximately as often
as the code being replaced, except perhaps when it is written explicitly to
fix *known* bugs.
However, if the maintainer sees, for example:
-strcpy(mybuffer, received_data_packet.data);
+strncpy(mybuffer, received_data_packet.data, sizeof(mybuffer));
or:
2003-08-16 ...
* network.c: Fix potential buffer overrun
* admin.c: don't allow access to change passwords unless the user is
authenticated
then this should be examined more closely, and I am willing to assist
maintainers with this kind of review.
> I suspect the reality is not nearly that good. I wonder how many
> maintainers even check adequately for potential security bugs. They don't
> always stand out in upstream changelogs. A huge range of bugs can be
> involved in an exploit. And it's practically axiomatic that most
> programmers have a poor understanding of security issues.
Maintainers often do not care in the least about security, or at least do
not notice it. Upstream security fixes will be uploaded to unstable without
checking whether stable needs to be fixed, or even mentioning the fact in
the changelog in some obvious way, sometimes even if the maintainer knows
about it.
> > I don't see what this has to do with the security team. If the
> > maintainer builds a package containing changes that he doesn't
> > understand, I wouldn't want it to bypass unstable and testing and be
> > injected directly into stable.
>
> It's possible to understand a change, and see that it is "obviously
> correct", without fully examining its security implications.
If the code before the change is questionable, and the new code is obviously
correct, and the change is properly documented, I see no obvious problem
with it. However, the volume of such changes would be far too much for a
stable distribution.
> > It certainly shouldn't be announced as a security update which users are
> > encouraged to install. A security advisory which does not explain the
> > user's exposure leaves them without the information they need to make a
> > decision about the update.
>
> It could be announced as a potential but unverified hole. Anyway, this
> whole "decision" thing is overblown for 99% of users. As long as Debian
> is careful with stable updates, they should be extremely reliable, and
> most users shouldn't think twice about installing them. I suppose the
> other 1% can do their own research. I think the benefit in terms of holes
> closed outweighs the cost of more numerous and less informative updates.
The reason why many users don't have to think about installing the updates
is because they trust us to be responsible with our changes. In cases where
the stability of the system is critical, updates will still be scrutinized,
because downtime must be scheduled. This means that they need to know the
urgency of the issue.
> > We already have a well-controlled bug-fix-only branch. It's called
> > "stable", and the system for making changes to it is known as
> > "proposed-updates".
>
> Bug-fixes do not get into stable in a timely fashion. proposed-updates is
> not known or not understood by most users. AFAIK, there's no policy about
> what goes there, which limits its usefulness. But maybe it could become
> part of the solution.
Bug fixes do not get into stable in a timely fashion because people talk
about it instead of putting effort into it. As far as I know, Joey has been
the only one working on this for quite a while now. If you would like to
see more or different point releases, the best thing to do would be to start
putting together more or different point releases.
If users do not know about or understand proposed-updates, it is their own
fault. It is quite clearly described at
http://www.debian.org/releases/stable/errata.
The policy for what will be accepted is also very clearly described, in the
developer's reference section 5.5.1 ("Uploads to Stable").
Joey maintains a set of web pages documenting the point release process:
http://people.debian.org/~joey/stable.html
--
- mdz
Reply to: