Re: [SECURITY] [DSA 479-1] New Linux 2.4.18 packages fix local root exploit (source+alpha+i386+powerpc)

"David R" <[EMAIL PROTECTED]> writes: > What do I do? Do I use apt-get remove to get rid of the patched kernel? Do I > do something else? You could look at /var/cache/apt/archives and see if there is an old version of the kernel package. Try to install it using "dpkg -i". -- Current mail filte

Re: Major TCP Vulnerability

Phillip Hofmeister <[EMAIL PROTECTED]> writes: > This article isn't anything I am going to loose sleep over. Any mission > critical long term TCP connections over an untrusted network (The > Internet) should already be using IPSec. Core routers usually don't have the CPU power to run IPsec (yes,

Re: Major TCP Vulnerability

Greg Folkert <[EMAIL PROTECTED]> writes: > This Vulnerability is ancient news, and it is not really a > Vulnerability. It's one instance of a more general set of vulnerabilities which stem from the lack of control plane separation. > What happens if the route goes dead? Same effect. Not quite.

Re: Large, constant incoming traffic

* Kjetil Kjernsmo: > Oh, I see. But one thing I do not understand, it doesn't seem like this > traffic is directed at me, since it's not my address that's the > destination...? Are they routing their traffic through me or something? It's some odd switch-router whose forwarding table is overflo

Re: apt-get update

> Is ftp2.de.debian.org down The server seems to have some problems. It's not something at your end, I'd guess. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, s

Re: [OT] Trojan/[spy/ad]ware and thawte.com

* Vincent Deffontaines: > 1) What are those .crl files used for? These are Certificate Revocation Lists. They are essential for the operation of a PKI, especially a global one with lose registration checks. > Maybe they could be used to "corrupt" actual browser's certs? There whole purpose is

[EMAIL PROTECTED]

Has [EMAIL PROTECTED] been directed away from debian-private? It's probably a good move. In the past, the old setup resulted in some confusion because submitters usually do not expect that security@ is read by all people in the organization. 8-) I can't find any documentation for that change. D

Re: Unusual spam recently

* David Stanaway: > Has anyone else been receiving unusual spam recently which contains no > content? Yes, I've seen it, too. > Is this some spam engine checking MTAs to see if the addresses are > accepted? Looks like a mass-mailer bug to me. -- Current mail filters: many dial-up/DSL/cable mo

Re: Strange bind error

* Emmanuel Lacour: > For the first time I saw those curious errors. I don't understand where > is the error, in my bind or in the remote client/server?? > > Any idea? > > Apr 21 22:00:50 volubilis named[12517]: socket.c:1100: unexpected error: > Apr 21 22:00:50 volubilis named[12517]: internal_sen

Re: Sudo question

* Johann Spies: > alias specification Cmnd_Alias BACKUP = > /opt/tivoli/tsm/client/ba/bin/dsm, \ > /opt/tivoli/tsm/client/ba/bin/dsmadmc, \ > /opt/tivoli/tsm/client/ba/bin/dsmc, \ > /opt/tivoli/tsm/client/ba/bin/dsmagent,\ > /opt/tivoli/tsm/client/ba/bin/dsmcad,\ > /opt/tivoli/tsm/client/ba/bin/ds

Addressing the recent zlib issue

