subject:"join us\!"

NEXT WEEK: Join us for the Contact Advocate, Inc. - 2005 - Get Found! Conference

2005-09-01 Thread Contact Advocate, Inc.

Title Sponsors

Join us for the Contact Advocate, Inc. - 2005 - Get Found! Conference

2005-08-18 Thread Contact Advocate, Inc.

Title Sponsors

Join us for the Contact Advocate, Inc. - 2005 - Get Found! Conference

2005-08-12 Thread Contact Advocate, Inc.

Title Sponsors

Re: join us!

2000-09-17 Thread Josip Rodin


Note: I don't read -user, just -devel, so I just saw this thread. I
apologize for duplication, if someone already said things I'm going to say
in my message.

Kurt Seifried wrote:
 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.

They have the same upstream version number (the part before the hyphen, `-')
but they do not have the same Debian revision (the part after the hyphen).
Besides, the tarball at the Debian sites/mirrors is still intact, it's just
the Debian patch (a gzipped unified diff) that changed.

 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.

The risk of introducing a bug with a patch made by security-oriented people
is quite small because those patches are usually short, discussed on a
mailing list (or several of them), and tested before uploading.

Frankly, I can't remember seeing many Debian security releases of a package
breaking anything compared to previous (security-wise broken) release of the
package. The most common problem with security uploads that is not related
to security is packages being compiled with wrong dependencies on some
architecture. This happened some three or four times in the last few years,
and the packages were recompiled shortly after after people reported it.

 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.

What can I say - we feel the gain is worth the effort.

 Third, the effort you invest in this detracts from the effort
 desperately needed to improve and develop open source software.

Security fixes are an improvement and a result of development of the open
source software that was fixed. There are many users who like the fact
Debian cares about stability and security, rather than caring for getting
the very newest stuff packaged.

 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.

Observing the kind of bug reports users file against Debian packages over
the past year or so, I came to the conclusion that the packages in stable
get far, far less bug reports than those in unstable, and the statistic
improves with each new release. You may choose not to believe me because
I'm biased - feel free to take a look for yourself, it's all on
http://bugs.debian.org/.

-- 
Digital Electronic Being Intended for Assassination and Nullification

Re: join us!

2000-09-16 Thread Peter Palfrader

[Sorry for the late jump in, I found this thread because of Seth's X-Post]
Hi Oliver!

On Thu, 31 Aug 2000, Oliver Elphick wrote:

 Kurt Seifried wrote:
 ...
   Problem: user can enter Lilo commands at the Lilo prompt
 ...
   Additional solution: remove/replace password in lilo.conf after setting it
   (i.e. set password, run lilo, remove password).
 
 You may not have noticed mbr:
 bash-2.04$ dpkg --status mbr
[...]
 If you are making a big thing of security against those with physical
 access, you need to mention this package, which is required and is
 silently installed in a Debian installation.  (It exists because the
  
 standard pc MBR is a non-free Microsoft product.)

Not any longer. There was a big discussion and flame fest a few months ago
and the default now is to _not_ install this mbr (instead install lilo into
the mbr). Additionally the mbr has been modified to print MBR upon boot time
so it is actually visible that /something/ is there.

HTH

yours,
peter

-- 
PGP encrypted messages preferred.
http://www.cosy.sbg.ac.at/~ppalfrad/
[please CC me on lists]


pgpLjNZL6JVro.pgp
Description: PGP signature

Re: join us!

2000-09-15 Thread David Benfell

On Thu, Aug 31, 2000 at 10:20:44AM -0400, Paul D. Smith wrote:
 
 %% Kurt Seifried [EMAIL PROTECTED] 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.

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.
 
 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.

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.

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.
 
 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.

  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?

 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?

  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.

 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.

-- 
David Benfell
[EMAIL PROTECTED]
ICQ 59438240 [e-mail first for access]
---
There are no physicists in the hottest parts of hell, because the
existence of a hottest part implies a temperature difference, and
any marginally competent physicist would immediately use this to
run a heat engine and make some other part of

Re: join us!

2000-09-15 Thread Seth Cohn


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 [EMAIL PROTECTED] 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

Re: join us!

2000-09-01 Thread Matt Stegman

On Thu, 31 Aug 2000, Kurt Seifried wrote:

 [snip] ... people view security as a number of small unrelated
 problems, when in fact you have to treat it as an entire, complex,
 system.

I agree.  I also think that good security needs to involve research.  I
think it's Debian's responsibility to provide secure packages, but I don't
expect them to handhold me through the installation and configuration
process.  There's far too many possible configurations for them to guess
at what is appropriate for me.

When I want to secure a system, I research it.  I check man pages.  I look
in /usr/doc.  I surf the web.  I look for books.  In short, I do what I
can to find out how this system works.  After I've read some, I
think.  Given my setup, how will changing X affect me?

I don't expect someone else to do this for me.  My security is my
responsibility.

 Problem: User can boot off off removable media
 Solution: Change BIOS settings, Debian can't really do this, however they
 may wish to document it. I have at:
 http://www.securityportal.com/lskb/1000/kben1001.html

Does everyone need to document this?  It already is, in many places.  In
fact, I consider it common knowledge.

 Problem: user can enter Lilo commands at the Lilo prompt
 Debian's solution (partial): install sulogin, thus requiring user to enter a
 root password for runlevel 1, this still allows the user to enter command
 arguments however.
 Real solution: use restricted and password, set lilo.conf mode 600, now
 the user must get root to read file or some other exploit to read file (then
 they could read /etc/shadow, or whatever as well).

I agree with you 100% here. sulogin is a half-assed solution.

...
 Problem: users with physical access can compromise security.
 Yes but there is a big difference between hitting ctrl-alt-del, tryping
 Linux init=/bin/sh then making them bring a boot disk, or if you locked
 the BIOS down stealing the machine/etc. I love visiting computers labs with
 Linux machines, I have yet to find one where lilo was restricted/password
 protected yet, many use sulogin, but that doesn't work so well.

Hmmm... my lab has for more than a year now.  All our computers are set to
boot from the hard drive only, BIOS has a password set, LILO has
restricted/password set... all non-needed services are turned off...
packages are updated to exploit-free versions (as far as I know,
anyway)... anything I'm missing here?

Actually, I think NFS is out biggest security problem.  As far as someone
can write down a lab computer's IP, bring their own computer in, and mount
our NFS shares, they'd get full access to everyone's home directories.  We
need something better, but that's an entirely different discussion.

 As you can see booting the computer (even looking at it in pure overview
 terms) is quite complex and there are many interactions (i.e. OS security is
 pointless if the attacker has a boot disk and can use it). However with a
 few simple steps you can plug all the holes possible short of sending a
 debian representitive to the persons house/business to install debian
 securely for them. The effort put into sulogin would have been better placed
 in making the install script go would you like to protect boot up
 blahblahblah Y/n: followed by set a lilo password:. As I pointed out to
 one person using sulogin and not securing Lilo is like putting a nice
 expensive dead bolt lock on a screen door.

Maybe that deserves to be filed as a bug.

-Matt Stegman
[EMAIL PROTECTED]

FAQ-O-Matic (was: Re: join us!)

2000-09-01 Thread Paul D. Smith

%% John Hasler [EMAIL PROTECTED] writes:

  jh Paul D. Smith writes:

   What kinds of problems are you seeing?

  jh I find the Web interface (the only one available to me as a section
  jh adminstrator) just about completely unusable for editing.

You mean the page with all the buttons for choosing different
operations, or the actual page for editing answers?

For the first, I agree that it takes some getting used to, but I don't
really have a better idea, myself.  I suppose there could be some kind
of choose menu with editing options instead of lots of little buttons.
Might be cleaner.

For the second, it's fine for me for small editing jobs; for larger ones
I do the work in my editor and paste the results into the window.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://www.paulandlesley.org/gmake/
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist

Re: FAQ-O-Matic (was: Re: join us!)

2000-09-01 Thread John Hasler

Paul D. Smith writes:
 For the second, it's fine for me for small editing jobs;

I find it frustrating for anything.

 I do the work in my editor and paste the results into the window.

I hadn't tried that.  I'd rather just download the file, edit it, and then
upload it.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: FAQ-O-Matic (was: Re: join us!)

2000-09-01 Thread Joey Hess

John Hasler wrote:
 Paul D. Smith writes:
  For the second, it's fine for me for small editing jobs;
 
 I find it frustrating for anything.
 
  I do the work in my editor and paste the results into the window.
 
 I hadn't tried that.  I'd rather just download the file, edit it, and then
 upload it.

Use a sane web browser (like w3m) that lets you edit fields in the
editor of your choice.

-- 
see shy jo

Re: join us!

2000-08-31 Thread Kurt Seifried

 Yes I read the update. I'd be happy to review your articles for you, but I
 don't think you should stop at one reviewer. Debian is a very big project
and I'm
 still finding my way around parts of it. You may have been in contact with
Ben
 Collins. If so I suggest you ask him too.

Yeah, he did email me, not terribly friendly. I think it's rather obvious I
researched the article if I was taking apart files like lilo.conf/etc.

Ben Collins wrote:

If you would have bothered to check the changelogs for the packages you
noted as having root hacks in them, you would have noticed that every
daemon you pointed out is not vulnerbale to the holes you point out. Here is
a list:

One question: where is it explicitly stated that Debian backports fixes and
that one needs to read /usr/doc/*/changelog?

I spoke to several friends, comp sci, one with a degree in software
engineering, and they all agree this is a horrible way to do things (the
software engineer went so far as to say a little piece of me dies everytime
someon does something like that). When I see ProFTPD 1.2.0pre10 I think
aha, this has a root hack, fixed in 1.2.0rc2. But Debian goes ProFTPD
1.2.0pre10-revision 4 (or whatever) has the root hack fixed, of course you
need to read the changelog to figure this out. If more vendors do this (and
unfortunately I am told Caldera does, I haven't confirmed it) life will be a
living hell for people, my Linux digest will be something like:

original source package from ftp.proftpd.net - ProFTPD 1.2.0pre10 has a root
hack, fixed in 1.2.0rc2

Debian ProFTPD 1.2.0pre10 revision 3 has the root hack mentioned above
however fixed in 1.2.0pre10revision 4, revision 5 also fixes some of the
problems that were possible in rc1

Caldera ProFTPD 1.2.0pre10 revision 2 has the root hack, partially fixed in
rev 4, completely fixed in rev 5 (whatever).

RedHat, SuSE, TurboLinux, Mandrake are all shipping 1.2.0rc2.

You see where this leads I think.

As for the code freeze, well the code is NOT frozen if Debian is
backporting changes into it, Apache 1.3.9 as shipped by Debian for example
is more like a 1.3.9 sortof 10/11/12 but not really. While the argument we
are not adding new features can be used, the fact of the matter is that
Debian is making (in some cases significant) changes to code that changes
behaviour (like fixing root hacks, cross site scripting vulnerability,
whatever).

not directed at anyone in generalP.S I am sick and tired of being flamed,
if you feel like it go outside and yell at the sky. It's not like I bother
to read emails with a subject line of you retard/

 regards,
 johno - [EMAIL PROTECTED]

-Kurt

Re: join us!

2000-08-31 Thread Paul D. Smith

%% Kurt Seifried [EMAIL PROTECTED] 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.

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 :).

Second, you are absolutely, 100% correct that there is a serious lack of
coherent documentation in these areas when it comes to Debian.  There
are a lot of things one is just kind of expected to know; or at least
I haven't found anyplace that brings them all together.  Some other
examples from just the last week or so: information on Debian runlevel
handling, and information on how Debian expects to share devices (group
permissions for /dev/sound, etc.)

The Debian Guide is great for newbies but doesn't have much information
for experienced users.

Manuals for newbies are very important, of course, but Debian really
needs either an appendix or another document that provides this more
detailed, distro-specific information.  Some kind of Introduction to
Debian for UNIX Admins.  I think Debian has many more experienced
UNIX/Linux people migrating to it than other distros, and so this kind
of migration guide is more important to Debian.

Please don't mark this as criticism per se: I maintain a manual too and
I know how hard it is.  I hope this is taken as encouragement for more
people to spend some time on this.

IMHO, FAQ-O-Matic is a _very cool_ tool and that should definitely be
revived and expanded, but a more manual-like document that could be
shipped with Debian would be even better.  Maybe even something in the
install that asked if you want to read it...

  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?

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 can't afford to put the entire set of potentially very
destabilizing changes into a current or almost-current product!
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.  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.

I just don't understand your friends' revulsion.

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://www.paulandlesley.org/gmake/
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist

Re: join us!

2000-08-31 Thread John Hasler

Paul D. Smith writes:
 IMHO, FAQ-O-Matic is a _very cool_ tool...

But a real PITA to administer.
-- 
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin

Re: join us!

2000-08-31 Thread Ben Collins

On Thu, Aug 31, 2000 at 07:18:18AM -0600, Kurt Seifried wrote:
  Yes I read the update. I'd be happy to review your articles for you, but I
  don't think you should stop at one reviewer. Debian is a very big project
 and I'm
  still finding my way around parts of it. You may have been in contact with
 Ben
  Collins. If so I suggest you ask him too.
 
 Yeah, he did email me, not terribly friendly. I think it's rather obvious I
 researched the article if I was taking apart files like lilo.conf/etc.

My appologies, but you did touch a nerve. Anyone in a place of high
visibility and large influence is expected to hold to higher standards
than everyone else. Sucks I know, but you have to carry that
responsibility, or you get problems like this one.

 Ben Collins wrote:
 
 If you would have bothered to check the changelogs for the packages you
 noted as having root hacks in them, you would have noticed that every
 daemon you pointed out is not vulnerbale to the holes you point out. Here is
 a list:
 
 One question: where is it explicitly stated that Debian backports fixes and
 that one needs to read /usr/doc/*/changelog?
snipped large portion of technical backing

This is ludicrous. Backporting fixes is done everywhere in the industry at
every level. Just because someone is running Solaris 5.5.1, is it a
vulnerable system? No, you have to run the patch checks to see if it is
secured.

On Windows95/98/2k/NT, the version level means nothing, even the SP# means
nothing, because patches are seperate pieces even then.

Now this is at a higher level, but we still see it in lower levels. Let's
take the Linux kernel. You'll notice that security fixes for that come
about well before there is a version increase, and most distributions
release a patched version well before they wait for a version increase to
be made available. GLibc is the same way, and even RedHat will patch up
the current version and release (I know this from experience).

Now, let's look at the reasoning Debian has for this. We'll inspect the
release cycle as it goes.

Debian unstable, oh the glory of mass uploads and new packages abound the
project. Bleeding edge releases of major and unknown software enter the
project. Many of these programs have major bugs in them. When new version
of the program come out, hey, they just get packaged up and tossed in,
hopefully not introducing any new bugs. Even if they do, it's ok, we're
unstable.

Now, along comes the initial freeze. No new packages are allowed in, and
new uploads are done in semi-caution. We're nearing release, and adding
too many new features always invites more new bugs. If major security
concerns arise, fix as needed, however it's needed.

Down the road, we enter a deep freeze. Oh shit! We're getting ready to
release. Boot-floppies and CD images start being tested very heavily.
Surely we don't take any new packages. New features are moot at this
point. The only uploads allowed are ones fixing fairly important bugs
(What we call Release Critical, see our website for details, in the Bug
Tracking System). If a security problem comes along, it has to be fixed,
however, we'll take the case of Apache like this:

Apache 1.3.9 is in the current frozen. We have to fix the bugs, but since
then Apache 1.3.12 has been released. We don't want this new version. The
current version has proven to contain no bugs in our BTS, the only problem
being this security flaw. This new verion may contain new unforseen bugs
that will require fixing again in the near future and maybe even some
incompatibilites that will require some hacking in order to make upgrades
easy. Do we take this extremely new version or do we side with caution and
backport the fixes? Obviously, for the sake of a more stable, bug-free
distribution, we fix the known bugs, and avoid introducing new ones. The
changes get noted in the packages' changelog (every Debian package has a
Debian changelog in the doc dir, it's documented that way).

This same thing happens after freeze. The current release gets patched to
fix *known* bugs, and we avoid at all costs introducing new ones. IMO,
this is a lot smarter than just taking the newest version. And anyone who
says anything different is just a version number junky, and not really
concerned or knowledgable about what it takes to produce a bug free
distribution.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: join us!

2000-08-31 Thread Paul D. Smith

%% John Hasler [EMAIL PROTECTED] writes:

  jh Paul D. Smith writes:

   IMHO, FAQ-O-Matic is a _very cool_ tool...

  jh But a real PITA to administer.

Hmm.  Well, we use a pretty large FOM internally at work here, and I
haven't noticed that it's a _huge_ PITA :).  Mostly seems pretty
self-administrating, and almost all the admin I've done has been through
the web interface (although I had to play with the search update cron
job due to permission issues).

What kinds of problems are you seeing?

-- 
---
 Paul D. Smith [EMAIL PROTECTED]  Find some GNU make tips at:
 http://www.gnu.org  http://www.paulandlesley.org/gmake/
 Please remain calm...I may be mad, but I am a professional. --Mad Scientist

Re: join us!

2000-08-31 Thread Dave Sherohman

Kurt Seifried said:
 Debian ProFTPD 1.2.0pre10 revision 3 has the root hack mentioned above
 however fixed in 1.2.0pre10revision 4, revision 5 also fixes some of the
 problems that were possible in rc1

Personally, when I see 1.2.0pre10-4, I think, This is not the same as the
original/base 1.2.0pre10.  Depending on how the numbering is implemented, it
has been updated 3 or 4 times since the original 1.2.0pre10.  So I would not
expect it to have the same bugs.

 As for the code freeze, well the code is NOT frozen if Debian is
 backporting changes into it, Apache 1.3.9 as shipped by Debian for example
 is more like a 1.3.9 sortof 10/11/12 but not really. While the argument we
 are not adding new features can be used, the fact of the matter is that
 Debian is making (in some cases significant) changes to code that changes
 behaviour (like fixing root hacks, cross site scripting vulnerability,
 whatever).

Would you be more comfortable if it were called a feature freeze?

-- 
Two words: Windows survives. - Craig Mundie, Microsoft senior strategist
So does syphillis. Good thing we have penicillin. - Matthew Alton
Geek Code 3.1:  GCS d- s+: a- C++ UL++$ P L+++ E- W--(++) N+ o+
!K w---$ O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv b+ DI D G e* h+ r++ y+

Re: join us!

2000-08-31 Thread Kurt Seifried

 Personally, when I see 1.2.0pre10-4, I think, This is not the same as
the
 original/base 1.2.0pre10.  Depending on how the numbering is implemented,
it
 has been updated 3 or 4 times since the original 1.2.0pre10.  So I would
not
 expect it to have the same bugs.

So did you fix the root hack in pre10, the DOS in rc1, or the typo in the
install script? Oh yeah, I gotta read the changelog to find out,
wheep.Making major changes to software (plugging root hacks counts I
think) and not modifying the software revision (ok, the Debian package
number is revised, but that means nothing unless you read the changelog) is
just a bad idea. Also when the main change in a software package is bug
fixes and not feature additions I think it might be sane to upate the
package, As for Apache, 1.3.12 has been out 6+ months, freezing software and
using a version much older doesn't make much sense to me (and let's face it,
some software packages, like Apache, do an extremely good QA job and
generally don't ship broken stuff, OTOH big billy bobs irc client version
.34 is another story).

  As for the code freeze, well the code is NOT frozen if Debian is
  backporting changes into it, Apache 1.3.9 as shipped by Debian for
example
  is more like a 1.3.9 sortof 10/11/12 but not really. While the argument
we
  are not adding new features can be used, the fact of the matter is that
  Debian is making (in some cases significant) changes to code that
changes
  behaviour (like fixing root hacks, cross site scripting vulnerability,
  whatever).

 Would you be more comfortable if it were called a feature freeze?

Yup. And for gods sake, document it somehwere that you need to read the
changelogs. I've actually gotten several emails from smart Linux people
(i.e. people that also write/manage online Linux related publications) going
hey, that's news to me too. I am not going to sit down and read /usr/doc/*
just on a whim, neither are most users or even people trying to do a review
(i.e. I wouldn't mind seeing you guys writing a review of say TurboLinux =).

 Dave

-Kurt

Re: join us!

2000-08-31 Thread Ben Collins

On Thu, Aug 31, 2000 at 10:03:59AM -0600, Kurt Seifried wrote:
  Personally, when I see 1.2.0pre10-4, I think, This is not the same as
 the
  original/base 1.2.0pre10.  Depending on how the numbering is implemented,
 it
  has been updated 3 or 4 times since the original 1.2.0pre10.  So I would
 not
  expect it to have the same bugs.
 
 So did you fix the root hack in pre10, the DOS in rc1, or the typo in the
 install script? Oh yeah, I gotta read the changelog to find out,
 wheep.Making major changes to software (plugging root hacks counts I
 think) and not modifying the software revision (ok, the Debian package
 number is revised, but that means nothing unless you read the changelog) is
 just a bad idea. Also when the main change in a software package is bug
 fixes and not feature additions I think it might be sane to upate the
 package, As for Apache, 1.3.12 has been out 6+ months, freezing software and
 using a version much older doesn't make much sense to me (and let's face it,
 some software packages, like Apache, do an extremely good QA job and
 generally don't ship broken stuff, OTOH big billy bobs irc client version
 .34 is another story).

Regarless of how good of a QA job they do, it doesn't mean squat when you
have to assure compability for 6 supported architectures. Taking new
versions to fix security problems, along with all the code changes, in
this fashion, is a management nightmare. There is no way to get out a
timely and stable fixed package using this method. There's no way to test
things enough. So you use the current *known good with one exception*
version, and fix it instead. This way you can sleep at night and retain
your sanity.

   As for the code freeze, well the code is NOT frozen if Debian is
   backporting changes into it, Apache 1.3.9 as shipped by Debian for
 example
   is more like a 1.3.9 sortof 10/11/12 but not really. While the argument
 we
   are not adding new features can be used, the fact of the matter is that
   Debian is making (in some cases significant) changes to code that
 changes
   behaviour (like fixing root hacks, cross site scripting vulnerability,
   whatever).
 
  Would you be more comfortable if it were called a feature freeze?
 
 Yup. And for gods sake, document it somehwere that you need to read the
 changelogs. I've actually gotten several emails from smart Linux people
 (i.e. people that also write/manage online Linux related publications) going
 hey, that's news to me too. I am not going to sit down and read /usr/doc/*
 just on a whim, neither are most users or even people trying to do a review
 (i.e. I wouldn't mind seeing you guys writing a review of say TurboLinux =).

I'de like to see you coordinate 6 architectural builds of some fairly
large packages and ensure stability, and compability for each one, just to
get a security update out. After all, we are talking about fixing the
bugs, not ooh, we have a reason to get version 1.0-foo into stable now!

You are right, users cannot be expected to read the changelogs all the
time. However, there is no easier way to dessiminate this information
other than a) security announcements, and b) changelogs, readily available
with the packages.

You, as a journalist, yes, we can expect you to read this, or alteast
contact some real Debian folks ([EMAIL PROTECTED] maybe?) before making
assumptions. Obviously no one can write a review of an operationg system
without knowledge of that system, or without further investigation into
that OS's structure and inner-workings.

Remember, Debian is volunteers, so you wont get a big corporate marketing
department spilling off oh we are great, we have insert buzz word here
and so on. You'll get very intelligent, and yes, sometimes harsh folks,
who do nothing but work on this all day long, and know what they are
talking about. They will give you straight answers, and most of them time,
when you speak intelligently yourself, and show an interest, rather than
negativity, they are even open to suggestions.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Re: join us!

2000-08-31 Thread Kurt Seifried

BTW Idon't know if anyone actually got it but the point of my article was
more that Debian is trying to improve security, but seems to be missing
major things. I suppose I should have stated this more obviously (like in H1
at the top). Sigh, anyways for next time I will be less subtle. Bruce
Schneier's new book (secret's and lies) covers this too, people view
security as a number of small unrelated problems, when in fact you have to
treat it as an entire, complex, system. For example: Protecting boot up:

Problem: User can boot off off removable media
Solution: Change BIOS settings, Debian can't really do this, however they
may wish to document it. I have at:
http://www.securityportal.com/lskb/1000/kben1001.html

Problem: user can enter Lilo commands at the Lilo prompt
Debian's solution (partial): install sulogin, thus requiring user to enter a
root password for runlevel 1, this still allows the user to enter command
arguments however.
Real solution: use restricted and password, set lilo.conf mode 600, now
the user must get root to read file or some other exploit to read file (then
they could read /etc/shadow, or whatever as well).
Additional solution: remove/replace password in lilo.conf after setting it
(i.e. set password, run lilo, remove password).

Problem: users with physical access can compromise security.
Yes but there is a big difference between hitting ctrl-alt-del, tryping
Linux init=/bin/sh then making them bring a boot disk, or if you locked
the BIOS down stealing the machine/etc. I love visiting computers labs with
Linux machines, I have yet to find one where lilo was restricted/password
protected yet, many use sulogin, but that doesn't work so well.

As you can see booting the computer (even looking at it in pure overview
terms) is quite complex and there are many interactions (i.e. OS security is
pointless if the attacker has a boot disk and can use it). However with a
few simple steps you can plug all the holes possible short of sending a
debian representitive to the persons house/business to install debian
securely for them. The effort put into sulogin would have been better placed
in making the install script go would you like to protect boot up
blahblahblah Y/n: followed by set a lilo password:. As I pointed out to
one person using sulogin and not securing Lilo is like putting a nice
expensive dead bolt lock on a screen door.

Kurt Seifried
SecurityPortal, your focal point for security on the net
http://www.securityportal.com/

Re: join us!

2000-08-31 Thread jpenny

On Thu, Aug 31, 2000 at 10:26:20AM -0600, Kurt Seifried wrote:
 BTW Idon't know if anyone actually got it but the point of my article was
 more that Debian is trying to improve security, but seems to be missing
 major things. I suppose I should have stated this more obviously (like in H1
 at the top). Sigh, anyways for next time I will be less subtle. Bruce
 Schneier's new book (secret's and lies) covers this too, people view
 security as a number of small unrelated problems, when in fact you have to
 treat it as an entire, complex, system. For example: Protecting boot up:
 
 Problem: User can boot off off removable media
 Solution: Change BIOS settings, Debian can't really do this, however they
 may wish to document it. I have at:
 http://www.securityportal.com/lskb/1000/kben1001.html

OK, 2 to 5 minutes downtime to disable.  Big Whoop.  Maybe should be
done.  But, have you ever tried to administer 200 computers?  How many
people know the BIOS password?  Do the primary users know it?  Can they
reboot their own machine?  Does an administrator have to visit every
machine every time it needs to be rebooted?  Do you write down lists
of 200 passwords?

 
 Problem: user can enter Lilo commands at the Lilo prompt
 Debian's solution (partial): install sulogin, thus requiring user to enter a
 root password for runlevel 1, this still allows the user to enter command
 arguments however.
 Real solution: use restricted and password, set lilo.conf mode 600, now
 the user must get root to read file or some other exploit to read file (then
 they could read /etc/shadow, or whatever as well).
 Additional solution: remove/replace password in lilo.conf after setting it
 (i.e. set password, run lilo, remove password).
 
 Problem: users with physical access can compromise security.
 Yes but there is a big difference between hitting ctrl-alt-del, tryping
 Linux init=/bin/sh then making them bring a boot disk, or if you locked
 the BIOS down stealing the machine/etc. I love visiting computers labs with
 Linux machines, I have yet to find one where lilo was restricted/password
 protected yet, many use sulogin, but that doesn't work so well.
 

This is actually one of only two reasonable points in the discussion.
The other point was that better documentation is needed.

 As you can see booting the computer (even looking at it in pure overview
 terms) is quite complex and there are many interactions (i.e. OS security is
 pointless if the attacker has a boot disk and can use it). However with a
 few simple steps you can plug all the holes possible short of sending a
 debian representitive to the persons house/business to install debian
 securely for them. The effort put into sulogin would have been better placed
 in making the install script go would you like to protect boot up
 blahblahblah Y/n: followed by set a lilo password:. As I pointed out to
 one person using sulogin and not securing Lilo is like putting a nice
 expensive dead bolt lock on a screen door.
 

I take it then that you have now retracted the version-itis 
(use the latest version no matter how many new holes may have been
introduced) argument.  I see no mention of the I didn't install
MD5 because I can't read recommendations during the setup process, so,
are we down to nothing but the LILO setup?  (And the need for more
documentation?)

 Kurt Seifried
 SecurityPortal, your focal point for security on the net
 http://www.securityportal.com/
 
 
 
 
 
 -- 
 Unsubscribe?  mail -s unsubscribe [EMAIL PROTECTED]  /dev/null

Re: join us!

2000-08-31 Thread Kurt Seifried

 OK, 2 to 5 minutes downtime to disable.  Big Whoop.  Maybe should be
 done.  But, have you ever tried to administer 200 computers?  How many
 people know the BIOS password?  Do the primary users know it?  Can they
 reboot their own machine?  Does an administrator have to visit every
 machine every time it needs to be rebooted?  Do you write down lists
 of 200 passwords?

I never said it was a great solution, but due to the crapulent management
nature of PC hardware there isn't much choice. Deal with it. Set bios
passwords, and yes, I guess you need to write them down. If a machine needs
to boot from removable media then chances are you need atech to visit and
fix it. Of course there are large lists of default BIOS passwords floating
around to :P. You can't exactly blame me for something the PC industry
decided to do years ago.

 This is actually one of only two reasonable points in the discussion.
 The other point was that better documentation is needed.

Better documentaiton is ALWAYS needed, I should know, I spend a lot of time
writing Linux security documentaiton and publishing it online for free, as
far as I know I'm the only game in town (with a minor exception being a
redhat install/security guide in PDF, url escapes me at the moment).

http://www.securityportal.com/lskb/

 I take it then that you have now retracted the version-itis
 (use the latest version no matter how many new holes may have been
 introduced) argument.  I see no mention of the I didn't install
 MD5 because I can't read recommendations during the setup process, so,
 are we down to nothing but the LILO setup?  (And the need for more
 documentation?)

Actually no, I am still annoyed with debian's versioning (lack of) and
making major software changes without really changing version numbers.

My point on MD5/crypt is crypt is the default, and most users would read the
text and be scared off of MD5. Red Hat for example makes MD5 and shadow the
default, you have to go choose them and disable them if you do not want them
(meaning most redhat users install with shadow and md5).

-Kurt

Re: join us!

2000-08-31 Thread John Hasler

Paul D. Smith writes:
 What kinds of problems are you seeing?

I find the Web interface (the only one available to me as a section
adminstrator) just about completely unusable for editing.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: join us!

2000-08-31 Thread Bob Bernstein

On Thu, Aug 31, 2000 at 10:03:59AM -0600, Kurt Seifried wrote:

 So did you fix the root hack in pre10, the DOS in rc1, or the typo in the
 install script? Oh yeah, I gotta read the changelog to find out,
 wheep.

Well, you're going to have to read it somewhere, yes? And now you know where!

 As for Apache, 1.3.12 has been out 6+ months, freezing software and
 using a version much older doesn't make much sense to me 

What does that mean, doesn't make much sense to me? I have just read
through this whole thread and in it are two very good explanations of why
this is done here, and many many other places, as noted, all over the
industry.

I can't help but think what a review of OpenBSD by you would look like! I
would like to see you take on Theo for insisting (still) on bind4, not 8!
But his reasoning is exactly what's been described here! Sure, you can
install bind8 if you wish on obsd - there's a package for it - but just try
to tell them it's bind8 that belongs in the distro. Whoosshhh. g

 Yup. And for gods sake, document it somehwere that you need to read the
 changelogs. I've actually gotten several emails from smart Linux people
 (i.e. people that also write/manage online Linux related publications) 

Oh, you mean Linux journalists? Hmmm... You were looking much better when
you just admitted that you didn't do your homework; continuing this attack
is getting very old. Changelogs are standard components of the apparatus
that comprises how software is distributed, not just in Linux but all over
the industry. Why do you think those files are there? Insisting that you
should be informed that they ought to be actually *read* is like asking
someone to remind you to be careful when you fire up your chainsaw.

 I am not going to sit down and read /usr/doc/* just on a whim, neither are
 most users or even people trying to do a review

On a whim? I gotta tell you Kurt, you are all over the court, and you are
not doing yourself any favors by persisting in this. Only your best friends
will tell you: chill out; get some sleep; and stop reacting all over the
place. Do yourself a favor and stay off these lists for a few days. Your ego
is getting in your way. Come back when your head clears.

-- 
Bob Bernstein
at
Esmond, R.I., USA

Re: join us!

2000-08-31 Thread Oliver Elphick

Kurt Seifried wrote:
...
  Problem: user can enter Lilo commands at the Lilo prompt
...
  Additional solution: remove/replace password in lilo.conf after setting it
  (i.e. set password, run lilo, remove password).

You may not have noticed mbr:
bash-2.04$ dpkg --status mbr
Package: mbr
Status: install ok installed
Priority: required
Section: base
Installed-Size: 42
Maintainer: Santiago Vila [EMAIL PROTECTED]
Version: 1.1.2-1
Description: Master Boot Record for IBM-PC compatible computers.
 This is used in booting Linux from the hard disk.
 The MBR runs first, then transfers control to LILO, which transfers
 control to the Linux kernel.

As far as I can see, install-mbr can be used to second-guess the BIOS
on available boot devices, and by default allows one to boot from floppy
even if the BIOS has floppy-booting disabled (or after the hard disk).
You get the mbr prompt if you press Ctrl too early when waiting for
the lilo prompt.

If you are making a big thing of security against those with physical
access, you need to mention this package, which is required and is
silently installed in a Debian installation.  (It exists because the
standard pc MBR is a non-free Microsoft product.)

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
  ...Take heed, and beware of covetousness; for a man's
  life consisteth not in the abundance of the things 
  which he possesseth.   Luke 12:15

NEXT WEEK: Join us for the Contact Advocate, Inc. - 2005 - Get Found! Conference

Join us for the Contact Advocate, Inc. - 2005 - Get Found! Conference

Join us for the Contact Advocate, Inc. - 2005 - Get Found! Conference

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

FAQ-O-Matic (was: Re: join us!)

Re: FAQ-O-Matic (was: Re: join us!)

Re: FAQ-O-Matic (was: Re: join us!)

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

Re: join us!

25 matches

Site Navigation

Mail list logo

Footer information