* Matthew Garrett:
I don't think that's a problem. Just put the original binary hash in the
certificate before signing it, and extend the X.509 parser to refuse
certificates that have a tag that's present in dbx.
Why would Microsoft put a hash of something into dbx which they
haven't
* Peter Jones:
I just want to make sure this doesn't go unresponded to - Red Hat
will not sign kernel modules built by an outside source. We're simply
not going to sign these kernel modules. That's one of the big reasons
we want a setup where they can sign their own modules in the first
* Matthew Garrett:
On Mon, Feb 25, 2013 at 03:46:14PM +0100, Florian Weimer wrote:
You could just drop the requirement that ring 0 code must be signed.
I don't think Windows 8 enforces this, but I'm not yet sure if there
is a physical presence check before you can enter a mode in which
* Daniel Borkmann:
> On 02/11/2013 08:00 PM, Florian Weimer wrote:
>> * Daniel Borkmann:
>
> Thanks for your feedback, Florian!
>
>>> + * memcmp_nta - memcmp that is secure against timing attacks
>>
>> It's not providing an ordering, so it should not have
* Daniel Borkmann:
On 02/11/2013 08:00 PM, Florian Weimer wrote:
* Daniel Borkmann:
Thanks for your feedback, Florian!
+ * memcmp_nta - memcmp that is secure against timing attacks
It's not providing an ordering, so it should not have cmp in the
name.
I agree. What would you suggest
* Daniel Borkmann:
> + * memcmp_nta - memcmp that is secure against timing attacks
It's not providing an ordering, so it should not have "cmp" in the
name.
> + for (su1 = cs, su2 = ct; 0 < count; ++su1, ++su2, count--)
> + res |= (*su1 ^ *su2);
The compiler could still
* Daniel Borkmann:
+ * memcmp_nta - memcmp that is secure against timing attacks
It's not providing an ordering, so it should not have cmp in the
name.
+ for (su1 = cs, su2 = ct; 0 count; ++su1, ++su2, count--)
+ res |= (*su1 ^ *su2);
The compiler could still short-circuit
* Matthew Garrett:
> I'm not sure why you think that Fedora PXE installs will
> automatically wipe disks - they'll do whatever Kickstart tells them
> to do.
Or what the referenced initrd contains (which is not signed, for
obvious reasons). The point is that "the bootloader is signed by
Fedora"
* Chris Friesen:
> On 11/06/2012 01:56 AM, Florian Weimer wrote:
>
>> Personally, I think the only way out of this mess is to teach users
>> how to disable Secure Boot.
>
> If you're going to go that far, why not just get them to install a
> RedHat (or SuSE, or Ubun
* Chris Friesen:
On 11/06/2012 01:56 AM, Florian Weimer wrote:
Personally, I think the only way out of this mess is to teach users
how to disable Secure Boot.
If you're going to go that far, why not just get them to install a
RedHat (or SuSE, or Ubuntu, or whoever) key and use that instead
* Matthew Garrett:
I'm not sure why you think that Fedora PXE installs will
automatically wipe disks - they'll do whatever Kickstart tells them
to do.
Or what the referenced initrd contains (which is not signed, for
obvious reasons). The point is that the bootloader is signed by
Fedora does
* Eric W. Biederman:
> If windows is not present on a system linux can not be used to boot a
> compromised version of windows without user knowledge because windows is
> not present.
Interesting idea. Unfortunately, it is very hard to detect reliably
that Windows is not present from the
* James Bottomley:
> Right, but what I'm telling you is that by deciding to allow automatic
> first boot, you're causing the windows attack vector problem. You could
> easily do a present user test only on first boot which would eliminate
> it.
Apparently, the warning will look like this:
* James Bottomley:
Right, but what I'm telling you is that by deciding to allow automatic
first boot, you're causing the windows attack vector problem. You could
easily do a present user test only on first boot which would eliminate
it.
Apparently, the warning will look like this:
* Eric W. Biederman:
If windows is not present on a system linux can not be used to boot a
compromised version of windows without user knowledge because windows is
not present.
Interesting idea. Unfortunately, it is very hard to detect reliably
that Windows is not present from the
* Greg KH:
> the logic is a little different in 2.6.22 and earlier in regards to this
> area of code. This way we are safer.
Your patch doesn't include the CVE-2006-0010 hunk. Is this because
get_user() implies an access_ok() check (while __copy_from_user()
obviously does not)?
--
To
* Greg KH:
the logic is a little different in 2.6.22 and earlier in regards to this
area of code. This way we are safer.
Your patch doesn't include the CVE-2006-0010 hunk. Is this because
get_user() implies an access_ok() check (while __copy_from_user()
obviously does not)?
--
To unsubscribe
* Matthew Wilcox:
> +struct stringbuf {
> + char *s;
> + int alloc;
> + int len;
> +};
I think alloc and len should be unsigned (including some return values
in the remaining patch).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
* Matthew Wilcox:
+struct stringbuf {
+ char *s;
+ int alloc;
+ int len;
+};
I think alloc and len should be unsigned (including some return values
in the remaining patch).
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
* Andrew Morton:
>> XFS overwrites that data with zeros upon reboot, which tends to
>> irritate users when it happens.
>
> yup.
>
>> >From this point of view, data=ordered doesn't seem too bad.
>
> If your computer is used by multiple users who don't trust each other,
> sure. That covers, what?
* Andrew Morton:
XFS overwrites that data with zeros upon reboot, which tends to
irritate users when it happens.
yup.
From this point of view, data=ordered doesn't seem too bad.
If your computer is used by multiple users who don't trust each other,
sure. That covers, what? About 2% of
* Andrew Morton:
> The easy preventive is to mount with data=writeback. Maybe that should
> have been the default.
The documentation I could find suggests that this may lead to a
security weakness (old data in blocks of a file that was grown just
before the crash leaks to a different user).
* Andrew Morton:
The easy preventive is to mount with data=writeback. Maybe that should
have been the default.
The documentation I could find suggests that this may lead to a
security weakness (old data in blocks of a file that was grown just
before the crash leaks to a different user). XFS
* Linus Torvalds:
> I consider dual-licensing unlikely (and technically quite hard), but at
> least _possible_ in theory. I have yet to see any actual *reasons* for
> licensing under the GPLv3, though. All I've heard are shrill voices about
> "tivoization" (which I expressly think is ok)
In a
* Linus Torvalds:
I consider dual-licensing unlikely (and technically quite hard), but at
least _possible_ in theory. I have yet to see any actual *reasons* for
licensing under the GPLv3, though. All I've heard are shrill voices about
tivoization (which I expressly think is ok)
In a
* Theodore Tso:
> we can continue trying to innovate around better filesystem and LVM
> storage technologies, as opposed to trying to chase the ZFS tail
> lights.
Indeed. Here's a gem from the official ZFS FAQ:
| What can I do if ZFS panics on every boot?
|
| ZFS is designed to survive
* Theodore Tso:
we can continue trying to innovate around better filesystem and LVM
storage technologies, as opposed to trying to chase the ZFS tail
lights.
Indeed. Here's a gem from the official ZFS FAQ:
| What can I do if ZFS panics on every boot?
|
| ZFS is designed to survive
> i read on the web that terry lambert has got 1.6 million simultaneous
> connection ? how is the way it is done.
Multiple IP addresses, I guess.
--
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
i read on the web that terry lambert has got 1.6 million simultaneous
connection ? how is the way it is done.
Multiple IP addresses, I guess.
--
Florian Weimer[EMAIL PROTECTED]
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
* Samium Gromoff:
>> > Lisp environments can produce standalone executables
>>
>> If you've got a stand-alone executable, you don't need MAP_FIXED. The
>> ELF loader maps the program at a fixed address anyway (at least on
>> i386 and x86_64, I haven't checked others).
>
> Not so.
>
> The thing
> Randomisation has nothing to do with C. In fact from a C perspective the
> compiler and linker do a lot of work to deal with ELF and loading code at
> arbitary addresses for dynamic linking and the like, not the user and
> not as language constructs. Perhaps the Lisp universe should wake up and
* Samium Gromoff:
> Lisp environments can produce standalone executables
If you've got a stand-alone executable, you don't need MAP_FIXED. The
ELF loader maps the program at a fixed address anyway (at least on
i386 and x86_64, I haven't checked others).
AFAIK, PolyML has recently made the
* Samium Gromoff:
Lisp environments can produce standalone executables
If you've got a stand-alone executable, you don't need MAP_FIXED. The
ELF loader maps the program at a fixed address anyway (at least on
i386 and x86_64, I haven't checked others).
AFAIK, PolyML has recently made the
Randomisation has nothing to do with C. In fact from a C perspective the
compiler and linker do a lot of work to deal with ELF and loading code at
arbitary addresses for dynamic linking and the like, not the user and
not as language constructs. Perhaps the Lisp universe should wake up and
* Samium Gromoff:
Lisp environments can produce standalone executables
If you've got a stand-alone executable, you don't need MAP_FIXED. The
ELF loader maps the program at a fixed address anyway (at least on
i386 and x86_64, I haven't checked others).
Not so.
The thing is that the
* Arjan van de Ven:
>> No amount of carefulness will prevent vendors stick arbitrarily
>> damaging values of stack and mmap base randomisation, severely reducing
>> the usefullness of MAP_FIXED.
>
> MAP_FIXED is useful still. The only safe way is to use addresses you got
> from mmap(), eg you
* Arjan van de Ven:
No amount of carefulness will prevent vendors stick arbitrarily
damaging values of stack and mmap base randomisation, severely reducing
the usefullness of MAP_FIXED.
MAP_FIXED is useful still. The only safe way is to use addresses you got
from mmap(), eg you overmap
* Greg KH:
>> This reminds of the the utterly broken dl2k network driver (which has
>> got interrupt handling problems and doesn't properly synchronize with
>> DMA transfers, IIRC). Hardware specs are available, and I guess I
>> could even provide a hardware sample, maybe even two. (If the
>>
* Greg KH:
> Yes, that's right, the Linux kernel community is offering all companies
> free Linux driver development. No longer do you have to suffer through
> all of the different examples in the Linux Device Driver Kit, or pick
> through the thousands of example drivers in the Linux kernel
* Greg KH:
Yes, that's right, the Linux kernel community is offering all companies
free Linux driver development. No longer do you have to suffer through
all of the different examples in the Linux Device Driver Kit, or pick
through the thousands of example drivers in the Linux kernel source
* Greg KH:
This reminds of the the utterly broken dl2k network driver (which has
got interrupt handling problems and doesn't properly synchronize with
DMA transfers, IIRC). Hardware specs are available, and I guess I
could even provide a hardware sample, maybe even two. (If the
community
* Linus Torvalds:
> Now, this should _matter_ only for user processes that are buggy,
> and that have written to the page _before_ extending it with
> ftruncate().
APT seems to properly extend the file before mapping it, by writing a
zero byte at the desired position (creating a hole).
24986
* Linus Torvalds:
Now, this should _matter_ only for user processes that are buggy,
and that have written to the page _before_ extending it with
ftruncate().
APT seems to properly extend the file before mapping it, by writing a
zero byte at the desired position (creating a hole).
24986
* Marc Haber:
> After updating to 2.6.19, Debian's apt control file
> /var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
> six hours.
I've seen that with Debian's 2.6.18 kernels as well. Perhaps it's
related to this Debian bug?
* Marc Haber:
After updating to 2.6.19, Debian's apt control file
/var/cache/apt/pkgcache.bin corrupts pretty frequently - like in under
six hours.
I've seen that with Debian's 2.6.18 kernels as well. Perhaps it's
related to this Debian bug?
* Mateusz Berezecki:
> Florian Weimer <[EMAIL PROTECTED]> wrote:
> -> The FTC issues are shared by many (most?) wireless drivers. The
> -> copyright/trade secret issues might be worked around by basing the
> -> work on the OpenBSD version of that driver (and someo
* Jeff Garzik:
> There is still the open question of whether this is legal enough to
> include in the kernel :(
Are you referring to FTC issues, or potential copyright/trade secret
issues?
The FTC issues are shared by many (most?) wireless drivers. The
copyright/trade secret issues might be
* Jeff Garzik:
There is still the open question of whether this is legal enough to
include in the kernel :(
Are you referring to FTC issues, or potential copyright/trade secret
issues?
The FTC issues are shared by many (most?) wireless drivers. The
copyright/trade secret issues might be
* Mateusz Berezecki:
Florian Weimer [EMAIL PROTECTED] wrote:
- The FTC issues are shared by many (most?) wireless drivers. The
- copyright/trade secret issues might be worked around by basing the
- work on the OpenBSD version of that driver (and someone is actually
- working
* Howard Chu:
>>> Has anybody contacted the Sleepycat people with a description of
>>> the problem yet?
>> Berkeley DB does not call sched_yield, but OpenLDAP does in some
>> wrapper code around the Berkeley DB backend.
> That's not the complete story. BerkeleyDB provides a
>
* Howard Chu:
Has anybody contacted the Sleepycat people with a description of
the problem yet?
Berkeley DB does not call sched_yield, but OpenLDAP does in some
wrapper code around the Berkeley DB backend.
That's not the complete story. BerkeleyDB provides a
db_env_set_func_yield() hook
* Andi Kleen:
> Has anybody contacted the Sleepycat people with a description of the
> problem yet?
Berkeley DB does not call sched_yield, but OpenLDAP does in some
wrapper code around the Berkeley DB backend.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
* Andi Kleen:
Has anybody contacted the Sleepycat people with a description of the
problem yet?
Berkeley DB does not call sched_yield, but OpenLDAP does in some
wrapper code around the Berkeley DB backend.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
* Janak Desai:
> With unshare, namespace setup can be done using PAM session
> management functions without patching individual commands.
I don't think it's a good idea to use security-critical code well
without its original specification. Clearly the current situation
sucks, but this is mainly
* Janak Desai:
With unshare, namespace setup can be done using PAM session
management functions without patching individual commands.
I don't think it's a good idea to use security-critical code well
without its original specification. Clearly the current situation
sucks, but this is mainly a
* Linus Torvalds:
> Ok,
> -rc3 is pretty small,
Is it -rc2 or -rc3? (Makefile and log message don't agree, either.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Linus Torvalds:
Ok,
-rc3 is pretty small,
Is it -rc2 or -rc3? (Makefile and log message don't agree, either.)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* Chuck Wolber:
> Has the Linux Kernel reached a point where the majority of developers feel
> that (at least for now) no *MAJOR* "rip it out, stomp on it, burn it and
> start over" parts of the kernel exist any longer?
The IP stack is likely to see some development activity, at leat there
are
* Chuck Wolber:
Has the Linux Kernel reached a point where the majority of developers feel
that (at least for now) no *MAJOR* rip it out, stomp on it, burn it and
start over parts of the kernel exist any longer?
The IP stack is likely to see some development activity, at leat there
are some
* Petr Baudis:
>> Almost certainly, v3 will be incompatible with v2 because it adds
>> further restrictions. This means that your proposal would result in
>> software which is not redistributable by third parties.
>
> Hmm, what would be actually the point in introducing further
> restrictions?
* Ingo Molnar:
> is there any fundamental problem with going with v2 right now, and then
> once v3 is out and assuming it looks ok, all newly copyrightable bits
> (new files, rewrites, substantial contributions, etc.) get a v3
> copyright? (and the collection itself would be v3 too) That
* Ingo Molnar:
is there any fundamental problem with going with v2 right now, and then
once v3 is out and assuming it looks ok, all newly copyrightable bits
(new files, rewrites, substantial contributions, etc.) get a v3
copyright? (and the collection itself would be v3 too) That method
* Petr Baudis:
Almost certainly, v3 will be incompatible with v2 because it adds
further restrictions. This means that your proposal would result in
software which is not redistributable by third parties.
Hmm, what would be actually the point in introducing further
restrictions? Anyone who
* David Lang:
>> Databases supporting replication are called high end. You forgot
>> the cats dance around the network this issue involves.
>
> And Postgres (which is Free in all senses of the word) is high end by this
> definition.
I'm not aware of *any* DBMS, commercial or not, which can
* David Lang:
Databases supporting replication are called high end. You forgot
the cats dance around the network this issue involves.
And Postgres (which is Free in all senses of the word) is high end by this
definition.
I'm not aware of *any* DBMS, commercial or not, which can perform
* Chris Wedgwood:
>> It doesn't matter so much for the cached case, but it _does_ matter
>> for the uncached one.
>
> Doing the minimal stat cold-cache here is about 6s for local disk.
Does sorting by inode number make a difference?
-
To unsubscribe from this list: send the line "unsubscribe
* Jon Smirl:
> On Apr 8, 2005 2:14 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>How do you replicate your database incrementally? I've given you enough
>>clues to do it for "git" in probably five lines of perl.
>
> Efficient database replication is achieved by copying the transaction
>
* Matthias Andree:
>> commiter_name VARCHAR(32) NOT NULL CHECK(commiter_name !=
>> ''),
>> commiter_email VARCHAR(32) NOT NULL CHECK(commiter_email
>> != ''),
>
> The length is too optimistic and insufficient to import the current BK
> stuff. I'd vote for
* Matthias Andree:
commiter_name VARCHAR(32) NOT NULL CHECK(commiter_name !=
''),
commiter_email VARCHAR(32) NOT NULL CHECK(commiter_email
!= ''),
The length is too optimistic and insufficient to import the current BK
stuff. I'd vote for 64 or at
* Jon Smirl:
On Apr 8, 2005 2:14 PM, Linus Torvalds [EMAIL PROTECTED] wrote:
How do you replicate your database incrementally? I've given you enough
clues to do it for git in probably five lines of perl.
Efficient database replication is achieved by copying the transaction
logs and
* Chris Wedgwood:
It doesn't matter so much for the cached case, but it _does_ matter
for the uncached one.
Doing the minimal stat cold-cache here is about 6s for local disk.
Does sorting by inode number make a difference?
-
To unsubscribe from this list: send the line unsubscribe
* Jonas Diemer:
> What do you think of this?
I think that these days, the underlying assumption (software cannot
destroy hardware, and if it can, we have a problem) is simply no
longer valid.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
* Jonas Diemer:
What do you think of this?
I think that these days, the underlying assumption (software cannot
destroy hardware, and if it can, we have a problem) is simply no
longer valid.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
* Bernd Eckenfels:
> In article <[EMAIL PROTECTED]> you wrote:
>> 3. I open a file w/o O_SYNC, issue a bunch of writes, then call
>> ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
>> Only the second set of writes are synchronous?
>
> I also am curious if one can open a
* Bernd Eckenfels:
In article [EMAIL PROTECTED] you wrote:
3. I open a file w/o O_SYNC, issue a bunch of writes, then call
ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
Only the second set of writes are synchronous?
I also am curious if one can open a file, write
* Geert Uytterhoeven:
>> Easy, start working for OSDL, then start hacking arch or
>> whatever. Puff, you are his coworker, you are competing with Larry,
>> Linus license goes away.
>
> I don't know whether the kernel hackers that work for IBM use the
> `free' version of BK or not, but if they do,
* Geert Uytterhoeven:
Easy, start working for OSDL, then start hacking arch or
whatever. Puff, you are his coworker, you are competing with Larry,
Linus license goes away.
I don't know whether the kernel hackers that work for IBM use the
`free' version of BK or not, but if they do,
Ubuntu Security Notice USN-82-1 mentions a remote crash in the IP
forwarding path. Quote from the Ubuntu security advisory (apparently,
no CVE name has been assigned so far):
| http://oss.sgi.com/archives/netdev/2005-01/msg01036.html:
|
| David Coulson noticed a design flaw in the
Ubuntu Security Notice USN-82-1 mentions a remote crash in the IP
forwarding path. Quote from the Ubuntu security advisory (apparently,
no CVE name has been assigned so far):
| http://oss.sgi.com/archives/netdev/2005-01/msg01036.html:
|
| David Coulson noticed a design flaw in the
One of my machines is running into an uncorrectable machine check
exception. The MCA error code is 0x152, but AMD's documentation
("AMD64 Architecture Programmer's Manual Volume 2: System
Programming") only contains a self-reference and no actual explanation
of the error codes.
Any hints on how
One of my machines is running into an uncorrectable machine check
exception. The MCA error code is 0x152, but AMD's documentation
(AMD64 Architecture Programmer's Manual Volume 2: System
Programming) only contains a self-reference and no actual explanation
of the error codes.
Any hints on how to
* Lorenzo Hernández García-Hierro:
> As it's impact is minimal (in performance and development/maintenance
> terms), I recommend to merge it, as it gives a basic prevention for the
> so-called system fingerprinting (which is used most by "kids" to know
> how old and insecure could be a target
* Lorenzo Hernández García-Hierro:
As it's impact is minimal (in performance and development/maintenance
terms), I recommend to merge it, as it gives a basic prevention for the
so-called system fingerprinting (which is used most by kids to know
how old and insecure could be a target system,
thought I had all of the sysctl ones
BTW uuid_strategy() is broken in the RANDOM_UUID case. It calls
copy_to_user() on table->data, which is always NULL.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT
() is broken in the RANDOM_UUID case. It calls
copy_to_user() on table-data, which is always NULL.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
Alexander Viro <[EMAIL PROTECTED]> writes:
> On 7 Jun 2001, Florian Weimer wrote:
>
> > Matthias Urlichs <[EMAIL PROTECTED]> writes:
> >
> > > Select is defined as to return, with the appropriate bit set, if/when
> > > a nonblocking read/wri
Alexander Viro [EMAIL PROTECTED] writes:
On 7 Jun 2001, Florian Weimer wrote:
Matthias Urlichs [EMAIL PROTECTED] writes:
Select is defined as to return, with the appropriate bit set, if/when
a nonblocking read/write on the file descriptor won't block. You'd get
EBADF
How do you avoid race conditions if more than one thread is creating
file descriptors? I think you can only do that under very special
circumstances, and it definitely requires some synchronization.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cer
conditions if more than one thread is creating
file descriptors? I think you can only do that under very special
circumstances, and it definitely requires some synchronization.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS
s area. Fortunately, there is a
number of other programming languages out there which do permit proper
bounds checking on arrays (and have strong, static typing and other
gizmos which make shooting yourself into the foot unintentionally a
bit more difficult).
--
Florian Weimer
are not flushed, the computer won't see the updates.
(Synchronization is done manually, so it's not an issue---trust me, I
know what I'm doing. ;-)
Kernel version doesn't matter. ;-)
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de
are not flushed, the computer won't see the updates.
(Synchronization is done manually, so it's not an issue---trust me, I
know what I'm doing. ;-)
Kernel version doesn't matter. ;-)
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de
. Fortunately, there is a
number of other programming languages out there which do permit proper
bounds checking on arrays (and have strong, static typing and other
gizmos which make shooting yourself into the foot unintentionally a
bit more difficult).
--
Florian Weimer[EMAIL
the choice whether to create a system which is
safe or a system which maximizes interoperability at the cost of
potential risks. IMHO, the first choice is much more appropriate than
the second one.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart
system which is
safe or a system which maximizes interoperability at the cost of
potential risks. IMHO, the first choice is much more appropriate than
the second one.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-st
Gerhard Mack <[EMAIL PROTECTED]> writes:
> PS I wish someone would explain to me why distros insist on using WU
> instead given it's horrid security record.
The security record of Proftpd is not horrid, but embarrassing. They
once claimed to have fixed vulnerability, but in fact introduced
Gerhard Mack [EMAIL PROTECTED] writes:
PS I wish someone would explain to me why distros insist on using WU
instead given it's horrid security record.
The security record of Proftpd is not horrid, but embarrassing. They
once claimed to have fixed vulnerability, but in fact introduced
ontrol it at a single place, either when passing the
parameter down to modprobe, or in modprobe itself. Everything else is
too error-prone.
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-7
601 - 698 of 698 matches
Mail list logo
