Slashdot Mirror

from the LKML

SCo's infringing files list thread (51 articles)

AIX has crappy code (ctype.h)

(end lkml)
this week SCO puts up or shuts up

Smking Crack (and running Linux

from the LKML

SCo's infringing files list thread (51 articles)

AIX has crappy code (ctype.h)

(end lkml)
this week SCO puts up or shuts up

Smking Crack (and running Linux

According to the LKML, it's probably not in 2.2.x

that's an old email. 2.6.0 kernel changelog torvalds is at OSDL (open source development labs).

or goto slashdot archives on the topic.

or visit the lkml archives and read the email addy from the already done search.

No, that was David Wexelblatt.

David Dawes was the one who explained to The Open Group what they could with their X server when they tried to make it non-free.

Indeed. I believe Intel is already working with kernel developers on EFI. I see posts on EFI in the linux-kernel mailing list archives. I think this won't affect Linux much at all, although I don't know whether it will be able to take over EFI calls the same way it does BIOS calls.

Yes.

InnoDB takes a snapshot in time with REPEATABLE READ (and doesn't lock anything to do so). That means you can not get any one elses data injected while you are inside your transaction, which means you get a snapshot of only completed transactions. Here is a link where the creator of InnoDB talks about using mysqldump.

It sounds like PostgreSQL's SERIALIZABLE is very similar to InnoDB's REPEATABLE READ setting. It might be because PostgreSQL isn't really serializable in the mathmatical sense while InnoDB is. I'm not that familar with PostgreSQL's internals to know if it is similar to InnoDB's REPEATABLE READ level.

I'm sure this will be posted a billion times on /. but here is what Linux said in response. http:/ /marc.theaimsgroup.com/?l=linux-kernel&m=107212899 108511
hehe

Some people have pointed out that they are doing it to remove self
incriminating evidence from their website. Very likely.

Yeah, some items have disappeared
Like an ELF spec? Or the whole devspec page?

I really don't understand how this was done. None the less you CAN recover from this. Here's a little tutorial I found. I Highly suggest doing the backup first!!! :

If you're really really desperate, you can do what I did a few weeks ago. In my \
case, fsck didn't recover the partition either, indeed it crashed. So here's what's \
I did from the beginning of what I think fixed it:

1) reiserfsck --rebuild-tree
2) mount
3) reiserfsck -S
4) debugreiserfs to get metadata for Vitaly
5) mount
6) mount again

I'm not sure why this happened, but after the second mount, the partition was not \
recognizeable as ReiserFS anymore. I suspect it had to do with a few really huge \
files that were originally on the partition that reisefsck -S tried to recover. In \
doing so it probably hosed lots of stuff. Now, it was as simple as

7) reiserfsck --rebuild-tree

And I had most of my data linked under lost+found! Took me a few hours to sort \
through it all but I got back most of what I cared about. Maybe if you use the new \
pre8 fsck you won't need to jump through these hoops. Since the potential for data \
destruction is high here, I wouldn't blame you for not trying. And yes, this all \
happened by trial and error ::-)

This might help too :
http://marc.theaimsgroup.com/?l=reiserfs&m=1048613 18421306&w=2.

Good luck!

All of the critical fixes from -mm are pushed into Linus's current tree. Just take a look at the "Merged" section immediately following "Latest Linus tree" here; repeat with the previous -testX-mmY patch announcements.

Now take a look at this under the "Andrew Morton" heading and notice how many of those patch headings ring a bell. Yessir, he has been kickin' arse and taking names.

First, to answer your question. No, I have not yet used udev. When the semester finally wraps up, I plan on taking a look -- hoping that 2.6.0-final has not been released yet (a nice long "-rc"ish plan sounds best imo). My impression is that there's still a fair amount of configuration to be done, both documentation- and code-wise (of course not forgetting conffiles), so the more eyes looking at it, the better.

I highly recommend reading Greg's OLS paper Re: udev. Go here for quick links. ...And in the off-chance that someone reading this is using Debian sid, go here for packages.

First, to answer your question. No, I have not yet used udev. When the semester finally wraps up, I plan on taking a look -- hoping that 2.6.0-final has not been released yet (a nice long "-rc"ish plan sounds best imo). My impression is that there's still a fair amount of configuration to be done, both documentation- and code-wise (of course not forgetting conffiles), so the more eyes looking at it, the better.

I highly recommend reading Greg's OLS paper Re: udev. Go here for quick links. ...And in the off-chance that someone reading this is using Debian sid, go here for packages.

Here's what someone apparently from trident said about Linux support on the DRI list.

There are still a lot of problems with fb in 2.6 and will be for several versions judging from the development. But there's some interesting conversations regarding graphics on the lkml.

Some drives can, but no CD-ROM drives can. This problem only affects LG plain CD-ROM drives.