On my system, the following packages contain statically linked copies of zlib-related code: dpkg (zlib version 1.2.2) various kernel images (zlib version 1.1.3) monotone (probably an independent reimplementation of the algorithm) mozilla-browser (zlib version 1.1.4) openoffice.org-bin (z

Re: Addressing the recent zlib issue

* Javier Fernández-Sanguino Peña: > On Sun, Jul 10, 2005 at 03:59:43PM +0200, Florian Weimer wrote: >> Is anybody looking at this problem in a systematic manner, or should I >> just file bugs on the more likely candidates for a security update >> (dpkg and zysnc, based

Re: [SECURITY] [DSA 751-1] New squid packages fix IP spoofing vulnerability

* Martin Schulze: > The upstream developers have discovered a bug in the DNS lookup code > of Squid, the popular WWW proxy cache. When the DNS client UDP port > (assigned by the operating system at startup) is unfiltered and the > network is not protected from IP spoofing, malicious users can spo

Re: Security risks due to packages that are no longer part of Debian?

* Christian Hammers: > If a User upgrades his woody system to sarge and one package that has > been part of woody is now no longer part of Debian nor being superseded by > another package, will apt-get warn the user that this package is a potential > security risk as Debian does not monitor nor pr

Re: Security risks due to packages that are no longer part of Debian?

* Sam Morris: > You can use aptitude to discover obsolete packages on your system. See > > > for more info. Interesting feature. It doesn't work too well on unstable because of the C++ transition, but f

Re: Addressing the recent zlib issue

* Florian Weimer: > Is anybody looking at this problem in a systematic manner, or should I > just file bugs on the more likely candidates for a security update > (dpkg and zysnc, based on the list above and assuming that 1.1 is > indeed not affected). In the meantime, I'

Re: Addressing the recent zlib issue

* Javier Fernández-Sanguino Peña: > On Sun, Jul 10, 2005 at 03:59:43PM +0200, Florian Weimer wrote: >> Is anybody looking at this problem in a systematic manner, or should I >> just file bugs on the more likely candidates for a security update >> (dpkg and zysnc, based

Re: Addressing the recent zlib issue

* Mark Brown: >> If you've got a reasonable complete copy of the Debian package pool >> and you are willing to run Clamav across it, please respond to this >> message. > > Oh, I was actually just working on some other approaches to checking for > people doing this sort of stuff and right now I've

Re: Addressing the recent zlib issue

* Mark Brown: > On Tue, Jul 12, 2005 at 06:40:55PM +0200, Florian Weimer wrote: > >> operations. Unfortunately, we have to check all architectures >> individually because spurious buildd configuration changes might >> trigger static linking of zlib. > > Yes, althou

Re: Security risks due to packages that are no longer part of Debian?

* Bob Proulx: > Florian Weimer wrote: >> A tool which lists all packages which are no longer downloadable from >> any APT source would be more helpful, I think. Does it already exist? > > Does apt-show-versions do what you want? > > apt-show-versions | grep '

zlib status (CAN-2005-2096)

As far as I know, we currently have the following set of bugs related to the recent zlib vulnerability: 309196 rageircd (proactively filed, reused for CAN-2005-2096) 317523 aide 317966 dump 317967 dpkg 317968 zsync 317970 amd64-libs (private copy of DSO)

Document the bug fix policy regarding PHP Safe Mode

Please review the attached document, which explains Debian's policy on bugs in PHP Safe Mode. Feel free to share your thoughts. To my knowledge, this document only reflects the existing practice. This document is relevant because it is the "fix" for #318063. (debian-www Cc:ed; I don't know who a

Re: Included/staticly linked libraries in source packages:

* Kurt Roeckx: > Hi Florian, > > Thanks for doing all of this, since it was rather manual work for me. > > Afaik, there are 3 kind of problems with zlib: > - It's build-depending zlib, but linking staticly > - It has it's own copy of zlib, and links staticly to it > - It has it's own copy of the z

Re: Document the bug fix policy regarding PHP Safe Mode

* Andreas Gredler: > On Wed, Jul 13, 2005 at 08:31:25PM +0200, Florian Weimer wrote: > >> Alternatives >> >> Most large ISPs who run customer PHP scripts on shared hosting >> servers do not use mod_php (or other forms of direct >> integration into a web ser

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

* Herwig Wittmann: > I do not want to rude in any way- please try to excuse my way of > putting things, but does anybody have a prediction how probable it > is for such a thing to happen again? Delays in the order of weeks are pretty standard, and not always they are caused by embargoes. It's a

Re: WG: critical bug in cacti

* Gunther Stammwitz: > No answer yet... Does anyone know what's going on at the security > team? You should report publicly documented security issues to the Bug Tracking System (with a "security" tag), and not directly to the security team. The BTS is read by more people, and the actual package

Re: Security updates fro non-US

* Jarosław Tabor: > First of all thank you for help with debian security mirroring. Now I > have aditional question: where are security updates for non-US ? non-US should be (mostly) empty by now. Could you tell us which package you are interested in?

Re: Security updates for non-US

> Can confirm, that if there will be something in non-US, I will find it > on security.debian.org ? non-US has been discontinued in sarge: http://www.debian.org/releases/stable/i386/release-notes/ch-whats-new.en.html#s-non-us Therefore, security updates for packages in non-US are not necessary.

Old security bugs tagged woody

Many developers close security bugs which are tagged woody only, even though security support for oldstable has not been discontinued officially. How shall we bridge the apparent gap between documented policy and existing practice? Given our resources, I'd say fix the policy. Any objections? -

Re: Document the bug fix policy regarding PHP Safe Mode

* MJ Ray: > Florian Weimer <[EMAIL PROTECTED]> wrote: >> This decision is based on the on two observations: Most PHP users >> are small-scale users, not service providers. As a result, they do >> not have to deal with the challenge of multiple users who need to >&g

Re: Security fixes for mozilla and firefox in Sarge?

* Holger Mense: > the latest upload of mozilla in sarge is from friday, 13th of May. The > latest upload of firefox in sarge is from monday, 16th of May. Since then > several security issues were found in both programms. The issues in > firefox were fixed by upload of a new firefox release in unst

Re: On Mozilla-* updates

* Martin Schulze: > 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) This is very unfortunate and happened much sooner than expect

Re: On Mozilla-* updates

* Geoff Crompton: >> >> For these packages, help and/or advice is appreciated. >> > > Can we try to get a DD involved in the mozilla security team? Some of the Mozilla bugs come from deep design issues in the code. Even if you know all the details, backporting might still be infeasible. What's

Re: On Mozilla-* updates

* Geoff Crompton: >> >> For these packages, help and/or advice is appreciated. >> > > Can we try to get a DD involved in the mozilla security team? Presumably > when they become aware of a security issue, there is some discussion > about the problem and how to fix it. Access at this level may ma

Re: Bad press again...

* martin f. krafft: > I think Alvin was alluding to how it *should* be solved. As in: we > should have more than one security server, globally spaced. security.debian.org already is a Single Point of Ownership. I don't think we need multiple ones, so this is definitely a post-etch thing. -- T

Re: Bad press again...

* W. Borgert: > Do we have a security team for stable? I know, that we have a > security team for testing consisting of nine DDs and ten > non-DDs, but it seems to me, that stable is handled by Joey > alone. Has this changed since the havoc a few months ago? I don't think so. Joey seems to be

Re: Bad press again...

* Henrique de Moraes Holschuh: > On Sat, 27 Aug 2005, Florian Weimer wrote: >> I don't think so. Joey seems to be satisfied with this situation, and >> apart from unanswered email messages to <[EMAIL PROTECTED]>, there >> are few complaints, AFAIK. The email

Re: Bad press again...

* Petter Reinholdtsen: > The count of open security issues in stable and oldstable is probably > a better measuring meter, and it does not look too good. Security support is a task for Debian as a whole, not just the security team. IMHO, the main role of the security team is information sharing,

Re: Bad press again...

* Henrique de Moraes Holschuh: > On Sat, 27 Aug 2005, Florian Weimer wrote: >> * martin f. krafft: >> > I think Alvin was alluding to how it *should* be solved. As in: we >> > should have more than one security server, globally spaced. >> >> security.

Re: Bad press again...

* martin f. krafft: > FWIW, Florian sent me this interesting link: > http://www.cs.berkeley.edu/~nweaver/0wn2.html This is was only intended as an explanation of the term "single point of ownership". I don't agree with Nicholas Weaver's analysis. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED

Re: Bad press again...

* martin f. krafft: > also sprach Henrique de Moraes Holschuh <[EMAIL PROTECTED]> [2005.08.27.1540 > +0200]: >> > security.debian.org already is a Single Point of Ownership. I don't >> > think we need multiple ones, so this is definitely a post-etch thing. >> >> Irrelevant if secure apt is depl

Re: Bad press again...

* martin f. krafft: >> I don't think so. Joey seems to be satisfied with this situation, > > How would you know? Joey doesn't ignore all mail, only some of it. > That's because complaints don't actually have any result, so I, for > instance, have stopped. I've pointed to severe problems with De

Re: Bad press again...

* Petter Reinholdtsen: > [Florian Weimer] >> Correct me if I'm wrong, but the current team doesn't seem to want >> new members. > > I've been told that the current stable security team consist of one > person doing the work, Martin Schulze. If this &quo

Re: Bad press again...

* martin f. krafft: > also sprach Florian Weimer <[EMAIL PROTECTED]> [2005.08.28.1154 +0200]: >> Or are there many packages with backported security patches, ready >> for upload, and the security team does not act on them? I don't >> think so. > > This was

Re: Bad press again...

* Paul Gear: > There certainly have been exceptions to that rule. The maintainer of > shorewall has been trying for weeks to get a DSA issued about a > vulnerability, and it seems we have to convince Joey that it *is* a > vulnerability before he'll issue it. Is this #318946? This one is tagge

Re: Bad press again...

* Paul Gear: >>>There certainly have been exceptions to that rule. The maintainer of >>>shorewall has been trying for weeks to get a DSA issued about a >>>vulnerability, and it seems we have to convince Joey that it *is* a >>>vulnerability before he'll issue it. >> >> >> Is this #318946? > >

Re: Bad press again...

* Paul Gear: > I don't know upon what you're basing your characterization, but i'm > party to at least 3 emails to Joey describing the nature of the bug > in sufficient detail to understand it as a security flaw. Was this pre- or post-disclosure? In the latter case, such discussion should be Cc:

Re: Bad press again...

* Branden Robinson: > 2) I bring the Debian Security Team under delegation[2]. Martin Michlmayr has made the security team a delegate by this message: Have you withdrawn this delegation in the meantime? AIUI, DPL elections d

Re: Bad press again...

* Frans Pop: > On Monday 29 August 2005 20:13, Florian Weimer wrote: >> Martin Michlmayr has made the security team a delegate by this >> message: >> <http://lists.debian.org/debian-devel-announce/2003/05/msg5.html> > > Huh? I read no formal delegation in t

Re: Bad press again...

* Frans Pop: > On Monday 29 August 2005 21:40, Florian Weimer wrote: >> > I see no "(as DPL) I appoint" or "I delegate" in that mail. >> >> This is not necessary. > > I'm sorry, but I still think you're doing creative reading. There is o

Re: Bad press again...

* Paul Gear: >> In the latter case, such discussion should be Cc:ed to the bug >> report, IMHO. > > Is that a policy issue, common convention, or just a suggestion? It's a suggestion ("IMHO"). I would like to see it as a common convention. I think there are many little things which should be do

Re: Bad press again...

* Paul Gear: > If we're going to have another crack at it, then, what track should we > take? Reopen the bug as Florian suggested, According to a recent discussion on -devel, this bug is still open. The BTS web is a bit confusing. > email the security team, just keep pestering Joey? IMHO, the

Re: Bad press again...

* Michael Stone: > Contact the security team. Describe the bug in such a way that the > security team understands its severity and impact. It is not sufficient > to say "just trust me and issue an advisory". From what I've seen so far > this is not the obvious buffer overflow sort of bug, it's a c

Re: Bad press again...

* Steve Wray: > Another example is fwbuilder which *silently* fails to overwrite its > generated script at compile time if the user doesn't have write > permissions on the existing script. Most bugs in security tools are security bugs. We have to draw a line somewhere, otherwise "stable" becomes

Re: Bad press again...

* Michael Stone: > On Mon, Aug 29, 2005 at 11:44:59PM +0200, Florian Weimer wrote: >>IMHO, Debian should publish at least a DSA that explains this >>discrepancy, especially if the package maintainer also thinks that >>it's necessary. > > Thank you for your

Re: Bad press again...

* Steve Wray: >>>I view this as a security problem because what if you *think* you've >>>made changes to your firewall and are now protected only... you arn't >>>and the firewall hasn't been updated? >>> >>>Is that enough of a security problem for the fix to get into stable? >> >> >> The underly

Re: Bad press again...

* Paul Gear: > The maintainer is not the problem. Lorenzo has prepared 2.2.3-2 for > sarge [1] and has tested the before and after situations and found that > the bug is fixed. The problem is no response from Martin Schulze. > > [1] http://idea.sec.dico.unimi.it/~lorenzo/tmp/ This information s

Re: Bad press again...

* Paul Gear: > Florian Weimer wrote: >> ... >> It seems that shorewall generates an ACL that ACCEPTs all traffic once >> a MAC rule matches. Further rules are not considered. The >> explanations in version 2.2.3 seem to indicate that this was the >> intend

Re: Bad press again...

* Michael Stone: > On Tue, Aug 30, 2005 at 12:17:22AM +0200, Florian Weimer wrote: >>I think this part of the diff is pretty instructive, together with >>upstream's explanation: > > Frankly, no, it's not. > >> if [ -n "$MACLIST_TTL" ]; the

Re: open_basedir bug also not fixed?

> as described in [1], safemode bugs are not fixed in debian mod_php. The document you quoted is unofficial. As far as I know, it matches existing practice (which is not official documented, unfortunately). I think it would make sense to include a reference to open_basedir in that documented, sh

Re: Bad press again...

* Paul Gear: > It makes perfect sense to me... All it's saying is that IP-to-MAC > mappings are cached in the 'Recent' set for each interface for > $MACLIST_TTL seconds without requiring them to be passed through the MAC > filter for every packet. The problem is this sentence: "Subsequent connec

Re: [SECURITY] [DSA 794-1] New polygen packages fix denial of service

* Martin Schulze: > Debian-specific: no Shouldn't this be "yes"? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Abwesenheit

> Is there a reason not to simply read the "Precedence: list" header > and simply not respond at all ? "Precedence: list" is non-standard. Technically speaking, RFC-compliant software should not use it. 8-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble?

Re: Abwesenheit

* Peter Palfrader: > On Mon, 19 Sep 2005, Florian Weimer wrote: > >> > Is there a reason not to simply read the "Precedence: list" header >> > and simply not respond at all ? >> >> "Precedence: list" is non-standard. Technically

Re: security.debian.org timeouts

* Steve Kemp: > On Mon, Sep 19, 2005 at 09:18:29PM +0200, No?l K?the wrote: > >> anybody knows what's the problem with klecker/security.d.o? > > http://lists.debian.org/debian-curiosa/2005/09/msg00018.html The MRTG output is broken (as suggested by the straight line). Real port utilization

Re: security.debian.org timeouts

* Michael Stone: > The current problem isn't a bandwidth problem, but it is related to > people downloading the X update. The available bandwidth is not sufficient for dealing with an X11 update, at least in the usual way (pushing everything that's built by the source packages, and not just the v

Re: JCE Code Signing Certificate

* Charles Fry: > I should also point out that this JCE Code Signing Certificate is > necessary not only to allow libbcprov-java to be used as a trusted > security provider, but also for me to package bcmail, bctsp, and bcpg > which are also part of Bouncy Castle. I can currently build all of them,

Re: JCE Code Signing Certificate

* Charles Fry: > Well, I may not entirely understand your question, but here is my > understanding of the situation, as supported by the document How to > Implement a Provider for the JavaTM Cryptography Extension[1]. Unfortunately, this document doesn't explain why the certificate is needed. >

Re: JCE Code Signing Certificate

* Michael Koch: > This is a big field which needs even bigger investigation. The free > runtimes can load them but signed jars are still not supported (or was > this fixed lately...). Your best action would be to just test it with > kaffe or gcj or whatever and report any bugs you find. In the me

Re: JCE Code Signing Certificate

* Charles Fry: >> In the meantime, it occurred to me that the certified key (including >> the private key) would have to be included in the source package, >> otherwise the package would fail to build from source. >> >> While I see nothing in Sun's form that requires us to keep the private >> key

Re: [SECURITY] [DSA 871-1] New libgda2 packages fix arbitrary code execution

* Martin Schulze: > For the unstable distribution (sid) these problems will be fixed soon. According to the libgda2 changelog, CAN-2005-2958 has already been fixed in version 1.2.2-1. (I hope this data is correct.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe".

Re: CAN to CVE: changing changelogs?

* Thijs Kinkhorst: >> You could change them retroactively (with a little note that you did so), >> but it's not strictly necessary, as MITRE will continue to provide referrals >> from CAN-based entries to CVE-based entries. > > Wouldn't one of the goals of the change to just one name instead of tw

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

* Steve Kemp: > However a useful response such as "Yes we've got your package report > and we'll update an advisory after we've done openssh, mozilla, the > kernel." is not going to happen. The web pages state that you aim for a fix within 48 hours. Maybe this sentence should be removed? Se

Re: [SECURITY] [DSA 875-1] New OpenSSL packages fix cryptographic weakness

> I have read the CVE advisory, why is DSA 875-1 only about openssl094? > Will there be other DSAs? I am asking because it seems strange to me > that Woody is already fixed but other, more important systems (the > current stable for example) will have to wait. Typically, one DSA is issued for each

Re: clamav and magic byte

* Geoff Crompton: > Anyone know if clamav is vulnerable to the magic byte detection evasion > issue discussed at http://www.securityfocus.com/bid/15189? > > Or alternatively, can anyone work out if it is vulnerable? It is vulnerable only in the sense that it doesn't detect viruses for which there

Re: clamav and magic byte

* Andrey Bayora: >> "...Andrey Bayora just describes one way to create new viruses, there are > countless others." > > Please, read http://www.securityelf.org/magicbyteadv.html - there > are 13 CVE numbers issued for this BUG. Often, CVE numbers are assigned because vendors release updates, not t

Re: clamav and magic byte

* Andrey Bayora: > OK, last try to convince you... :) > >> It's not a bug, it's a design property of such ssystems > > In other words: it is a design error (feature). Sure, if you want to put it that way. > As I point out my whitepaper, the "changed" viruses STILL detected with the > SAME signat

What is a security bug?

It seems that I have difficulty understanding what constitutes a security bug in a web browser. Suppose that the web browser always crashes when confronted with certain input, losing all of its state. With tabbed browsing, multiple browser opened by the same process etc., this means that potentia

Re: What is a security bug?

* Jasper Filon: > Well, obviously it is not a _security_ bug, since it has nothing to do > with security. Availability is typically considered one aspect of security (and arguably the hardest one to get right in networked applications). For example, here's a quote from FIPS 199: | Security Obje

Re: What is a security bug?

* Noah Meyerhans: > On Wed, Nov 23, 2005 at 12:59:02PM +0100, Florian Weimer wrote: >> Availability is typically considered one aspect of security (and >> arguably the hardest one to get right in networked applications). > > I tend to consider it the other way around. Se

Re: What is a security bug?

* Thomas Bushnell: > Florian Weimer <[EMAIL PROTECTED]> writes: > >> Suppose that the web browser always crashes when confronted with >> certain input, losing all of its state. With tabbed browsing, >> multiple browser opened by the same process etc., this means

Re: What is a security bug?

* Michelle Konzack: > If you allow to run apps as different user on the > same desktop, you pick security holes in your system. In theory, the X security extension could prevent that. However, I have doubts that it offers significant protection because it is not really on the radar screen (even

Re: What is a security bug?

* Jochen Striepe: > Hi, > > On 28 Nov 2005, Michelle Konzack wrote: >> If you allow to run apps as different user on the >> same desktop, you pick security holes in your system. > > Please explain that, I don't understand at all. Trusted X applications ("trusted" in the sense that they are no

Re: closing unwanted ports - and what is 1720/tcp filtered H.323/Q.931

* Noah Meyerhans: >> what is >> 1720/tcp filtered H.323/Q.931 >> ? >> >> and how do i turn it off if it is uneccessary. > > It may be nothing. The fact that it showed up as filterd in the nmap > output indicates that nmap didn't received a TCP RST packet back when it > tried to contact that por

Re: [SECURITY] [DSA 922-1] New Linux 2.6.8 packages fix several vulnerabilities

* Johann Glaser: > Do you know if these vulnerabilities are resolved in the current > linux-source-2.6.12-10? If you use kernel packages derived from the linux-2.6 source package, you can use debsecan to list known kernel vulnerabilities. debsecan is part of unstable (make sure you get version 0

Re: question on having . as LOAD_PATH (ruby)

* Junichi Uekawa: > Hi perl and pyhton people, > > Sorry for the crosspost; contrary to what's said in perl-policy and > python-policy, '.' seems to be included in module search-path. I find > it uneasy considering we have quite a few tools running as root. Is > this intentional or unintentional?

Re: [SECURITY] [DSA 930-1] New smstools packages fix format string vulnerability

* Thijs Kinkhorst: > It's great to hear that unstable will be fixed soon, but why wasn't > there a grave bug filed against the package? If for some reason the > maintainer misses this DSA, it is lateron unknown that the version in > unstable is vulnerable and still needs to be fixed... Uhm, th

Re: [SECURITY] [DSA 930-1] New smstools packages fix format string vulnerability

* Steve Kemp: > Testing will get the fix shortly via the package migration, How? By downgrading the smstools package? (etch and sid are at the same version.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 938-1] New koffice packages fix arbitrary code execution

* Martin Schulze: > CVE IDs: [...] CVE-2005-3193 [...] The sarge diff does not fix this problem. Since I can't find a trace of the affected code in xpdf, it's probably just the reference which is wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Tro

Re: [SECURITY] [DSA 945-1] New antiword packages fix insecure temporary file creation

* Martin Schulze: > For the stable distribution (sarge) these problems have been fixed in > version 0.35-2sarge1. I would have expected a version like 0.35-1sarge1. The version you have chosen violated an implicit constraint fulfilled by most (all?) security updates: the version of a package upd

Re: [SECURITY] [DSA 945-1] New antiword packages fix insecure temporary file creation

* Jeroen van Wolffelaar: > It's weird that antiword's security update was seeminly[1] based on the > testing version, rather than the stable version: > > antiword | 0.35-1 |stable | source > antiword | 0.35-2 | testing | source > [1] Looking exclusively at the version nu

Re: Security implications of tty group?

* Thomas Hood: > Hello, security experts. > > In #349578 it is claimed that the mesg program should not warn if a tty > device node fails to belong to group "tty". > > What are the security implications of a tty device node failing to belong > to group "tty"? "mesg y" does not have the desired ef

Re: Security implications of tty group?

* Thomas Hood: > Florian Weimer wrote: >> In other words, the warning makes perfect sense. > > > Would it also be secure if (as the submitter of #349578 writes): This hasn't got to do much with security. >> The tty is /dev/pts/* and is always owned and group-owned

Re: [SECURITY] [DSA 952-1] New libapache-auth-ldap packages fix arbitrary code execution

* Nick Boyce: >>From this I infer that mod_auth_ldap for Debian-packaged Apache 2 must > be included with the main Debian Apache packages, and that no > libapache(2)-auth-ldap package is required - and that I therefore need > fixed Apache 2 packages. Is this so ? Apache 2 comes with its own LDAP

Re: encrpyt harddrive without passphrase/userinput

* Mario Ohnewald: > The whole setup must fulfill the following requirements: > > a) it must be able to boot (remotely) without userinput/passphrase > b) the importtant partitions such as /etc, /var, /usr and /home must be > encrypted/protected. Put the key on an USB stick, and load it from an ini

Re: encrpyt harddrive without passphrase/userinput

* Horst Pflugstaedt: > I just ask myself why you bother encrypting a filesystem that will be > accessible to anyone having access to the machine since it boots without > password? You can return hard disks to the vendor for warranty claims even if they still contain sensitive data. -- To UNSUB

Re: encrpyt harddrive without passphrase/userinput

* Horst Pflugstaedt: > On Sun, Feb 26, 2006 at 11:17:56PM +0100, Florian Weimer wrote: >> * Horst Pflugstaedt: >> >> > I just ask myself why you bother encrypting a filesystem that will be >> > accessible to anyone having access to the machine since it boots with

Re: first A record of security.debian.org extremely slow

* martin f. krafft: > You are not really supposed to use those as they are pulled once > daily only, and security is a time-critical domain where sometimes > it's very important to have updates without any delays. One day more or less doesn't really matter. So far, Debian security updates predat

Re: first A record of security.debian.org extremely slow

* martin f. krafft: >> One day more or less doesn't really matter. So far, Debian security >> updates predated widespread (semi-)automated exploits by weeks. > > Why then do you think security.d.o is not mirrored by Debian? Our mirror network is not actually well-known for its integrity (think p

Re: first A record of security.debian.org extremely slow

* Geoff Crompton: > I'm also wondering if security.debian.org has enough resources for every > single debian box on the planet checking it every X minutes. You can use the DSA posting as a trigger. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact

  1   2   3   4   5   6   >