Il lun, 2003-08-11 alle 12:22, Gian Piero Carrubba ha scritto:
DSA-361-1 states that the vulnerabilities reported have been fixed in
2.2.2-13.woody.8 (and this is the version you can find in the
repository)... DSA-361-2 is the same advisory, except that it states
that the vulnerabilities have
Il lun, 2003-08-11 alle 02:58, Matt Zimmerman ha scritto:
I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been
released in december 2001
2.2.2-6woody2 is a later version than 2.2.2-6. 2.2.2-6 has the bugs,
2.2.2-6woody2 has the fixes.
2.2.2-6 has been released on dec
Hi all,
can anyone explain me the DSA-361-2?
Does it mean that the vulnerabilities reported were already addressed in
woody in version 2.2.2-6woody2 ?
I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been
released in december 2001, so i've to assume fake vulnerabilities (CAN
Il ven, 2004-02-20 alle 05:58, John Galt ha scritto:
we won't hide problems ...
Well, I really don't want to feed a troll, but this is a theme I'm
wondering about from a while...
Shouldn't the delayed disclosure be regarded a a sort of, at least
partially, infringement of the Debian manifesto ?
From
http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6
When a security fix is prepared, packages are prepared for unstable
and the patch is back ported to stable (since stable is usually some
minor or major versions behind). Packages for the stable distribution
are
Il ven, 2004-02-20 alle 12:13, Michael Stone ha scritto:
Well, I really don't want to feed a troll, but this is a theme I'm
wondering about from a while...
Then do a web search. It's been discussed before in way too much detail
and repeating the arguments just brings out the trolls.
You're
Il ven, 2003-04-25 alle 11:19, David Ramsden ha scritto:
Noticed on vil.mcafee.com that a proof of concept exploit for Snort to
exploit the vuln. found in v1.8 through to 1.9.1.
up to 2.0rc1 as reported by cert
What's the status of a patch from Debian Security? No DSA yet either.
I know
Hi all,
can anyone explain me the DSA-361-2?
Does it mean that the vulnerabilities reported were already addressed in
woody in version 2.2.2-6woody2 ?
I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been
released in december 2001, so i've to assume fake vulnerabilities (CAN
Il lun, 2003-08-11 alle 02:58, Matt Zimmerman ha scritto:
I haven't found 2.2.2-6woody2 in the changelog, however 2.2.2-6 has been
released in december 2001
2.2.2-6woody2 is a later version than 2.2.2-6. 2.2.2-6 has the bugs,
2.2.2-6woody2 has the fixes.
2.2.2-6 has been released on dec
Il lun, 2003-08-11 alle 12:22, Gian Piero Carrubba ha scritto:
DSA-361-1 states that the vulnerabilities reported have been fixed in
2.2.2-13.woody.8 (and this is the version you can find in the
repository)... DSA-361-2 is the same advisory, except that it states
that the vulnerabilities have
Il ven, 2004-02-20 alle 05:58, John Galt ha scritto:
we won't hide problems ...
Well, I really don't want to feed a troll, but this is a theme I'm
wondering about from a while...
Shouldn't the delayed disclosure be regarded a a sort of, at least
partially, infringement of the Debian manifesto ?
From
http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s9.1.6
When a security fix is prepared, packages are prepared for unstable
and the patch is back ported to stable (since stable is usually some
minor or major versions behind). Packages for the stable distribution
are
Il ven, 2004-02-20 alle 12:13, Michael Stone ha scritto:
Well, I really don't want to feed a troll, but this is a theme I'm
wondering about from a while...
Then do a web search. It's been discussed before in way too much detail
and repeating the arguments just brings out the trolls.
You're
Il gio, 2004-05-13 alle 19:53, Kjetil Kjernsmo ha scritto:
[...]
19:41:32.083993 217.77.34.162.2090 226.58.55.41.1434: udp 376 [ttl 1]
19:41:32.192344 217.77.34.162.2090 234.247.236.46.1434: udp 376 [ttl
1]
A switched lan, I see ;)
It can be slammer [1] (if so, I guess why the ISP tech
Il giorno Thu, 7 Jun 2007 15:51:51 +0200
Joan Hérisson [EMAIL PROTECTED] ha scritto:
So I added this rule :
iptables -A tcp_packets -p TCP -i eth1 -s
0/0 --dport 8080 -j allowed
where eth1 is the way toward my local network
* [Sat, Apr 23, 2011 at 12:04:33PM +0200] Quequanys:
Does it fallback to weaker algorithm, if the hash
made with stronger one is not avaible? Is there a
way to force APT to use only selected algorithms
so APT only accepts files verified by choosen
algorithms, and rejects files when required
* [Fri, Apr 29, 2011 at 07:57:28PM +0200] Tomasz Wozowicz:
ForceHash sha256; // hashmethod used for expected hash: sha256,
sha1 or md5sum
It doesnt say what will happen if the expected hash is unavaible-
maybe it will just use weaker hash as fallback?
No. After all, it's named ForceHash not
* [Mon, Sep 01, 2014 at 08:48:25PM +0200] Thijs Kinkhorst:
[needrestart]
- Do people agree that this would be something that's good to have in a
default installation? Are there drawbacks?
I like needrestart and I added it to my standard toolbox since its
admission in Debian (well, it took
* [Fri, Nov 13, 2020 at 05:26:56AM -0500] John Runyon:
Why do we have such messages on the security mailing list? Is there a
way to get actual security team announcements without all this spam?
That's a job for debian-security-announce@l.d.o (please note the
'-announce' suffix)
Ciao,
Gian
* [Thu, Aug 19, 2021 at 01:25:00AM -0500] Daniel Lewart:
Is there a preferred sources.list URI for the Debian security
repository between:
* http://deb.debian.org/debian-security
* http://security.debian.org/debian-security
I asked in debian-devel and received two replies:
*
* [Sat, Jan 22, 2022 at 11:09:20AM +0100] Stefan Fritsch:
I think the bullseye-security codename should be "bullseye" instead.
Or am I missing something
The repo naming scheme has changed with bullseye. I do not have the
announcement at hands, however the old '/updates' is now
'-security',
* [Fri, Mar 29, 2024 at 10:24:09PM +] Adam D. Barratt:
Due to recent events, the point release has been postponed. A new date
will be announced when possible.
Given the centrality of xz, and standing that AFAIK the intricacies of
the attack are not yet fully understood, should we expect a
* [Wed, Apr 03, 2024 at 09:21:41AM +0100] Samuel Henrique:
# Alternative solutions:
If we really want to distinguish the case when we don't produce any affected
packages but the source contains the vulnerability (a build with different
flags might result in an affected package), we can create a
* [Sun, Mar 31, 2024 at 09:28:46PM +] Nick Sal:
With respect to debian testing, assume we filter SSH access only to a
subnet using the files host.{deny,allow} (see below).
Would this prevent the attack if a malicious payload was not sent from
the allowed subnet?
I've not seen any
* [Wed, Apr 03, 2024 at 11:11:20PM +0100] Samuel Henrique:
On the proposed solution I also mention that we can use the "(free text
comment)" section to indicate that, while sticking to "not-affected", this
would simplify things as no new value is needed. But parsing the cases where
only the
25 matches
Mail list logo
