Re: join us!
Please follow up to Debian-devel, since this isn't really a user issue.
[please ignore the long quoted sections. I decided it ws better to quote
in full, since I was crossposting this]
At 04:34 PM 09/15/2000 -0700, David Benfell wrote:
On Thu, Aug 31, 2000 at 10:20:44AM -0400, Paul D. Smith wrote:
>
> %% Kurt Seifried <seifried@securityportal.com> writes:
>
> ks> One question: where is it explicitly stated that Debian backports
> ks> fixes and that one needs to read /usr/doc/*/changelog?
>
> I'll answer this on two levels:
>
> First, if you're writing an article on a subject for publication it
> behooves you to find this information, even if it's not explicitly
> stated. In other words, if you think to yourself "hey, that's strange,
> this system seems to be shipping old, security-problem-ridden code!"
> (which you basically said you thought in your article) then you should
> try to find out if that's really true. One excellent way to do that is
> by posting one simple message to this mailing list.
No, the best way would be to contact the _maintainer_ of the package in
question. Ultimately, that person(s) is responsible for the software on
behalf of Debian.
Debian has an excellent system to not only find out WHO maintains the code,
but how to contact them. Either by bugreport programs, website info, or
just dpkg- s <package>, you will get the info you need to contact the right
person.
This assumes that it is a reasonable assumption that there might be
another explanation. I would argue that Kurt's assumption, though
incorrect, was reasonable.
Basically, you are forking development. There is now a version to be
found in all the standard places where you get the tar-balls, and
another version to be found in Debian. But they both have the same
version number. This is misleading information.
No, they are NOT forking. Consider: the only way to get the Debian version
is from a Debian site. Debian packages are set up as orig.tar.gz and a
Debian Patch.
This prevent the exact problem you are talking about.
> If this had been done, you could have blasted Debian for documentation
> issues, while still performing a valuable service by educating people,
> via your article, on how Debian handles security updates :).
>
Granted.
>
> ks> I spoke to several friends, comp sci, one with a degree in
> ks> software engineering, and they all agree this is a horrible way to
> ks> do things (the software engineer went so far as to say "a little
> ks> piece of me dies everytime someon does something like that").
>
> Uhm. Can you provide more details about exactly what they're objecting
> to?
>
First, you are forking development. You are applying code from future
modifications to old software. This poses a significant risk of
introducing bugs which will not be reproducible anywhere except in a
Debian environment. This cuts off the non-Debian part of the open
source community in cooperating to resolve problems.
No, this allows Debian to ship 'known stable' but still 'security-hole'
with a minimum of problems. Given the choice between a patched hole of
version 1.2stable and 'secured' 2.0beta, the choice is clear. Keep in
mind, 99% of the time, the current up-to-date version is in unstable, and
can and will be used by those who want it (they can recompile it for stable
if needed).
As for non-reproducible anywhere but Debian, this is why Debian has a
bug-tracking system. And a maintainer who will track and fix those
problems, since they are the patcher in most cases.
Second, you are duplicating effort. Even if your backports of bug
fixes can be cleanly applied to the old code, you still must test
them. In some cases, it will not be possible to apply these backports
cleanly. This will require development which has already been done in
the main fork.
See above. Development of new things might be worse than a bug-fix.
What if 2.0 breaks things that 1.2 had working? (ie XF864.0 vs 3.3.6)
Third, the effort you invest in this detracts from the effort
desperately needed to improve and develop open source software.
For these reasons, I find the claim that you are retaining stability
to be dubious. Perhaps it really works sometimes. I suspect,
however, that you have merely chosen another form of instability which
is perhaps more to your liking, but not necessarily to mine.
Someone took responsiblity to patch things. It's not just 'hey, here's a
patch'.
It's "The maintainer felt that this patch was critical to the software,
even tothe point of a backport."
> Backporting specific fixes to earlier releases is not only not "a
> horrible way to do things", but is absolutely de rigueur in the
> industry.
You overstate this. Some very valuable improvements are indeed often
backported. Far more often, the answer to software problems is,
instead, get the latest version.
USB 2.2 backport versus 2.4 USB in kernel
> You can't afford to put the entire set of potentially very
> destabilizing changes into a current or almost-current product!
How can you be so confident that your backporting/forked development
model introduces significantly fewer destabilizing changes? Have you
any statistics to validate this?
Yes, it's called the Debian bugreport and Debian's history of security.
> Instead, you extract the most important fixes and port them back into
> the stable release so people can get the benefits of that specific fix,
> in a stable environment.
>
> Most everybody does this. Even the Linux kernel, for example.
Again, you overstate the case. While the 2.0 kernel tree continues to
be maintained, it only sees what its maintainers believe are the most
important fixes. Other issues which may be troublesome are ignored.
And I believe you are, somewhat, begging the question. How many
people running the 2.0 kernel chose it for new installations? Are
they simply running the 2.0 kernel because they choose not to fix what
isn't broken or, given a new system to set up, are they choosing a 2.0
kernel for its vaunted stability?
Yes. and it's size, and it's known issues (or lack thereof)
> Many of
> the packages which have security fixes announced on CERT, etc. provide
> patches for older releases in addition to saying that the latest release
> has fixed the problem.
>
Perhaps I misunderstand, but my impression of this is that the patches
for older releases, where present, essentially upgrade older versions
to newer versions.
No, they fix holes or bugs, NOT add new features.
> I just don't understand your friends' revulsion.
I do. And the world of programming would have had to changed a whole
lot more than I think it has for my concerns about this approach to be
satisfied.
Hope this clears up your questions.
Seth
Reply to: