Re: Broken signature for DSA-2040-1

2010-05-02 Thread Martin Schulze 
Kurt Roeckx wrote:
> On Sun, May 02, 2010 at 09:06:46PM +0200, Francesco Poli wrote:
> > Hi,
> > I received DSA-2040-1 and verified its GPG signature, as I always do.
> > I found out that I am unable to correctly verify the signature.
> 
> Works for me:
> gpg: Signature made Sun 02 May 2010 02:55:15 PM CEST using DSA key ID 4E2ECA5A
> gpg: Good signature from "Moritz Muehlenhoff "
> gpg: aka "Moritz Muehlenhoff "

Without a working signature the mail wouldn't be transported through
debian-security-announce.  A valid ecurity team member's signature is
required.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100502194941.gb31...@finlandia.home.infodrom.org

Re: Vulnerabilities not affecting Debian: reporting proposal

2007-07-11 Thread Martin Schulze 
Alexander Konovalenko wrote:
> On 7/11/07, Martin Schulze <[EMAIL PROTECTED]> wrote:
>>
>> Do you know about
>>
>> http://www.debian.org/security/nonvulns-etch
>
> Oh, that's great. I should have read the website more carefully! Thanks.
>
> What about providing a more elaborate summary for some issues? Some
> entries merely say that the bug is not exploitable or that Debian is
> not affected.

Feel free to add (or adjust the output format).
Should be discussed with the web team I guess ([EMAIL PROTECTED])

Regards,

Joey


-- 
It's time to close the windows.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Vulnerabilities not affecting Debian: reporting proposal

2007-07-11 Thread Martin Schulze 
Alexander Konovalenko wrote:
> Proposed solution

Do you know about

http://www.debian.org/security/nonvulns-etch

Regards,

Joey
http://www.debian.org/security/nonvulns-sarge

-- 
It's time to close the windows.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 1258-1] New Mozilla Firefox packages fix several vulnerabilities

2007-02-07 Thread Martin Schulze 
Alexander Sack wrote:
> On Wed, Feb 07, 2007 at 08:36:56AM +0100, Martin Schulze wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > - --
> > Debian Security Advisory DSA 1258-1[EMAIL PROTECTED]
> > http://www.debian.org/security/ Martin Schulze
> > February 7th, 2007  http://www.debian.org/security/faq
> > - --
> 
> Isn't this about thunderbird? We had the firefox announcement a bit
> ago already.

Lalala

-- 
Every use of Linux is a proper use of Linux.  -- Jon 'maddog' Hall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA 1184 corrections

2006-10-05 Thread Martin Schulze 
Jens Seidel wrote:
> On Thu, Oct 05, 2006 at 09:06:41AM +0200, Martin Schulze wrote:
> > Jens Seidel wrote:
> > > I applied the following patch to CVS and hope I did it right. But I have
> > > one problem understanding the text:
> > > 
> > > Index: dsa-1184.wml
> > > ===
> > > RCS file: /cvs/webwml/webwml/english/security/2006/dsa-1184.wml,v
> > > retrieving revision 1.5
> > > retrieving revision 1.6
> > > diff -u -r1.5 -r1.6
> > > --- dsa-1184.wml  29 Sep 2006 19:01:15 -  1.5
> > > +++ dsa-1184.wml  2 Oct 2006 17:35:13 -   1.6
> > > @@ -1,6 +1,6 @@
> > >  several vulnerabilities
> > >  
> > > -This advisory covers the S/390 components of the recent security
> > > +This advisory covers the S/390 component of the recent security
> 
> > Umh...  Now the advisory text is misleading on the web:
> > 
> >More information:
> > 
> >   This advisory covers the S/390 component of the recent
> >   security update for the Linux 2.6.8 kernel that was missing
> >   due to technical problems. For reference, please see the
> >   text of the original advisory.
> > 
> > This advisory DSA 1184 does not only cover the S/390 components but
> > updates for all architectures.  The update DSA 1184-2, linked at the
> > bottom as revised advisory (strictly speaking, it's not a revised
> > advisory but an addition, so maybe we need a new string and tag)
> > covers only the S/390 components.
> > 
> > Btw. since there are four binary packages for S/390, it's plural, hence,
> > components.
> 
> OK, but shouldn't it be "that WERE missing" if you use plural or does
> "was" refer to "the recent security update"?

Oops...

You are correct.

> > > @@ -67,7 +67,7 @@
> > >  
> > >  Diego Calleja Garcia discovered a buffer overflow in the DVD
> > >  handling code that could be exploited by a specially crafted DVD
> > > -or USB storage device to execute arbitrary code.
> > > +USB storage device to execute arbitrary code.
> > 
> > It is DVD or USB storage as both can trigger the vulnerability. 
> 
> ?
> 
> I googled for this vulnerability before I changed anything. As far as I
> understand the DVD driver/handling code is affected and this can only
> be exploited using a DVD hardware device, e.g. a USB DVD device or even
> an ATAPI drive.

Hmm, did I misunderstood it?  I have no desire to dig out the details, so
I propose to leave the text as it is now (i.e. with your correction).

> OK, I added it to CC: and will be more carefully in the future. (There where
> no other changes to content from me, only typo fixes.)

Yes, saw it, and these changes are highly appreciated, at least by me.

Regards,

Joey

-- 
Given enough thrust pigs will fly, but it's not necessarily a good idea.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: BADSIG verifying s.d.o Release file

2006-06-30 Thread Martin Schulze 
martin f krafft wrote:
> I've been seeing this a bunch in the past few weeks. Just making
> sure you know about it, and maybe someone knows what's going on:
> 
> W: GPG error: http://security.debian.org stable/updates Release: The
> following signatures were invalid: BADSIG 010908312D230C5F Debian
> Archive Automatic Signing Key (2006) <[EMAIL PROTECTED]>

Could the reason be that the Release.gpg file has a size of zero?
If so, I've already informed ftpmasters.  If not, what's the other
cause?

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bogus DNS data from several debian.org authoritative servers

2006-05-29 Thread Martin Schulze 
Florian Weimer wrote:
> * Martin Schulze:
> 
> > Disabled again.  The problem lies somewhere "between" saens and you.
> > It's fine on saens locally.
> 
> While the bogus A record should be gone now that saens is down, you
> should still remove saens from the list of authoritative name servers
> for debian.{org,com,net} and ipv6.debian.org.  This is definitely not
> a local issue at Bjørn's site, it's globally visible.

Err... that's a bit more complicated...
So, in theory you are correct.

Regards,

Joey


-- 
Ten years and still binary compatible.  -- XFree86


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bogus DNS data from several debian.org authoritative servers

2006-05-29 Thread Martin Schulze 
Neil McGovern wrote:
> I'm forwarding this over to debian-admin, as they're the people who can
> fix this :)

I had already answered Bjoern:

Ah yes, the named on saens went alive again.  That was not planned.

Disabled again.  The problem lies somewhere "between" saens and you.
It's fine on saens locally.

Regards,

Joey

-- 
Ten years and still binary compatible.  -- XFree86


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "Fix" of sudo with DSA-946-1

2006-03-22 Thread Martin Schulze 
Freek Dijkstra wrote:
> Martin Schulze wrote:
> 
> > Proposed updates for woody and sarge are here:
> > http://klecker.debian.org/~joey/security/sudo/
> > I'd be glad if you could test them.r
> 
> That's awesome. Thanks! Here, have some karma :-)

:)

> I just installed your version on sarge using:
> - Remove my (custom) "Defaults" line in my /etc/sudoers file
> - sudo dpkg -i sudo_1.6.8p7-1.4_i386.deb
> 
> Most environment variables seem there as I would expect, and those I
> don't expect are indeed removed. The only issue I still have is that the
> manual page should still be updated. I noticed some changes in
> sudoers.pod (in sudo_1.6.8p7-1.4.diff.gz), but somehow that did not pass
> to the sudoers.5.gz man page in the sudo_1.6.8p7-1.4_i386.deb.

Umh...  That's a packaging bug, I'll get it recreate the manpage
explicitly

