also sprach Thomas Walter <t.walter@nefkom.net> [2006.06.24.0047 +0200]:
> When using Debian and from one stable release to the other then you have
> a "drastic/radical" change in features/functionality.
Yes, at a point in time *I* can define, and I have about a year of
flexibility.
> Due to the fact that there may be several major/minor releases from
> upstream jumped over while the package lives in
> experimental/unstable/testing.
... which is why Debian tries to ensure a migration path not from
one package to the next, but from stable to testing.
> Using backport one can mitigate big steps but profit from
> improvements in existing features/functionality. Maybe,
> new/additional functionality introduces new bugs, but this risk is
> reduced by the strict rules of backports ti use SW from testing
> only.
Right. *maybe* this approach is feasible for a small number of
machines. But when you're in charge of hundreds of Debian machines,
you really want to make all the changes once and in a two or three
week time frame during which you can dedicate your energy.
I use Debian because I do not want to read about a security problem
on Friday morning, upgrade the machines after the mirror pulse,
leave for the weekend at a reasonable hour, and get a pager alert at
home because this "amazing new feature" introduced a bug and crashed
most of the systems. I also don't want to find out that 1.2 dropped
a feature that 1.1 merely deprecated, just because last night,
someone decided s/he wants 1.2 on backports.org now.
> In general upstream goes forward, not backward and does not release bug
> fix versions forever.
... which is why Debian stable backports them. Now, backports is
a necessity for a lot of reasons, but it's *not* Debian stable. And
since Debian stable is the reason that *I* employ Debian on
critical servers, I sure as hell want to have a say as to what gets
upgraded to a new upstream version, and when.
> In brief, if the customer wants version x, then the admin has to
> provide version x.
Sure. But that does not mean he has to run the slightest chance of
accidentally pulling in version y of a different package, which
might break things.
I am not saying "stop backports.org". I am saying change the policy
to require the admin to explicitly allow packages to be installed or
upgraded, and for me, that's the difference between the -1 and the
200 pin.
> As the name/definition says, "security updates" fix bugs which are
> a security hole, but not bugs in features/functionality.
Dude. backports.org does not have a policy to only allow security
bugs. If, as you say, upstream fixes a security bug in a newer
version, which also introduces this "amazing new feature Y", then
please, ask me whether I want to install it. Or: don't install it
unless I have checked and approved of it.
> Most internal users are no intruders.
Check your facts. The last paper published by CERT in 2004
attributes somewhere close to 70% of *all* attacks to come from the
inside, be they by disgruntled users or trojans.
My point has been made. It won't cause any pain to change the
default pin to those who follow or have followed the directions on
the web. But it will protect those who err, and it will propagate
a more serious and secure default.
'nuff said.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
spamtraps: madduck.bogus@madduck.net
"this sentence contradicts itself -- no actually it doesn't."
-- douglas hofstadter
Attachment:
signature.asc
Description: Digital signature (GPG/PGP)