http://marc.theaimsgroup.com/?l=linux-smp&m=902223 42930942&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=902 22342930991&w=2

On Thu, 7 May 1998, Andre M. Hedrick wrote:

> On Wed, 6 May 1998, Mark Garlanger wrote:
>
> >
> > You should really just put it up at a web site and have people download it if needed.
> > It's
> > just wasted time for the people that only using SCSI or 2.0.33.
> >
> > Mark
> >
>
> Really??
>
> With Ultra DMA/33 EIDE drives at burst transfer rates of 133Mb per second
> and sustained transfer rates of 33Mb per second, about $260 for 6.4G
> Quantum Fireball, $60-80 for the controller, one HH-3.5 bay, and one
> interrupt for 4 (four) devices that are true backwards compatable.
> This is a DEKA-BUCK solution.
>
> Compared against Ultra-Wide SCSI-3 drives at burst transfer rates of 120Mb
> per second and sustained transfer rates of 40Mb per second, about
> $750-1000 for 6.4-9.2G (name your brand), $260 or more for the controller,
> usually FH-5.25 bay required, and one interrupt for 7 (mixed SCSI-class)
> to 15 (all SCSI-3UW) (includes CDROM/CDR/TAPE/DISK all SCSI-3UW).
> This is a KILO-BUCK solution.
>
> Once you leave the SCSI-3 class to cost/performance diverges worse
> than above.
>
> Please note that I may have some of my facts wrong about the SCSI-3UW
> standard/performance/compatablity, but the cost is well understood.
>
> You must have more $$$ to burn for an Ultra-Wide SCSI-3 system,
> when compared against the close second in performance of the
> new Ultra DMA/33 standard offers many people.

Well any (WHATEVER)-IDE solution is a single-user/single-task
hardware setup. Running a True Multi-user/Multitasking OS like Linux
on that gives frustrations when running it on such hardware.

UW-SCSI-3 is a multi-user/multi-tasking hardware-setup. So Linux will
perform on that always better.

Robert

http://marc.theaimsgroup.com/?l=linux-smp&m=902223 42930942&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=902 22342930991&w=2

On Thu, 7 May 1998, Andre M. Hedrick wrote:

> On Wed, 6 May 1998, Mark Garlanger wrote:
>
> >
> > You should really just put it up at a web site and have people download it if needed.
> > It's
> > just wasted time for the people that only using SCSI or 2.0.33.
> >
> > Mark
> >
>
> Really??
>
> With Ultra DMA/33 EIDE drives at burst transfer rates of 133Mb per second
> and sustained transfer rates of 33Mb per second, about $260 for 6.4G
> Quantum Fireball, $60-80 for the controller, one HH-3.5 bay, and one
> interrupt for 4 (four) devices that are true backwards compatable.
> This is a DEKA-BUCK solution.
>
> Compared against Ultra-Wide SCSI-3 drives at burst transfer rates of 120Mb
> per second and sustained transfer rates of 40Mb per second, about
> $750-1000 for 6.4-9.2G (name your brand), $260 or more for the controller,
> usually FH-5.25 bay required, and one interrupt for 7 (mixed SCSI-class)
> to 15 (all SCSI-3UW) (includes CDROM/CDR/TAPE/DISK all SCSI-3UW).
> This is a KILO-BUCK solution.
>
> Once you leave the SCSI-3 class to cost/performance diverges worse
> than above.
>
> Please note that I may have some of my facts wrong about the SCSI-3UW
> standard/performance/compatablity, but the cost is well understood.
>
> You must have more $$$ to burn for an Ultra-Wide SCSI-3 system,
> when compared against the close second in performance of the
> new Ultra DMA/33 standard offers many people.

Well any (WHATEVER)-IDE solution is a single-user/single-task
hardware setup. Running a True Multi-user/Multitasking OS like Linux
on that gives frustrations when running it on such hardware.

UW-SCSI-3 is a multi-user/multi-tasking hardware-setup. So Linux will
perform on that always better.

Robert

And Markus, author of OpenSSH, just updated the OBSD source twice regarding this openssl issue as well.

And Markus, author of OpenSSH, just updated the OBSD source twice regarding this openssl issue as well.

OpenSSH isn't remotely vulnerable to these attacks. Recent versions don't use the OpenSSL ASN.1 parsing code for signature validation (e.g. signatures coming from the network). The OpenSSL ASN.1 code is only used for parsing private keys.

This was done a little while ago, as Markus (wisely) decided that we didn't need a whole ASN.1 parser just to verify signatures.

Don't let that slow you down patching the issue - Apache and other SSL/TLS apps (OpenLDAP, the various imapd's, etc.) may be vulnerable.

Amazon also uses Mason. See here. Although, IIRC mod_perl is required for Mason.