> I just read through all bugreports, and carefully tried to reproduce
> each one to see if all is well now.
> 
> Most importantly, the variables that are kept are indeed now the same as
> I would get when I specify "Defaults env_reset". Specifically:
> HOME variable kept (closes #349587)
> SHELL variable kept (closes #350776)

> DISPLAY   variable kept (closes #349085)
> XAUTHORITY variable kept (closes #349549)

These are not passed through by env_reset with the original source,
but only with this patch.

> Two variables are not kept:
> EDITOR variable kept (bug #349196).

Not important.

> LC_ALL variable kept in earlier releases, including sudo_1.6.8p7-1.3
> (the previous security fix).

I've added the locale variables again.

> Update manual pages (#349129):
> NOT FIXED.

Done now.

> Given that some things still need manual tweaking (e.g. EDITOR or LC_*
> variables), it is good to update the page. I noticed that one of the
> file you created, sudo_1.6.8p7-1.4.diff.gz, has some manual changes to
> sudoers.pod, but these changes are not reflected in the sudoers.5.gz man
> page in the sudo_1.6.8p7-1.4_i386.deb. Additionally, if you have not
> done so, here is also a patch for the man pages:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349196;msg=34

Too many unrelated changes, rejected, should potentially be applied to
the version in sid->etch.

> sudo -V output is misleading: it gives a very incomplete list of
> env vars that are removed. (also #349129)
> NOT FIXED.

Well... yes, it is misleading.  That's due to the program structure.

> To be honest, I'm not sure if this should be fixed now. On one hand it
> would be good, but I fear that it may introduce too much new code (which
> seem a bad thing for a security patch). I would leave it open for etch,
> but not fix it in woody or sarge, but the security team can decide best.

It should be adjusted in sid instead.

> Complaint about 'sudo vi ':
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349196;msg=15
> Status: I can't reproduce it (or it is simply fixed now)

Problem was missing $HOME.

> Complaint about "sudo joe filename":
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349196;msg=10
> Status: I can't reproduce it (or it is simply fixed now)

Problem was missing $HOME.

> Complaint that "Defaults env_reset, env_keep=*, always_set_home" gives
> two PATH variables instead of one (#354431).
> NOT FIXED.
> This is indeed an important bug, but I think it is not directly related
> to the security bug, and should thus just be fixed in etch.

Not security related.

> Finally, I suggest to add a /usr/share/doc/sudo/READM.Debian file with
> this contents:

Ok.

Thanks a lot.  I've produced new packages and copied them to the same
location.

Regards,

Joey

-- 
Linux - the choice of a GNU generation.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "Fix" of sudo with DSA-946-1

2006-03-20 Thread Martin Schulze 
Proposed updates for woody and sarge are here:
http://klecker.debian.org/~joey/security/sudo/
I'd be glad if you could test them.r

Regards,

Joey

-- 
Linux - the choice of a GNU generation.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: umn.edu security.d.o host unreachable

2006-03-13 Thread Martin Schulze 
martin f krafft wrote:
> Hi, it seems 128.101.240.212, one of the two remaining security
> mirrors, is unreachable. Other mirrors (non-Debian, like
> 128.101.240.209 and 128.101.240.210, which seem to be right "next
> door") are reachable.
> 
> It would be great to get a status update from the administration
> team.

The host is not reachable.

Regards,

Joey

-- 
The only stupid question is the unasked one.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: tartini (one of the security mirrors) unreliable

2006-03-10 Thread Martin Schulze 
martin f krafft wrote:
> tartini.debian.org, one of the three servers providing
> security.debian.org seems to have intermittent problems:
> 
> Get:1 http://security.debian.org sarge/updates/main Packages [189kB] 
> Err http://security.debian.org sarge/updates/main Packages
>  
>   Connection timed out [IP: 82.94.249.158 80]
> 
> This isn't the first time I am seeing this. The host does recover
> after a short time, but the problem keeps coming back. I doubt the
> problem is on my end, this is from a rack machine with
> a triple-redundant connection directly onto Berlin's Level3
> backbone and I see no other problems.
> 
> Maybe the administrators would be so kind as to investigate the
> issue and send an update when it's resolved?

I've finally removed tartini from the security round robin.

Regards,

Joey

-- 
Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: db.debian.org certificate

2006-02-28 Thread Martin Schulze 
Noèl Köthe wrote:
> Hello,
> 
> the https db.debian.org certificate is expired on 2006-01-30.

Certificate requested from wiggy on

Date: Tue, 14 Feb 2006 14:17:08 +0100

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: PMASA-2005-6 when "register_globals = on"

2005-11-15 Thread Martin Schulze 
Neil McGovern wrote:
> On Tue, Nov 15, 2005 at 05:54:32PM +0100, Piotr Roszatycki wrote:
> > http://www.phpmyadmin.net/home_page/security.php?issue=PMASA-2005-6 reports 
> > that sarge's phpmyadmin package has a security flaw which is occured only 
> > if 
> > "register_globals = on" setting is used.
> > 
> > This feature is disabled in Debian package by default so I doubt if this is 
> > serious problem. I'd like to ask if I should prepare the new package for 
> > sarge or not?
> > 
> 
> According to the advisory, all versions < 2.6.4-pl4 are affected
> (2.7.0-beta1 from the development schema).
> 
> This would mean that this affects sid and etch too. Has a bug been
> filed/a CVE number assigned for this?

I don't know of one.  We may have to go without one for the moment.

Also, a second issue has just popped up:
http://www.fitsec.com/advisories/FS-05-02.txt

I'd be glad if you could provide patches and packages for
both issues.

(both because in the second the path disclosure is bogus for
us since dpkg -c will disclose the path as well).

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: What's going on with advisory for phpmyadmin?

2005-10-28 Thread Martin Schulze 
John Goerzen wrote:
> On Fri, Oct 28, 2005 at 04:42:31PM +0200, Piotr Roszatycki wrote:
> > Why my report was ignored? I've reported the problem 3 days ago and I had 
> > no 
> > reply.
> 
> This seems to be a very frequent problem going on for awhile now.
> 
> Could someone from the security team comment on what the problem is?

The problem in this case is confusing reports and patches with
arbitrary changes that don't belong into security updates.

Regards,

Joey

-- 
Life is too short to run proprietary software.  -- Bdale Garbee


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Version of 'cvs' in security archive

2005-09-14 Thread Martin Schulze 
Loïc Minier wrote:
> On Tue, Sep 13, 2005, Sam Morris wrote:
> > Is the version in stable too high, or is the version in stable/updates 
> > too low? :)
> 
>  I think packages never leave from security.d.o.

In cvs you see the result of the major fuckup of security.debian.org I was
complaining about loudly during the release.  The version for woody ended
up in sarge.  Since the version number is lower than the version in sarge
in the main archive, you can safely ignore it.

On security.debian.org:

klecker!joey(pts/0):~> elmo -e -s cvs
cvs oldoldstable  1.10.7-9.2 alpha arm i386 m68k powerpc sparc 
source
cvs oldstable 1.11.1p1debian-13  alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source
cvs stable1.11.1p1debian-11  alpha amd64 arm hppa i386 ia64 
m68k mips mipsel powerpc s390 sparc source

In the main archive:

spohr!joey(pts/13):~> elmo -e cvs
cvs oldstable  1.11.1p1debian-10  alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source
cvs stable 1:1.12.9-13alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source
cvs testing1:1.12.9-15alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source
cvs unstable   1:1.12.9-14hurd-i386
cvs unstable   1:1.12.9-15alpha arm hppa i386 ia64 m68k mips 
mipsel powerpc s390 sparc source

Gruesse,

Joey

-- 
Testing? What's that? If it compiles, it is good, if it boots up, it is perfect.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Request for help with Kernel, Ethereal and Lesstif

2005-09-01 Thread Martin Schulze 
Lesstif
---

We have a bunch of patches for libxpm which is also part of lesstif1-1
in woody that need to be applied and tested.  It needs to be
investigated whether the version in sarge needs patches as well.  This
refers to only a single bug (CAN-2004-0914) but results in quite a
large patch that does not cleanly apply.  A good C coder with a
lesstif test environment is required.

Ethereal


The test program, Red Hat and iDEFENSE discovered several (read 24)
flaws in various disssectors of Ethereal.  The patches need to be
reviewed and applied to the versions in woody, sarge and sid.  For sid
the maintainer could yuo some help, hence, I've mentioned it above.
The advisory text should be proposed as well.

Kernel
--

I have prepared an updated kernel package for woody's 2.4.18 kernel
for a number of vulnerabilities (some 40).  This work needs to be
reviewed and ported to 2.4.16, 2.4.17 and 2.4.19 including testing.
The 2.4.18 kernel is running on a test machine and under a real
environment during LinuxTag and from time to time afterwards without
problems.


For all set of packages it needs to be documented which bugs exist in
which version.

All three issues have escaped the time frame of the security team in
the past, hence, I'm now calling for help.


The volunteer is required to be a registered Debian developer.


If you are interested and sure that you can work on one of these
issues, please get in touch with me.  If you are not 100% sure that
your skills are sufficient, please don't contact me, since I would
probably only waste time needed for other stuff.

Regards,

Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier

Please always Cc to me when replying to me on the lists.


signature.asc
Description: Digital signature

Re: On Mozilla-* updates

2005-07-30 Thread Martin Schulze 
Noah Meyerhans wrote:
> Most other OS vendors are willing to make updates for errata beyond
> simple security updates.  Often this means minor updates to software
> packages like web browsers.  I believe the community will be better able
> to help us prepare e.g. bug-free firefox 1.0.5 packages than it will to
> produce 1.0.4+security packages.  I believe these updated packages

Looking at how 1.0.5 was binary-incompatible with 1.0.4 I can only
assert that the community has failed already.

> should be tested as thoroughly as possible and released via
> security.debian.org and included in the next sarge revision.  As an

We don't have the proper framework for thoroughly testing security
updates before they are visible on security.debian.org similar to the
10 days embargo from unstable into testing.  The regular testing is
not sufficient as it can't cover all details.

> Whatever solution we choose, I believe it is very important for us to do
> it within Debian and not rely on backports or some other unofficial
> channels.  As Debian developers, it is our duty to solve this problem,
> and simply kicking the packages out of Debian or ignoring them from the
> point of view of updates and security is really no solution at all.

Be prepared for reality, in half a year or in one year, there won't be
1.0.x Mozilla Firefox packages anymore that build on Debian stable.
At least that's what I anticipate.

Regards,

Joey

-- 
Experience is something you don't get until just after you need it.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

On Mozilla-* updates

2005-07-29 Thread Martin Schulze 
Moin,

it seems that less than two months after the release of sarge it is
not possible to support Mozilla, Thunderbird, Firefox (and probably
Galeon) packages anymore.  (in terms of fixing security related
problems)

Unfortunately the Mozilla Foundation does not provide dedicated and
clean patches for security updates but only releases new versions that
fix tons of security related problems and other stuff that is or may
be irrelevant for security updates.  As a result, it is extremely
difficult to get security patches extracted and backported.  This is
an utter disaster for security teams and distributions that try to
support their releases.

We have tried to prepare updated packages, but they may cause problems
as has been the case for a Debian fork.  Eventually they've given up
and released the new upstream version as security update.  *sigh*

Using new upstream versions are bound to cause new problems.  Maybe
not at the moment with only going from 1.0.4 to 1.0.6 but more
probably they will do later.

Sooner or later they will change the behaviour of the program (so uses
will be confused), change the API (so plugins, language files etc
won't work anymore), alter the dependencies (so the packages will be
slurp in new packages or cannot be built on stable at all).

I guess in the long term we're on a lost track and it seems this
situation has already started.

For these packages, help and/or advice is appreciated.

Regards,

Joey

-- 
It's time to close the windows.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#319406: heartbeat: upgrade and reconfigure errors

2005-07-25 Thread Martin Schulze 
Horms wrote:
> The attached patch should resolve this problem, and I have put
> packages that include this patch up at
> http://debian.vergenet.net/pending/heartbeat/
> 
> Joey, what do you want to do about this?

We can't do anything about it.

All you can do, ant that's what you did already, is provide .deb files
and add the link to this bug report.

Fortunately, the problem does not occur regularily and does not
affect many users (otherwise the bug would have been reported
years ago already when there was a working proposed-updates
directory).

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian Security Support in Place

2005-07-09 Thread Martin Schulze 
Lupe Christoph wrote:
> > The security team will continue to support Debian GNU/Linux 3.0 alias
> > woody until May 2006, or if the security support for the next release,
> > codenamed etch, starts, whatever happens first.
> 
> This is equivalent to saying "We will rip security support for oldstable
> from under your feet at any time just as we please".

No, it is not.  Please read again.

> This is not acceptable in a production environment. May 2006 is less
> than a full year anyhow, which is very short for a production
> environment.

It'll be end of May 2006, which will be one year minus 6 days or so
after the release of sarge.  Do we need to discuss days?

> So in essence the announcement says "screw you, commercial customers".

Please read again, you failed.

Regards,

Joey

-- 
Reading is a lost art nowadays.  -- Michael Weber

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian security archive/updates b0rken???

2005-06-29 Thread Martin Schulze 
Steve Langasek wrote:
> On Sun, Jun 19, 2005 at 12:31:23AM -0400, sean finney wrote:
> > please excuse this blatant cross-posting, i wouldn't do it if i didn't
> > think it were critical that i do so...
> 
> > http://www.infodrom.org/~joey/log/?200506142140
> 
> > say it isn't so!
> 
> It isn't so.  It's true that the design of sbuild/wanna-build means there
> were no autobuilders available for stable-security at the moment of sarge's
> release, but there was already work in progress to fix this by the time that
> blog entry was posted, and the claim that "it looks like we'll be without
> security updates for quite a while" caused no small amount of consternation.

To avoid confusion, feel free to keep the security in the loop and send
updates to them.

FWIW: Up to today (still 8000 mails to go, though, there's a small
chance that an answer is within them), I still don't know what to
to with the updates to crip, bzip2, cvs and ht, that were in the
queue at the time sarge was released.  I asked both Ryan and the
ftpmaster team, without receiving an answer, hence the security
team can only assume that the status from the time sarge was released
is still true: security.debian.org broken.

I don't like abusing my root permission to fix areas where I shouldn't
intervene, hence I'm trying to avoid this on security.debian.org as
well.

> TTBOMK, there is now again a full complement of stable-security autobuilders
> available on 11 archs, and autobuilders for testing-security on 10/11 archs.

Good.

> It doesn't look like the security team has issued any DSAs since then,

Because they sent inquiries about the situation and haven't yet received
a note that everything is fine again and how to proceed with the updates
already in the queue.

> though they may have done uploads that haven't yet been published (I
> wouldn't know, not having access to look on klecker).

No uploads have been made since the release of sarge, because the archive
is broken.  What you could have seen was made before the release of sarge.
I have had prepared more than half a dozen uploads but did not upload them,
though.

I've uploaded a few packages now to find out if it's working again.
I don't expect the next DSAs to work properly, though.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please allow drupal 4.5.3-1

2005-06-02 Thread Martin Schulze 
Steve Langasek wrote:
> On Wed, Jun 01, 2005 at 07:16:00PM -0700, Ian Eure wrote:
> > On Wednesday 01 June 2005 04:54 pm, Hilko Bengen wrote:
> > > Just a few hours ago, the Drupal project has released version 4.5.3, a
> > > bugfix release which fixes a serious security bug. I have created and
> > > just uploaded a 4.5.3-1 package to unstable. Updated Debconf
> > > translations are the only additional changes over 4.5.2-3 which is
> > > the version in sarge.
> > Any reason why you can't just apply the patch to fix that specific bug?
> 
> > And you probably want to be emailing the release team...
> 
> He did contact the release team; unfortunately, the diff between 4.5.2 and
> 4.5.3 is rather large and I don't believe it's all security-related, so I
> think this will have to be left for the security team after all.

Umh, the release team most probably has even stricter rules than the
release team when it comes to cluttering the diff...

Regards,

Joey

-- 
If you come from outside of Finland, you live in wrong country.
-- motd of irc.funet.fi


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fixing stupid PHP application design flaws

2005-05-05 Thread Martin Schulze 
Florian Weimer wrote:
> * Henrique de Moraes Holschuh:
> 
> > I think not only we should do it, we should also make a big fuss
> > about it, so that some of the PHP people out there at least have a
> > chance to get the clue.
> 
> Unlikely to work.  Just look at how almost all PHP developers reject a
> proactive approach to SQL injection. 8-(

When upstream is security-ignorant, we need to educate our developers
to fix the applications before actually uploading, and fix them again
when a new upstream version is released, over and over again.

Regards,

Joey

-- 
If nothing changes, everything will remain the same.  -- Barne's Law

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fixing stupid PHP application design flaws

2005-04-30 Thread Martin Schulze 
Jeroen van Wolffelaar wrote:
> > Having /usr/share/$package for the include files and
> > /var/lib/$package for the executable PHP scripts that should be linked
> > into the web server.
> 
> Eh, that's now how squirrelmail works. All stock php files are in
> /usr/share/$package, and that's also what's used from the default apache
> config for squirrelmail. The config dir is symlinked from thew webroot
> to /etc, and so is that attachment spool symlinked to the appropriate
> /var/spool link. While all config files are accessible via the web, they
> have .php and are a no-op when executed seperately.

In another mail I already said that squirrelmail seems to operate the
way it should, which is very promising.

> > Even less competent users should be able to install these three
> > components on a bare system.  You can also provide a simple Makefile
> > to accomplish this task.  Such things worked for other packages as
> > well.
> 
> "Simple makefile" doesn't match the typical person installing a web
> application. A .tar.gz may already be too difficult, they want to be
> able to ftp their files to their provider and it should work. Also, this

Such people should stay being users and not try to become
administrators, really.

Also, if the  Debian distribution contains such applications that are
installed this way, they may need a new maintainer.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fixing stupid PHP application design flaws

2005-04-29 Thread Martin Schulze 
Jeroen van Wolffelaar wrote:
> > What do people on this list think about fixing PHP include files in a
> > DSA that are accessible via HTTP as well and contain one bug or
> > another as they are not supposed to be accessible via HTTP but
> > accidently are.
> > 
> > I'm rather annoyed by the lack of comptence of some PHP coders who
> > manage their project in a way so that include files are stored within
> > the regular DocumentRoot and are hencely accessible via HTTP as well.
> > Include files normally also don't contain any precaution about being
> > "executed" standalone.
> > 
> > These files should not be accessible via HTTP in the first place but
> > put into /usr/share/something instead and included from there.
> 
> I don't think that those include files are per definition a problem -- a
> well-managed project will only ship 'stock' include files only
> containing functions, whether the user gets to see the source of it, or
> it's being executed, it doesn't hurt.

I agree, as long as they are silent, they don't pose a problem per se.

> Of course, it's different if this is not the case (non-function stuff in
> include files). I'd myself be inclined to advice to only fix those

non-function and non-class.

> cases where there might be a potential problem. A lot of PHP web
> applications are designed by upstream to be simply untarreable in the
> place where the URL is supposed to be, and as such have include files
> necessarily http-accessible. It's sometimes hard for packagers to fix
> this, and when the include fiels cannot do harm, I don't see why.

Clean design.  Less tempting for stupid "coders".  Just to name two.

> It'd be wise for those projects to take the extra precaution by allowing
> (and the Debian maintainer to do so) include files outside the web root,
> but to DSA for such a thing when there might not even be a vulnerability
> at all, seems premature to me. It'd be like fixing all uses of sprintf
> because the programmer could have used snprintf to be more sure there is
> no problem.

Sure, that was never my intention either.

Regards,

Joey

-- 
Never trust an operating system you don't have source for!

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Fixing stupid PHP application design flaws

2005-04-29 Thread Martin Schulze 
Hans Spaans wrote:
> Martin Schulze wrote:
> > Hey!
> > 
> > What do people on this list think about fixing PHP include files in a
> > DSA that are accessible via HTTP as well and contain one bug or
> > another as they are not supposed to be accessible via HTTP but
> > accidently are.
> 
> Patching them like Squirrelmail has fixed this may be a better solution
> before everything is in place.

>From a first look, this is what I proposed, yes.

Having /usr/share/$package for the include files and
/var/lib/$package for the executable PHP scripts that should be linked
into the web server.

> > I'm rather annoyed by the lack of comptence of some PHP coders who
> > manage their project in a way so that include files are stored within
> > the regular DocumentRoot and are hencely accessible via HTTP as well.
> > Include files normally also don't contain any precaution about being
> > "executed" standalone.
> 
> I both agree and disagree with you. The reason I disagree with you, is
> that this works fine for php scripts that come with debian, but thats

No.  But it would work in Debian at least.

It is no problem to provide a tarball (or zip file) with the following
contents:

www/   - all files that need to be beneath DocumentRoot
include/   - all files that are included
foo.conf   - becomes /etc/foo/foo.conf and contains the path to include

Even less competent users should be able to install these three
components on a bare system.  You can also provide a simple Makefile
to accomplish this task.  Such things worked for other packages as
well.

> it. Everything a normal user installs is still a problem and even a
> bigger problem then the packages from debian. Also I counted 95 packages
> depending on php4 in Sarge at the moment versus way to many entries when
> you query freshmeat?

What are you trying to say?

> > These files should not be accessible via HTTP in the first place but
> > put into /usr/share/something instead and included from there.
> 
> Is this going to solve the problems? Don't get me wrong, because I love

Yes.  It would solve the problem of accessing include files that
shouldn't be accessed via HTTP since they weren't designed to be silent.

> your goal but I don't believe that what you suggesting right now is
> going to solve the problems with PHP at this moment. Maybe its an idea

It's not a problem with PHP but with web applications written in PHP.

I can imagine that similar problems exist with eperl, epython, pike or
any other languages embedded in the web space that weren't developed
thoroughly.

> to get in contact with Rasmus about securing PHP, because he's trying to
> get a more secure and sane php4.ini in the upstream releases. Unluckily

Securing PHP is a laaarge goal.

> Beside the fact that your plan has some issues with multiple
> installations because some application require that for multiple vhosts.

No.  Include files should be vhost-agnostic.  If they aren't, a lot
has gone wrong during implementation.  It should be sufficient to just
install the accessible PHP files a second time and maybe adjust the
database or other local storage, i.e. a differend config file.

> It may be a better idea to start with PHP itself and ask during
> installation of the users wants to install a secure or insecure version
> of php4.ini. The same is done with setuid issues for example.

There is no secure version of php4.ini.

> > As examples see the following problems:
> > 
> > CAN-2005-0459 - information disclosure in phpmyadmin
> 
> This one goes even further then information disclosure and isn't the
> reason you want it out of your docroot at this moment. Using unchecked
> variables isn't wise at all time.

You could say this problem is twofold...

> > CAN-2005-0870 - cross site scripting in phpsysinfo
> 
> Another example of what Rasmus is fighting for the last couple of years.
> Make the default php4.ini more sane and secure.

That won't work.  This is broken by design.  In the application.
PHP only provides the tools to shoot oneself in both feet, but others
do as well.  There's nothing wrong with it.  You don't have to do it...

Regards,

Joey

-- 
Never trust an operating system you don't have source for!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Fixing stupid PHP application design flaws

2005-04-28 Thread Martin Schulze 
Hey!

What do people on this list think about fixing PHP include files in a
DSA that are accessible via HTTP as well and contain one bug or
another as they are not supposed to be accessible via HTTP but
accidently are.

I'm rather annoyed by the lack of comptence of some PHP coders who
manage their project in a way so that include files are stored within
the regular DocumentRoot and are hencely accessible via HTTP as well.
Include files normally also don't contain any precaution about being
"executed" standalone.

These files should not be accessible via HTTP in the first place but
put into /usr/share/something instead and included from there.

As examples see the following problems:

CAN-2005-0459 - information disclosure in phpmyadmin
CAN-2005-0870 - cross site scripting in phpsysinfo

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#278777: xsok: unfixed buffer overflow (CAN-2004-0074)

2004-11-01 Thread Martin Schulze 
Steve Kemp wrote:
> On Fri, Oct 29, 2004 at 10:12:33PM +0200, Frank Lichtenheld wrote:
> 
> > Perhaps someone with a little more experience in identifying security
> > problems should take a look, too. I CC'ed debian-security.
> 
>   Here's a quick summery :
> 
>   To be clear there are three flaws being discussed in xsok:
> 
>CAN-2004-0074 - overflow with LANG environmental variable.
>  - overflow due to long '-xsokdir' parameter.
> 
>CAN-2003-0949 - Failure to drop privileges when unzipping.
> 
>   The second one was discovered by me and closed in DSA-405-1
> 
>   The first one is in two parts, the environmental variable
>  overflow is patched already by the package maintainer.  The
>  second appears to be not an issue given this code:
> 
> if (strlen(savedir) > MAXSAVEFILELEN-16 ||
> strlen(xsokdir) > MAXXSOKDIRLEN || [2]
> strlen(p->xpmdir) > MAXXSOKDIRLEN) {
> fprintf(stderr, "directory too long\n");
> exit(1);
> }
> 
> 
>   The second line [2] seems to test its bounds - unless I missed
>  an earlier usage.  I've got it installed here, but sadly I have
>  no X available so I cant test it.
> 
>   Run the following command to test if it's vulnerable:
> 
>  xsok -xsokdir `perl -e 'print "X"x3000'`

Thanks a lot!  I'll addd it to the non-vuln list.

Regards,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA 557-1 and CAN-2004-0564

2004-10-04 Thread Martin Schulze 
David F. Skoll wrote:
> On Mon, 4 Oct 2004, Martin Schulze wrote:
> 
> > There are reasons users install it setuid / setgid, and these installations
> > are vulnerable.
> 
> I disagree.  There is absolutely *no* reason to install rp-pppoe
> setuid-root.  It is normally invoked by pppd, and pppd must be either
> invoked by root or setuid-root itself.  Could you name a scenario in
> which a setuid-root rp-pppoe is needed?

Please talk to the Debian maintainer of rp-pppoe since pppoe is installed
root.dip and setuid in Debian sarge and sid.  The maintainer can be reached
through [EMAIL PROTECTED]  Details about this package can be found
here: http://packages.debian.org/pppoe

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DSA 557-1 and CAN-2004-0564

2004-10-04 Thread Martin Schulze 
David F. Skoll wrote:
> The rp-pppoe "security advisory" is totally bogus.  rp-pppoe is
> not meant to run SUID-root, and nowhere in the documentation is this
> recommended.

There are reasons users install it setuid / setgid, and these installations
are vulnerable.

> You might as well post a security advisory about "ls" because it doesn't
> drop privileges if it's installed SUID-root.

If it would be common for ls to run setuid/setgid and it was vulnerable
to any attack, we't have to, unfortunately.

Regards,

Joey

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: missing DSA for python2.2 ?

2004-08-31 Thread Martin Schulze 
Noèl Köthe wrote:
> Hello,
> 
> there is a stable update for python2.2
> (http://security.debian.org/pool/updates/main/p/python2.2/) available
> but there is no DSA for python2.2 on the webpage or mailinglist.
> 
> Is it missing or is the update wrong?

Hmm, you are correct.  I started to send out the advisory on August 28th,
but it wasn't sent out.  I guess it's due to a broken console at home and
I forgot about it.  I'll restart it.

Regards,

Joey

-- 
There are lies, statistics and benchmarks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Improved Debian Project Emergency Communications (was Re: communication structures crumbled)

2003-11-29 Thread Martin Schulze 
Karsten M. Self wrote:
> > It had to be re-installed.  You probably know that since you've read
> > the announcement we were able to send out before the machine was taken
> > down for reinstallation.
> 
> That announcement wasn't delivered for all users until _after_ murphy
> was resurrected.  I myself got the debian-security-announce message
> mailed Nov 21 on 25 Nov 2003 15:16:56 -0800.

That's true since murphy was powered down for a re-install in the middle
of its delivery.  The (same) mail on debian-announce should have been
delivered by that time.

Regards,

Joey

-- 
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Re: Improved Debian Project Emergency Communications (was Re: communication structures crumbled)

2003-11-29 Thread Martin Schulze 
Karsten M. Self wrote:
> > It had to be re-installed.  You probably know that since you've read
> > the announcement we were able to send out before the machine was taken
> > down for reinstallation.
> 
> That announcement wasn't delivered for all users until _after_ murphy
> was resurrected.  I myself got the debian-security-announce message
> mailed Nov 21 on 25 Nov 2003 15:16:56 -0800.

That's true since murphy was powered down for a re-install in the middle
of its delivery.  The (same) mail on debian-announce should have been
delivered by that time.

Regards,

Joey

-- 
Have you ever noticed that "General Public Licence" contains the word "Pub"?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: communication structures crumbled

2003-11-27 Thread Martin Schulze 
Dan Jacobson wrote:
> To us debian users, the most notable thing during this break in or
> whatever episode, is how the communication structures crumbled.

It had to be re-installed.  You probably know that since you've read
the announcement we were able to send out before the machine was taken
down for reinstallation.

> debian-announce had one message on the 21st, five days ago, saying for
> more information, see www.debian.org.

You'll find the same information linked on the front-page.  Since the
web infrastructure was affected as well, but you already knew that
since it was mentioned in the announcement, it was not that easy
updating the web server.  However, after a day we finally managed to
do that.

> Nothing special there, so I checked http://www.debian.org/security/,
> same problem.

As you know http://www.debian.org/security/ if for security
announcements regarding the packages Debian distributes.  It has
nothing to do with the security on the Debian machines.  Hence, it's
the wrong place.

> With the mailing lists affected, what would average user me do to
> learn the latest on the situation, google around? Googleing around
> just lead me to some stale discussion on the mailing lists before they
> got turned off.

Join #debian on any IRC network and see if somebody can relay some new
information.  Alternative: wait until the admin team manages to
resurrect the machines and services.

> At least some latest news could have been posted to the main website.

It sort-of was.

Joey

-- 
It's time to close the windows.

Please always Cc to me when replying to me on the lists.

Re: communication structures crumbled

2003-11-27 Thread Martin Schulze 
Dan Jacobson wrote:
> To us debian users, the most notable thing during this break in or
> whatever episode, is how the communication structures crumbled.

It had to be re-installed.  You probably know that since you've read
the announcement we were able to send out before the machine was taken
down for reinstallation.

> debian-announce had one message on the 21st, five days ago, saying for
> more information, see www.debian.org.

You'll find the same information linked on the front-page.  Since the
web infrastructure was affected as well, but you already knew that
since it was mentioned in the announcement, it was not that easy
updating the web server.  However, after a day we finally managed to
do that.

> Nothing special there, so I checked http://www.debian.org/security/,
> same problem.

As you know http://www.debian.org/security/ if for security
announcements regarding the packages Debian distributes.  It has
nothing to do with the security on the Debian machines.  Hence, it's
the wrong place.

> With the mailing lists affected, what would average user me do to
> learn the latest on the situation, google around? Googleing around
> just lead me to some stale discussion on the mailing lists before they
> got turned off.

Join #debian on any IRC network and see if somebody can relay some new
information.  Alternative: wait until the admin team manages to
resurrect the machines and services.

> At least some latest news could have been posted to the main website.

It sort-of was.

Joey

-- 
It's time to close the windows.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

static stunnel

2003-04-23 Thread Martin Schulze 
I've been asked to post the patch below.  Karsten Merker supplied
me with a patch to link woody stunnel statically against openssl.

Regards,

Joey

-- 
It's practically impossible to look at a penguin and feel angry.

Please always Cc to me when replying to me on the lists.
diff -Nur stunnel-3.22.orig/Makefile.in stunnel-3.22/Makefile.in
--- stunnel-3.22.orig/Makefile.in   Tue Apr 22 18:26:33 2003
+++ stunnel-3.22/Makefile.inTue Apr 22 18:24:51 2003
@@ -87,7 +87,7 @@
 # internal rules
 
 stunnel: $(OBJS)
-   $(CC) $(LDFLAGS) -o stunnel $(OBJS) $(LIBS)
+   $(CC) $(LDFLAGS) -o stunnel $(OBJS) -static $(LIBS)
 
 stunnel.so: Makefile env.c
$(CC) -fPIC -shared $(LDFLAGS) -o stunnel.so env.c $(LIBS) || \
diff -Nur stunnel-3.22.orig/debian/changelog stunnel-3.22/debian/changelog
--- stunnel-3.22.orig/debian/changelog  Tue Apr 22 18:26:33 2003
+++ stunnel-3.22/debian/changelog   Tue Apr 22 18:26:06 2003
@@ -1,3 +1,9 @@
+stunnel (3.22-1openssl096c2woody4) unstable; urgency=high
+
+  * statically link in new openssl 0.9.6c-2.woody.4
+
+ -- Karsten Merker <[EMAIL PROTECTED]>  Mon, 22 Apr 2003 18:17:00 +0100
+
 stunnel (3.22-1) unstable; urgency=high
 
   * New upstream release (closes: bug#126627).
diff -Nur stunnel-3.22.orig/debian/control stunnel-3.22/debian/control
--- stunnel-3.22.orig/debian/controlTue Apr 22 18:26:33 2003
+++ stunnel-3.22/debian/control Tue Apr 22 18:24:51 2003
@@ -1,7 +1,7 @@
 Source: stunnel
 Section: non-us/main
 Priority: optional
-Build-Depends: debhelper, libssl096-dev, openssl, libwrap0-dev, sdf
+Build-Depends: debhelper, libssl-dev (>=0.9.6c-2.woody.4), openssl 
(>=0.9.6c-2.woody.4), libwrap0-dev, sdf
 Maintainer: Paolo Molaro <[EMAIL PROTECTED]>
 Standards-Version: 3.5.1

Re: [SECURITY] [DSA 265-1] -- BAD SIGNATURE !?

2003-03-22 Thread Martin Schulze 
Nick Boyce wrote:
> On Friday 21 Mar 2003 2:01 pm, Martin Schulze wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > -
> >- Debian Security Advisory DSA 265-1
> > [EMAIL PROTECTED] http://www.debian.org/security/      
> >   Martin Schulze March 21st, 2003   
> > http://www.debian.org/security/faq
> > -
> [snip]
> 
> I get a bad signature reported by Kmail on this announcement.  Saving 
> the message out to a text file and verifying manually also fails :

Ditch KMail, it is a permanent source of problems when it comes to
digital signatures.

Also read http://www.debian.org/security/faq#signature

Feel free to fetch the message from the list archives on the
web and verify that one instead of the local copy.

Regards,

Joey

-- 
Still can't talk about what I can't talk about.  Sorry.  -- Bruce Schneier

Re: [SECURITY] [DSA 265-1] -- BAD SIGNATURE !?

2003-03-21 Thread Martin Schulze 
Nick Boyce wrote:
> On Friday 21 Mar 2003 2:01 pm, Martin Schulze wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > -
> >- Debian Security Advisory DSA 265-1
> > [EMAIL PROTECTED] http://www.debian.org/security/      
> >   Martin Schulze March 21st, 2003   
> > http://www.debian.org/security/faq
> > -
> [snip]
> 
> I get a bad signature reported by Kmail on this announcement.  Saving 
> the message out to a text file and verifying manually also fails :

Ditch KMail, it is a permanent source of problems when it comes to
digital signatures.

Also read http://www.debian.org/security/faq#signature

Feel free to fetch the message from the list archives on the
web and verify that one instead of the local copy.

Regards,

Joey

-- 
Still can't talk about what I can't talk about.  Sorry.  -- Bruce Schneier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: IBM and wrong DSA

2002-10-04 Thread Martin Schulze 
martin f krafft wrote:
> [joey, CCing you to make sure you see this immediately. you probably
> read debian-security too, i'd assume...]
> 
> Check out
> 
>   
> http://www-1.ibm.com/services/continuity/recover1.nsf/MSS/MSS-OAR-E01-2002.765.1
> 
> DSA 169 is htcheck, not tomcat, right? At least that's the case on
> www.debian.org.
> 
> What's up?

Read the mail I sent to -private.

Regards,

Joey

-- 
It's time to close the windows.

Re: IBM and wrong DSA

2002-10-04 Thread Martin Schulze 

martin f krafft wrote:
> [joey, CCing you to make sure you see this immediately. you probably
> read debian-security too, i'd assume...]
> 
> Check out
> 
>   http://www-1.ibm.com/services/continuity/recover1.nsf/MSS/MSS-OAR-E01-2002.765.1
> 
> DSA 169 is htcheck, not tomcat, right? At least that's the case on
> www.debian.org.
> 
> What's up?

Read the mail I sent to -private.

Regards,

Joey

-- 
It's time to close the windows.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Security updates without DSA?

2002-09-30 Thread Martin Schulze 
Olaf Meeuwissen wrote:
> Olaf Meeuwissen <[EMAIL PROTECTED]> (that's me!) writes:
> 
> > Dear .debs,
> > 
> > I recently wanted to apply security updates to a machine I'd installed
> > from woody pre6 CDs, hardened and upgraded to woody proper.  [...]
> > 
> > Before applying the upgrades I checked whether there was a DSA for the
> > packages that were going to be upgraded.  Surprise, there were several
> > that did not (seem to) have a corresponding DSA.
> > 
> > Question: Is that normal and OK?

Yes.  During the deep freeze of woody the security infrastructure was
implemented.  Security updates were added to woody before it was released
without issuing a DSA for each and every package.

Regards,

Joey

-- 
Every use of Linux is a proper use of Linux.  -- Jon "Maddog" Hall

Re: Security updates without DSA?

2002-09-30 Thread Martin Schulze 

Olaf Meeuwissen wrote:
> Olaf Meeuwissen <[EMAIL PROTECTED]> (that's me!) writes:
> 
> > Dear .debs,
> > 
> > I recently wanted to apply security updates to a machine I'd installed
> > from woody pre6 CDs, hardened and upgraded to woody proper.  [...]
> > 
> > Before applying the upgrades I checked whether there was a DSA for the
> > packages that were going to be upgraded.  Surprise, there were several
> > that did not (seem to) have a corresponding DSA.
> > 
> > Question: Is that normal and OK?

Yes.  During the deep freeze of woody the security infrastructure was
implemented.  Security updates were added to woody before it was released
without issuing a DSA for each and every package.

Regards,

Joey

-- 
Every use of Linux is a proper use of Linux.  -- Jon "Maddog" Hall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian-security-announce-$lang@lists?

2002-08-19 Thread Martin Schulze 
Ricardo Javier Cardenes Medina wrote:
> Mmmh... Comes to mind... What are the chances for a non-developer to be
> on "writers" at CVS now that we're authenticating via developer-related
> ssh keys? That would be very convenient just as many people (at least on
> the Spanish team) remain not being Debian Developers themselves, and
> relay on the developers to upload their changes. We've been thinking on
> a quite complicated way involving a second CVS on our servers :-D, but
> it's a lot of burden, if you ask me.

Please read http://www.debian.org/devel/website/

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

Please always Cc to me when replying to me on the lists.

Re: debian-security-announce-$lang@lists?

2002-08-14 Thread Martin Schulze 
Oohara Yuuma wrote:
> For your information, this is how the Japanese translation of DSAs works:
> 1. Kenshi Muto forwards the English DSA to [EMAIL PROTECTED]
>as soon as possible (usually in 24 hours)
> 2. Seiji Kaneko translates the e-mail version of DSA into Japanese and
>post it to [EMAIL PROTECTED]

Hmm, so the DSAs are all received twice at least.  Well, people will
be informed about incidents earlier than the translation is ready,
which is good.

I'd say the following two should be optimized by Mariko requesting an
account on www.debian.org so he doesn't need Tomohiro for committing. :)

> 3. Mariko GODA translates the wml version of DSA into Japanese and
>post it to [EMAIL PROTECTED] (this takes a while)
> 4. Tomohiro KUBOTA commits the translated DSA wml to the CVS server

Regards,

Joey

-- 
Let's call it an accidental feature.  --Larry Wall

Please always Cc to me when replying to me on the lists.

Re: debian-security-announce-$lang@lists?

2002-08-14 Thread Martin Schulze 
Jan Niehusmann wrote:
> On Wed, Aug 14, 2002 at 12:18:29PM +0200, Danny De Cock wrote:
> > On Wed, 14 Aug 2002, Siegbert Baude wrote:
> > > language. As a side note: I personally know Germans and foreign
> > > Chinese students here in Germany working in this business, whose
> > > English skills wouldn`t allow reading complicated DSAs.

One could reduce a DSA to "do I have this package installed?  Yes,
then I'd better update.".  However, if these people are subscribed to
a translation list and no translator is available at the moment,
they'll end up with a knowingly vulnerable system until they receive
the translated DSA.  This delay is what I am concerned about, since
it's easy to become infinitive when people are unavailable, on
holiday, on debconf or whatever.

> > I do not think these people will (be able to) set up their own debian
> > system: if their foreign language skills are insufficiently evolved to
> > install such a system, there is no need to read the DSAs.
> 
> While I agree that sufficient english skills to read a DSA are necessary
> to do a good job administrating a debian system, I'm very sure it is
> possible to install debian without understanding english. 

Looking at the gratuous (sp?) effort with translating everything,
granted for sure.

> I think the problem is a different one: In my experience, nearly all people
> dealing with linux systems know enough english to read DSAs. But many
> are just to lazy to read anything that is not in their native language.
> So translating the DSAs may lead to more secure debian systems, and in
> the end, less vulnerable systems on the net. So I think it's a good
> idea. At least as long as it doesn't delay the distribution of the
> english DSA.

These people already have the chance of reading DSAs in their native
tongue at the web server, though, imposing a delay, based on the work
of the translator and the website rebuild.  Hence, there is already a
chance for these people to read DSAs in their native tongue.

I'm counting one "I'm in favour of translated -announce lists"

Regards,

Joey

-- 
Let's call it an accidental feature.  --Larry Wall

Please always Cc to me when replying to me on the lists.

Re: debian-security-announce-$lang@lists?

2002-08-14 Thread Martin Schulze 
InfoEmergencias - Luis Gómez wrote:
> El mié, 14-08-2002 a las 11:03, Javier Fernández-Sanguino Peña escribió:
> > I do not see the benefit of this "push" method if we take in
> > account that we already provide an RDF channel for advisories and users
> > can configure their user agents (like Evolution) to retrieve them
> > automatically.
> 
> Hey, I knew nothing about it - Where can I learn more about polling such
> info with Evolution?

Check out http://www.debian.org/security/dsa.rdf

Regards,

Joey

-- 
Let's call it an accidental feature.  --Larry Wall

Please always Cc to me when replying to me on the lists.

Re: debian-security-announce-$lang@lists?

2002-08-14 Thread Martin Schulze 
Giuseppe Sacco wrote:
> We decided to translate from the english wml, so in order to start a
> translation we wait for the english published version. Is it the right
> way? In any case I will subscribe to debian-security-announce to get
> quicker translations.

That's the proper way.  However, due to a small delay in sending mail,
the advisories tend to hit the cvs archive a couple of minutes
*earlier* than the lists -- when I'm releasing the advisories, which
has happend for a while now.  There'll be an opposite delay when other
team members release the advisory, but it's normally only a couple of
hours maximum.  So basically, yes, it's the proper way.

Regards,

Joey

-- 
Let's call it an accidental feature.  --Larry Wall

Please always Cc to me when replying to me on the lists.

Re: debian-security-announce-$lang@lists?

2002-08-14 Thread Martin Schulze 
Giuseppe Sacco wrote:
> Il Tue, Aug 13, 2002 at 09:23:57PM +0200, Martin Schulze ha scritto:
> [...]
> > Currently, all DSAs are released via mail in english on
> > [EMAIL PROTECTED] and copied to www.debian.org
> > afterwards, where they will be picked up by seven[1] fellow translators
> 
> Just for the records. From this morning we also have Italian :-)

This exactly asserts my concern: There is only an Italian version of
DSA 149, while 150, 151 and 152 are still missing.

Regards,

Joey

-- 
Let's call it an accidental feature.  --Larry Wall

Please always Cc to me when replying to me on the lists.

debian-security-announce-$lang@lists?

2002-08-13 Thread Martin Schulze 
Hi,

what do other developers think about localized lists for security
advisories, such as [EMAIL PROTECTED]

Currently, all DSAs are released via mail in english on
[EMAIL PROTECTED] and copied to www.debian.org
afterwards, where they will be picked up by seven[1] fellow translators
who produce the text part in their native tongue.

This means that people who are interested in security, should
subscribe to the -announce list for immediate notification.  Those who
prefer an advisory in their native tongue will have to wait up to one
day to see the translation online.

Establishing localized -announce lists could impose an unacceptable
delay before the translated advisory gets posted to the localized
list.  This will probably be the case especially with long
advisories[2] or when translators are on their holidays or simply too
busy to maintain the translation properly[3] or if Debian releases a
couple of advisories on one day[4].

This could lead to a false assumtion that no vulnerabilities were
found and fixed, leaving a system  vulnerable longer than it would be
considered acceptable.

Given the above, what do you think about establishing localized
security-announce lists?  Please discuss this issue on debian-security
and not on debian-devel or debian-project to reach a larger audience.

Regards,

Joey

1. Danish, French, German, Japanese, Portuguese, Spanish and Swedish
2. See DSA 134 as a very bad example (Murphy...) or DSA 148
3. No harm intended, this happens to some people all the time (e.g. myself)
4. *cough* DSA 149, 150, 151 and 152 were released at the same day

-- 
Unix is user friendly ...  It's just picky about its friends.

Please always Cc to me when replying to me on the lists.

Re: [security] What's being done?

2002-01-13 Thread Martin Schulze 
Daniel Stone wrote:
> Considering that an upload hasn't been made to rectify this root hole,
> why hasn't something else been done about it - regular or security NMU?
> One would think that this is definitely serious.
> 
> Oh and BTW, Slackware released an update today. Without trolling, I can
> say that I was honestly surprised to note that Debian, a distro with
> ~850 developers and a dedicated security team, is behind Slackware on
> security issues.

Glibc always is a difficult problem.

 1. It takes ages to build packages and they need to be build on
currently six architectures (11 when woody is out).

 2. Glibc is the most important package.  If something in the security
update causes glibc to fail, imagine what will happen to all those
systems that just have updated their glibc due to a security
upload.  Even if they should manage to get their system working
again, it will take use *days* to provide fixed packages.

 3. Glibc is a beast that not many people want to deal with.  All
glibc problems I know of have been dealt by the Security Team
*together* with the glibc maintainer.  Both parties are busy
people as well.

 4. Supporting one or two architectures is way easier than supporting
six architectures.

 5. Because of that, we have to be extraordinary careful.  This takes
time.

Sorry for the inconvenience.  We are doing what we can.  Providing
patches and test reports are always welcome, but advisories for the
kernel and glibc will probably continue to take more time than usual.

Regards,

Joey

-- 
It's practically impossible to look at a penguin and feel angry.

Please always Cc to me when replying to me on the lists.

Re: [security] What's being done?

2002-01-13 Thread Martin Schulze 

Daniel Stone wrote:
> Considering that an upload hasn't been made to rectify this root hole,
> why hasn't something else been done about it - regular or security NMU?
> One would think that this is definitely serious.
> 
> Oh and BTW, Slackware released an update today. Without trolling, I can
> say that I was honestly surprised to note that Debian, a distro with
> ~850 developers and a dedicated security team, is behind Slackware on
> security issues.

Glibc always is a difficult problem.

 1. It takes ages to build packages and they need to be build on
currently six architectures (11 when woody is out).

 2. Glibc is the most important package.  If something in the security
update causes glibc to fail, imagine what will happen to all those
systems that just have updated their glibc due to a security
upload.  Even if they should manage to get their system working
again, it will take use *days* to provide fixed packages.

 3. Glibc is a beast that not many people want to deal with.  All
glibc problems I know of have been dealt by the Security Team
*together* with the glibc maintainer.  Both parties are busy
people as well.

 4. Supporting one or two architectures is way easier than supporting
six architectures.

 5. Because of that, we have to be extraordinary careful.  This takes
time.

Sorry for the inconvenience.  We are doing what we can.  Providing
patches and test reports are always welcome, but advisories for the
kernel and glibc will probably continue to take more time than usual.

Regards,

Joey

-- 
It's practically impossible to look at a penguin and feel angry.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions regarding the Security Secretary Position

2001-10-23 Thread Martin Schulze 
John Galt wrote:
> On Tue, 23 Oct 2001, Martin Schulze wrote:
> 
> >John Galt wrote:
> >> 
> >> It really didn't need to go to -devel in the first place: this is internal 
> >> to debian-security until there's a candidate. Folloups redirected.
> >
> >Err... you have noticed that there are already two people filling
> >this position, haven't you?
> 
> An since the candidate wasn't announced on -devel, once can only assume 

I'm sorry, but things are announced to -devel-announce, -news or
-announce.  If you don't follow these lists, I'm sorry...

Regards,

Joey

-- 
This is Linux Country.  On a quiet night, you can hear Windows reboot.

Please always Cc to me when replying to me on the lists.

Re: Questions regarding the Security Secretary Position

2001-10-23 Thread Martin Schulze 
John Galt wrote:
> 
> It really didn't need to go to -devel in the first place: this is internal 
> to debian-security until there's a candidate. Folloups redirected.

Err... you have noticed that there are already two people filling
this position, haven't you?

Regards,

Joey

-- 
This is Linux Country.  On a quiet night, you can hear Windows reboot.

Please always Cc to me when replying to me on the lists.

Re: Questions regarding the Security Secretary Position

2001-10-22 Thread Martin Schulze 

John Galt wrote:
> On Tue, 23 Oct 2001, Martin Schulze wrote:
> 
> >John Galt wrote:
> >> 
> >> It really didn't need to go to -devel in the first place: this is internal 
> >> to debian-security until there's a candidate. Folloups redirected.
> >
> >Err... you have noticed that there are already two people filling
> >this position, haven't you?
> 
> An since the candidate wasn't announced on -devel, once can only assume 

I'm sorry, but things are announced to -devel-announce, -news or
-announce.  If you don't follow these lists, I'm sorry...

Regards,

Joey

-- 
This is Linux Country.  On a quiet night, you can hear Windows reboot.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Questions regarding the Security Secretary Position

2001-10-22 Thread Martin Schulze 

John Galt wrote:
> 
> It really didn't need to go to -devel in the first place: this is internal 
> to debian-security until there's a candidate. Folloups redirected.

Err... you have noticed that there are already two people filling
this position, haven't you?

Regards,

Joey

-- 
This is Linux Country.  On a quiet night, you can hear Windows reboot.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Questions regarding the Security Secretary Position

2001-09-24 Thread Martin Schulze 
I'm awfully sorry for the delay, but I wasn't able to work on this
earlier again.

Here's a list of questions and answers that came up with the posting I
made last week.

Q: Is a requirement being a Debian developer?

   No.  It is my understanding that it would be good to have "fresh
   blood" in the team.  Working on security can cost a lot of time,
   thus it could even be helpful not being a Debian developer since
   that implies active package maintenance as well.  However, similar
   knowledge is very helpful, and may be required when working on
   issues.

Q: How much time is required to fill the position?

   That's something I don't know.  When I started with Debian
   Security, it was easy to do, there were two architectures, about
   1000 packages and not too many security incidents reported.

   This has changed.  We're at some 5000 packages, often there are
   more than two security incidents reported per week which we'll have
   to investigate, and there are six released architectures, probably
   12 for the next release.

   I can imagine that this job requires about 10-20 hours per week.
   However, it's possible that there are a couple of weeks where no
   work is to be done.  One has to expect that this position requires
   a lot of time.

Q: Are you open to finding a small (2-3 person) team to fill this role?

   Yes, I am open to this idea.  This would be based on my practise of
   forming a team in order to make it less dependant of one person
   (see listmaster, debian-admin, security etc.).

   However, the more people are involved, the more coordination has to
   be done.  On the other side, security is crucial and we should do
   anything that can improve the situation.

Q: How will the person/team come up to speed?

   I can't parse the question.

   In my announcement I wrote several tasks that this person/team
   would have to work on.  I forgot documentation thouth.  Please see
   

Q: What are the personal requirements?

   At least one of the secretary team needs to be able to code in C
   and understand Debian packaging as well as security incidents.  It
   would be useless if the person won't understand how an exploit
   works.

   If more than one person is going to fill this position than a
   second person could specialize on tracking problems and
   documentation while the first person works on details, programming
   and fixing.

   A lot of spare time is required as well.

Q: What is the method you will choose this person?

   The current Debian Security Team will discuss volunteers and
   appoint 1-3 persons.

Regards,

Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book


pgp5DCnWOOiUv.pgp
Description: PGP signature

Questions regarding the Security Secretary Position

2001-09-24 Thread Martin Schulze 

I'm awfully sorry for the delay, but I wasn't able to work on this
earlier again.

Here's a list of questions and answers that came up with the posting I
made last week.

Q: Is a requirement being a Debian developer?

   No.  It is my understanding that it would be good to have "fresh
   blood" in the team.  Working on security can cost a lot of time,
   thus it could even be helpful not being a Debian developer since
   that implies active package maintenance as well.  However, similar
   knowledge is very helpful, and may be required when working on
   issues.

Q: How much time is required to fill the position?

   That's something I don't know.  When I started with Debian
   Security, it was easy to do, there were two architectures, about
   1000 packages and not too many security incidents reported.

   This has changed.  We're at some 5000 packages, often there are
   more than two security incidents reported per week which we'll have
   to investigate, and there are six released architectures, probably
   12 for the next release.

   I can imagine that this job requires about 10-20 hours per week.
   However, it's possible that there are a couple of weeks where no
   work is to be done.  One has to expect that this position requires
   a lot of time.

Q: Are you open to finding a small (2-3 person) team to fill this role?

   Yes, I am open to this idea.  This would be based on my practise of
   forming a team in order to make it less dependant of one person
   (see listmaster, debian-admin, security etc.).

   However, the more people are involved, the more coordination has to
   be done.  On the other side, security is crucial and we should do
   anything that can improve the situation.

Q: How will the person/team come up to speed?

   I can't parse the question.

   In my announcement I wrote several tasks that this person/team
   would have to work on.  I forgot documentation thouth.  Please see
   

Q: What are the personal requirements?

   At least one of the secretary team needs to be able to code in C
   and understand Debian packaging as well as security incidents.  It
   would be useless if the person won't understand how an exploit
   works.

   If more than one person is going to fill this position than a
   second person could specialize on tracking problems and
   documentation while the first person works on details, programming
   and fixing.

   A lot of spare time is required as well.

Q: What is the method you will choose this person?

   The current Debian Security Team will discuss volunteers and
   appoint 1-3 persons.

Regards,

Joey

-- 
No question is too silly to ask, but, of course, some are too silly
to answer.   -- Perl book

 PGP signature

Seeking for a Debian Security Secretary

2001-09-17 Thread Martin Schulze 
Current problems with Debian Security have led me into reconsidering
this issue which I thought about one year ago or so.  Debian Security
is very crucial to our users and thus should be managed properly.

To help improve the situation I'm offering a very important job within
the Debian project.  I'd like to have somebody who will help the core
Debian Security Team doing their work.  This seems to be required
since all members of the Security Team have other important things to
do and still don't know how to fork(2) themselves.

This position requires:

 . Discussing security problems with the Security Team, as well as
   with third parties.

 . Notifying the Security Team of incidents they haven't noticed
   already.

 . Maintaining an internal list of security incidents, both resolved
   and unresolved.

 . Reminding members of the Debian Security Team until they release an
   advisory or decide that Debian is not vulnerable to a particular
   problem.[1]

 . Ensure that not only packages in stable but also in the unstable
   distribution contain security fixes.  This implies continuesly
   kindly reminding package maintainers, eventually also preparing
   releases or NMUs for unstable with help of the QA or Security Team.

 . Extract security patches from other vendors' security fixes for
   further investigation by the the Security Secretary or the Debian
   Security Team.

 . Preparing security patches together with the Debian Security Team.

This is done by:

 . Reading and understanding bugtraq.

 . Monitoring[2] others distributions security advisories (at least
   Immunix, Trustix, EnGarde, Caldera, RedHat, SuSE, Mandrake and
   Conectiva, the more the better).  This should be done by
   subscribing to other vendors security lists.

 . Reading and understanding mail on the private list of the Debian
   Security Team.

Explanations:

[1] From time to time the Security Team forgets about security issues.
It is very time-consuming doing research for old issues, but it
has to be done.

[2] This could help http://www.infodrom.ffis.de/Linux/security/, but
it is also not complete enough.

Regards,

Joey

-- 
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum


pgp4N2xrmRa2V.pgp
Description: PGP signature

Seeking for a Debian Security Secretary

2001-09-17 Thread Martin Schulze 

Current problems with Debian Security have led me into reconsidering
this issue which I thought about one year ago or so.  Debian Security
is very crucial to our users and thus should be managed properly.

To help improve the situation I'm offering a very important job within
the Debian project.  I'd like to have somebody who will help the core
Debian Security Team doing their work.  This seems to be required
since all members of the Security Team have other important things to
do and still don't know how to fork(2) themselves.

This position requires:

 . Discussing security problems with the Security Team, as well as
   with third parties.

 . Notifying the Security Team of incidents they haven't noticed
   already.

 . Maintaining an internal list of security incidents, both resolved
   and unresolved.

 . Reminding members of the Debian Security Team until they release an
   advisory or decide that Debian is not vulnerable to a particular
   problem.[1]

 . Ensure that not only packages in stable but also in the unstable
   distribution contain security fixes.  This implies continuesly
   kindly reminding package maintainers, eventually also preparing
   releases or NMUs for unstable with help of the QA or Security Team.

 . Extract security patches from other vendors' security fixes for
   further investigation by the the Security Secretary or the Debian
   Security Team.

 . Preparing security patches together with the Debian Security Team.

This is done by:

 . Reading and understanding bugtraq.

 . Monitoring[2] others distributions security advisories (at least
   Immunix, Trustix, EnGarde, Caldera, RedHat, SuSE, Mandrake and
   Conectiva, the more the better).  This should be done by
   subscribing to other vendors security lists.

 . Reading and understanding mail on the private list of the Debian
   Security Team.

Explanations:

[1] From time to time the Security Team forgets about security issues.
It is very time-consuming doing research for old issues, but it
has to be done.

[2] This could help http://www.infodrom.ffis.de/Linux/security/, but
it is also not complete enough.

Regards,

Joey

-- 
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum

 PGP signature

Re: mirroring security.debian.org?

2001-01-25 Thread Martin Schulze 
Noah L. Meyerhans wrote:
> I wish to mirror security.debian.org using rsync, but I can't find any
> documentation on rsync sources or other mirrors.  It's not mentioned on

Please don't do that.  Security updates should come *only* from
security.debian.org.  This was discussed a while, you should be
able to find some blurb about it in the debian-devel archive, I
guess.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.

Re: mirroring security.debian.org?

2001-01-25 Thread Martin Schulze 

Noah L. Meyerhans wrote:
> I wish to mirror security.debian.org using rsync, but I can't find any
> documentation on rsync sources or other mirrors.  It's not mentioned on

Please don't do that.  Security updates should come *only* from
security.debian.org.  This was discussed a while, you should be
able to find some blurb about it in the debian-devel archive, I
guess.

Regards,

Joey

-- 
A mathematician is a machine for converting coffee into theorems.


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Good Book

2000-01-18 Thread Martin Schulze 
Nick Jennings wrote:
> Hello,
> 
>   Can anyone on the list recommend a good book, online or in paper
> form, that goes in depth on Linux Security? Prevention & Detection etc.

O'Reilly has tha Locker book, Unix Security and stuff, check it out.

Regards,

Joey

-- 
Computers are not intelligent.  They only think they are.

Re: debian-security: another new mailing list

1999-10-30 Thread Martin Schulze 
Wichert Akkerman wrote:
> Previously Keith Harbaugh wrote:
> > This is to announce the establishment of a new debian mailing list:
> > 
> > debian-security,
> > 
> > for the discussion of all aspects of security
> > significant to the Debian system, including cryptography.
> 
> How can it happen that this list was made without the security team
> even hearing a rumour about it???

Err, this is a very good question!  Additionally, how can the
security team not be subscribed?

Wondering,

Joey

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Please always Cc to me when replying to me on the lists.