dorkslayers.com did not have NS records in the GTLD zone when Verisign added the wildcard records. The was quite a popular topic among mail administrators shortly after the wildcards were added. There's discussion about it here on the NANOG list, and here on the SpamAssassin discussion mailing list, and here in comp.mail.sendmail, and here in news.admin.net-abuse.email. There are others but these are the ones I frequent.

That said since dorkslayers.com (spelled it right this time) didn't have any NS records in the root GTLD when Verislime added the wildcards .com/.net all queries for the dorkslayers.com domain resulted with a positive response. This included any and all queries for anything hosts and subdomains. To use your example, randomjunk.dorkslayers.com would in fact have resolved to 64.94.110.11 before Bill, the dorkslayers.com owner, re-registered NS servers for dorkslayers.com.

There is another gentleman on the NANOG mailing list that has mentioned more than once since the Verislime incident that he has a client with a domain in use that somehow has gotten left out of the GTLD .com zone. I don't remember his name and I don't really want to sort through the lengthy threads about Verisign to find the posts. They are in the archives though. He discussed the lengths he's gone to to try and get Verisign to fix the problem in excrutiating detail. It sounded like he wasn't having much fun.

Let me make sure I answered all your points for my own sanity's sake. Paragraph 1, check. Paragraph 2, check. Paragraph 3, check. Paragraph 4, check. And Paragraph 5, clarified. Hope that helps.

Why is it so hard to make links from the urls? Anyway, here goes:

upgrade can be found here

There is no need to create a com or net data file. Just the
entries to the named.conf file is enough
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };

Ofcourse, if you use views, this needs to be provided within the relevant
view (the one performing recursive lookups).

quote from here

DaC

Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).

You can get the details from the bind-announce list archives:

• 9.2.2-P1
• 9.1.3-P1
• 9.2.3rc2

All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:

In response to high demand from our users, ISC is releasing a patch for BIND to support the declaration of "delegation-only" zones in caching/recursive name servers. Briefly, a zone which has been declared "delegation-only" will be effectively limited to containing NS RRs for subdomains, but no actual data outside its apex (for example, its SOA RR and apex NS RRset). This can be used to filter out "wildcard" or "synthesized" data from NAT boxes or from authoritative name servers whose undelegated (in-zone) data is of no interest.

Have fun downloading and installing!

Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).

You can get the details from the bind-announce list archives:

• 9.2.2-P1
• 9.1.3-P1
• 9.2.3rc2

All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:

In response to high demand from our users, ISC is releasing a patch for BIND to support the declaration of "delegation-only" zones in caching/recursive name servers. Briefly, a zone which has been declared "delegation-only" will be effectively limited to containing NS RRs for subdomains, but no actual data outside its apex (for example, its SOA RR and apex NS RRset). This can be used to filter out "wildcard" or "synthesized" data from NAT boxes or from authoritative name servers whose undelegated (in-zone) data is of no interest.

Have fun downloading and installing!

Although the news are not on the BIND page yet, patches for the current versions 9.2.2 and 9.1.3 are already available. Only 9.2.3rc2 is currently listed on the page (as of this writing).

You can get the details from the bind-announce list archives:

• 9.2.2-P1
• 9.1.3-P1
• 9.2.3rc2

All versions were released a few hours ago. Here is the common paragraph at the top of these three messages:

In response to high demand from our users, ISC is releasing a patch for BIND to support the declaration of "delegation-only" zones in caching/recursive name servers. Briefly, a zone which has been declared "delegation-only" will be effectively limited to containing NS RRs for subdomains, but no actual data outside its apex (for example, its SOA RR and apex NS RRset). This can be used to filter out "wildcard" or "synthesized" data from NAT boxes or from authoritative name servers whose undelegated (in-zone) data is of no interest.

Have fun downloading and installing!

This patch allows you to blacklist sender or recipient addresses
on the basis of their MX (or DNS) server's hostname and IP addresses.
Blocking by DNS server was asked for long ago. I wrote it today
because the same code can also be used to block verisign wild-card
domains.
/etc/postfix/main.cf:
smtpd_mumble_restrictions =
...
check_sender_mx_access hash:/etc/postfix/mx_access
...

/etc/postfix/mx_access:
64.94.110.11 reject verisgn wild-card

Combined with the new CIDR table this also allows you to block
mail from senders whose MX hosts resolve to reserved address
blocks such as 127.0.0.0/8 or 192.168.0.0/16.

This patch was written with yesterday's snapshot. It will also
apply with little trouble to the stable release.

This code is lightly tested. I haven't got the time to put this
into operation here today.

Wietse

1. Versions affected:

All versions of OpenSSH's sshd prior to 3.7 contain a buffer
management error. It is uncertain whether this error is
potentially exploitable, however, we prefer to see bugs
fixed proactively.

Sorry if this is already in the replies somewhere, but with the amount of response I figured I'd toss this up so people starting at the end looking forward for BIND 9 solutions/patches to this since I haven't really found anything solid yet.

For those who don't recognize the name.

Paul Vixie stated on bind9-workers that the ISC coding staff is working on changes to bind to fix this as we speak. See his comment here.

ferratus wrote:

Reading the mailing list, it appears that there's nothing confirmed so far. Let's hope its just a false rumour.

Not entirely true, it is confirmed that there is a bug, the bug is possibly exploitable. A little more info (and the patch) can be found at: http://marc.theaimsgroup.com/?l=openbsd-misc&m=106 371592604940&w=2

What hasn't been confirmed is:
A) Is it truly exploitable, or just a bug? and
B) Has it been exploited in the wild?
C) Has it been exploited on a ssh server with privilege separation properly enabled?

Just because a potential buffer overflow exists in code, does not mean its exploitable. I repeat, Not all buffer overflows are exploitable. Not all bugs in code are exploitable.

Link to Patch

The above link shows the buffer overflow and a patch to fix it. However no body has confirmed whether or not this bug is even exploitable. So before we all run and cry wolf about all our SSH servers being hacked lets calmly and collectivley actually let the people who know what they're talking about investigate if this is even exploitable.

But by all means patch and upgrade, better safe than sorry. But theres no reason for the drama.

Link to a patch.

Just one zero is needed, as it will disable the test for all modes.

By default, the OSIRU tests are enabled only when running network mode only, so if you havent customized your configuration and changed that, then you are in the clear - but it's a good idea to disable these tests nonetheless.

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

One impact, that strangely no one noticed here, is the amount of bandwidth this worm consumes from buzy smtp servers. My company provides email support to hundreds of thousands of users, so our addresses are in their address books.
My 2 t1 connections were overloaded a few hours after the worm got in the wild ! i had to work for about 10 hours to design a dynamic firewall filter to block infected systems from hammering my server, since these clients try to send their mail over and over to the same email adresses.
People intested in the filter description can find it in the postfix-users mailinglist - look for the messages "Battling SoBig.f induced bandwidth problems ". I only pity these who do not have the flexibility of a good *Nix based mail server - no way you can do that with Exchange

The relevant histories of ate_utils.c for 2.4 and 2.5.
Apparently the code was removed because it was "ugly as hell" (or worse).

The relevant histories of ate_utils.c for 2.4 and 2.5.
Apparently the code was removed because it was "ugly as hell" (or worse).

There's also a very informative lkml thread about this and it's already been removed from the source tree, but apparently not because of copyright issues but because it was just "ugly as hell".

There's also a very informative lkml thread about this and it's already been removed from the source tree, but apparently not because of copyright issues but because it was just "ugly as hell".

There's also a very informative lkml thread about this and it's already been removed from the source tree, but apparently not because of copyright issues but because it was just "ugly as hell".

http://www.tuhs.org/Archive/Caldera-license.pdf

January 23, 2002 Dear UNIX? enthusiasts, Caldera International, Inc. hereby grants a fee free license that includes the rights use, modify and distribute this named source code, including creating derived binary products created from the source code. The source code for which Caldera International, Inc. grants rights are limited to the following UNIX Operating Systems that operate on the 16-Bit PDP-11 CPU and early versions of the 32-Bit UNIX Operating System, with specific exclusion of UNIX System III and UNIX System V and successor operating systems: 32-bit 32V UNIX 16 bit UNIX Versions 1, 2, 3, 4, 5, 6, 7

-Tupshin

I applaud this initiative. Might be what X needs to get back to life. A bit of competition always sounds like a good thing.

But if they are really serious at encouraging developpers to join this project, the first sensible thing to do would probably be to forget about the IMake crazyness that has been used for years by XFree86 and switch to something else for building the whole project.

Replacing it by the autoconf/automake mix would make the source tree much more appealing to potential developpers. And just to back up my claim, someone else also made the same comment on the xfree-xpert mailing list a few months ago:

(...)
[ I also hope that somebody with more drive than I have will some day decide that the X Makefiles are such a mess that they'd be willing to get rid of all that horribly broken imake crap and just fix them. What a broken build system! ]

Linus

(...)
Just my 0x02 cents...

JBoss is already an Open Source implementation. Might it be a better effort to contribute and make JBoss stronger?

Yes, it would. However, the license used by Apache projects is less restrictive than the LGPL that is used in JBoss licensing. Also, many of the developers who are most interested in pushing Geronimo out of the incubator are actually former committers on the JBoss project. There is some bad blood on this issue, and it does not look like JBoss Group is interested in letting these people be committers to both the Apache project and the JBoss project.

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)