December 2003 - Legacy - lists.gtalug.org

video plugin for mozilla on linux
by jason-gaRZxGPHtpBxZtjKW1aY+1aTQe2KTcn/＠public.gmane.org 04 Dec '03

04 Dec '03

You can get the Macromedis Flash rpm's here http://sluglug.ucsc.edu/macromedia/site_ucsc.html And mozplugger if you do not already have it installed http://freshmeat.net/redir/mozplugger/37064/url_rpm/mozplugger-1.3.2-1.i586… JoeHill wrote: > On Wed, 3 Dec 2003 14:10:47 -0500 > Austin <aacton-B71PBEe7S7Y at public.gmane.org> wrote: > > >>>I want to install real player and flash plug-ins on Mandrake 9.2. >>>First I am trying to get flash to work, but after installation I >>>receive: >>> >>>LoadPlugin: failed to initialize shared library >>>/usr/lib/mozilla-1.5/plugins/libflashplayer.so >>>[libstdc++-libc6.2-2.so.3: cannot open shared object file: No such >>>file or directory] >> >># urpmi libstdc++2.10 >> >>BTW, the rpm is non-free software so it's only available on the >>PowerPack CD's and on the club website. > > > Strange, this wasn't the case on 9.1. I had Texstar's Mozilla Flash plugin > workin' fine, and I certainly have no club membership...yet ;-) > > Now I'm stuck in the same situation as Lloyd. > -- " Eventually people tire of repairing broken Windows, And decide to replace them with something stronger" (o_ //\ Linux - The Choice Of A GNU Generation V_/_ Jason Shein Linux Registered User #281100 jason-gaRZxGPHtpBxZtjKW1aY+1aTQe2KTcn/(a)public.gmane.org -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Got a license for that Code?
by joehill-rieW9WUcm8FFJ04o6PK0Fg＠public.gmane.org 04 Dec '03

04 Dec '03

"It looks like the Microsoft front organizations are pushing licensing for software writers. Of course, the usual suspects, the BSA and ITAA are involved in writing the laws." Link: http://newsvac.newsforge.com/article.pl?sid=03/12/03/1640223 -- JoeHill ++ ICQ # 280779813 Registered Linux user #282046 Homepage: www.orderinchaos.org +++++++++++++++++++++++++++ "Behind every great fortune is a crime." -- Balzac -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Multiple USB keyboards ?
by tim-s/rLXaiAEBtBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

William Park <opengeometry-FFYn/CNdgSA at public.gmane.org> writes: > I have multiple video cards (agp, pci) and multiple mouses (serial, > ps/2, usb) working independently. That is, I can choose which should be > selected when bringing up X. > > But, multiple keyboards are all shared; so, you can press keys from any > keyboard. How do you get them working independently? By having a separate XF86Config for each keyboard, mouse, and video card combination. Each XF86Config would have its own InputDevice sections for its respective keyboard and mouse. The trick is to know which device (in /dev) represents which keyboard or mouse. This is obviouse if you have say one PS/2 keyboard, one USB keyboard, one PS/2 mouse, and one USB mouse. But it's tricky if you have multiple USB keyboards and mice since they will be assigned entries in /dev/input dynamically. As long as you keep them permanently plugged in, you should be able to figure out what's what by trial and error. Note, while I have used USB keyboards and mice, I haven't tried this type of setup so YMMV. Good luck, -- tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> starnix inc. 905.771.0017 ext. 225 thornhill, ontario, canada http://www.starnix.com professional linux services & products -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

C considered harmful: was Debian attacker may have used new exploit
by tim-s/rLXaiAEBtBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> writes: > On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote: > > OK, I hate to flog a dead horse but really: > > > > Hmmmm, this is likely to start a looooong drawn out flame thread. > Language arguments almost always do. So, with trying to prevent that in > mind, I will avoid standing up for my general language of choice and > instead offer an alternative. > > > This exploit, like others against Unix machines many years ago, was based on > > a buffer overflow dumping the user into supervisor space. This, in turn, is > > a direct result of the fact that the C programming language does not check > > or enforce limits on a string length or buffer size - that's left up to the > > individual programmer. > > > > Surely, given the importance of security, it should be possible to fix the C > > language (or my preference, use a different one) to do systems programming. > > After all, C is not so much a systems programming language as a high-level > > version of assembly language. > > > > "Fixing" C in the sense you're imagining will never happen and people > often do use other languages for specific tasks. However, other > languages are not immune to buffer overflows as most of them are > actually written in C themselves. Not immune but still resistant. Typical C programs are full of calls to "dangerous" functions like strcpy() and sprintf(), as well as direct pointer manipulations. While language interpreters are no different, their cores tend to be quite small compared with modern behemoths and are well tested both with comprehensive test suites, which accompany most decent languages, and via applications written in the language. The flip side of course is that a buffer overflow (or similar problem) in a language implementation has the potential to affect all applications deployed in that language, so the impact could be much more widespread than a buffer overflow in a given C application. > The better solution is things like stackguard[1] and execshield[2] which > actually fix the root problem: the stack should NOT be executable and > neither should most of the heap and likewise portions of memory which > are actively executable shouldn't be writable from userspace. Maybe. Some language environments rely on an executable stack to implement trampolines. An executable heap could be useful in languages with just-in-time compilation or dynamic loading of compiled code, although I don't know if any language implementations use such techniques. -- tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> starnix inc. 905.771.0017 ext. 225 thornhill, ontario, canada http://www.starnix.com professional linux services & products -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

C considered harmful: was Debian attacker may have used new exploit
by tim-s/rLXaiAEBtBDgjK7y7TUQ＠public.gmane.org 04 Dec '03

04 Dec '03

Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> writes: > On Wed, 2003-12-03 at 23:30, Henry Spencer wrote: > > On Wed, 3 Dec 2003, Peter Hiscocks wrote: > Hell, even Prolog and the many species of LISP-type-languages are > interesting in their own right (though not terribly useful in my mind). LISP not useful? Sacrilege! I'm responding to this with Gnus, still arguably one of the best mail/news clients, running within Xemacs, still arguably one of the best programmers' editors (vi/emacs flame wars notwithstanding), written in a dialect of LISP. > But if you fit well into a specific category of application development > then there is a whole host of better choices for you. For instance, next > major GUI application I write will probably be in Java [....] You might find this article, by one of the LISP community's greats, both interesting and on topic: http://www.paulgraham.com/javacover.html -- tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org> starnix inc. 905.771.0017 ext. 225 thornhill, ontario, canada http://www.starnix.com professional linux services & products -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003, JoeHill wrote: > Like to have the last word, eh? No, I just find repeating myself on mailing lists to be a waste of time. I found I so many better uses for the time. Ok, so I replied :) I'm gone now. Please feel free to have the last word, it won't bother me a bit. Rob -- Robert Brockway B.Sc. email: robert-5LEc/6Zm6xCUd8a0hrldnti2O/JbrIOy at public.gmane.org, zzbrock at uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

C considered harmful: was Debian attacker may have used new exploit
by marcus.brubaker-H217xnMUJC0sA/PxXw9srA＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 23:30, Henry Spencer wrote: > On Wed, 3 Dec 2003, Peter Hiscocks wrote: > > This exploit, like others against Unix machines many years ago, was based on > > a buffer overflow dumping the user into supervisor space. > > Actually, no, as I understand it (with the caveat that I haven't really > gone investigating), this one is *not* a buffer overflow, exactly. It's > the result of *integer* overflow in (essentially) a buffer-overflow check. > A language with automatic buffer-overflow checks could easily have the > same vulnerability, if the implementor wasn't careful. > Interesting, this is certainly a less common form of exploit... > > After all, C is not so much a systems programming language as a high-level > > version of assembly language. > > Oddly enough, it has pushed most "real" systems programming languages out > of the business. And this is *not* because of sharp marketing tactics or > firm backing by a big organization or dot-com hype -- quite the contrary. > It succeeded because people with work to do find it easier to get results > in C than in "real" systems programming languages, and so it spread and > prospered despite inept or nonexistent marketing, uncertain support, and a > marked dearth of hype. > > It behooves people who aspire to design systems programming languages to > *PAY* *ATTENTION* *DAMMIT*, rather than just casting aspersions on the > intelligence and judgement of the customer. It is their own damn fault; > their languages keep failing, and C keeps succeeding despite its nasty > flaws, because they keep ignoring the needs of the real language users. > People went with C because it did what they wanted, instead of telling > them they shouldn't want that. > Honestly, I don't think there will be a language to supplant C as a *systems* programming language in general any time soon. Frankly, systems programming too frequently requires breaking the rules that other languages commonly enforce. There have been a lot of great languages developed out there for specific tasks. Perl is gorgeous for text processing, as is python I've heard. BASH is fair for simple task automation, and tolerable for slightly more complicated tasks. Matlab is a GODSEND for anyone doing algorithm prototyping and other kinds of scientific computation. Java is worlds beyond C++ when it comes to OOP. Hell, even Prolog and the many species of LISP-type-languages are interesting in their own right (though not terribly useful in my mind). The point though is that for applications where you need the kind of flexibility (or rope...heh) that C offers, there has yet to be any good substitutes. But if you fit well into a specific category of application development then there is a whole host of better choices for you. For instance, next major GUI application I write will probably be in Java or maybe C++ with a good widget library (GTKmm). It just hurts too much to write GUI apps in C. > > Years ago, Philipe Khan of Borland said that 'C is a disease and the > > Americans are spreading it.' Maybe he had this kind of thing in mind. > > I don't think it is impossible to keep C's virtues while eliminating its > more grievous faults. But it will not be done by people who look down > their long aristocratic noses at C, and scorn it as a peasant's language > of no interest to them. One mans grievous fault is another mans shiningly useful feature. Language wise I think there is really only a few things that can/should be done to improve C. Largely they involve incorporating the more sensible improvements from C++ and dropping most of the cruft. I.E. compile-time operator overloading would be nice but templates are horrendous. Beyond that though I think C would benefit most from more code reuse. Why is it that everyone has their own C libraries to handle strings? Things like Glib need to be more widely used, because otherwise we're all just reinventing the wheel and reproducing the bugs. -- Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

C considered harmful: was Debian attacker may have used new exploit
by marcus.brubaker-H217xnMUJC0sA/PxXw9srA＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 2003-12-03 at 22:55, Peter Hiscocks wrote: > OK, I hate to flog a dead horse but really: > Hmmmm, this is likely to start a looooong drawn out flame thread. Language arguments almost always do. So, with trying to prevent that in mind, I will avoid standing up for my general language of choice and instead offer an alternative. > This exploit, like others against Unix machines many years ago, was based on > a buffer overflow dumping the user into supervisor space. This, in turn, is > a direct result of the fact that the C programming language does not check > or enforce limits on a string length or buffer size - that's left up to the > individual programmer. > > Surely, given the importance of security, it should be possible to fix the C > language (or my preference, use a different one) to do systems programming. > After all, C is not so much a systems programming language as a high-level > version of assembly language. > "Fixing" C in the sense you're imagining will never happen and people often do use other languages for specific tasks. However, other languages are not immune to buffer overflows as most of them are actually written in C themselves. The better solution is things like stackguard[1] and execshield[2] which actually fix the root problem: the stack should NOT be executable and neither should most of the heap and likewise portions of memory which are actively executable shouldn't be writable from userspace. > (Incidentally, a former profs at Ryerson, Heather Hinton, was working on > such a mechanism to prevent stack overflows. I guess it's never been widely > adopted.) Hinton...any relation to Geoffrey Hinton? At any rate, many people have (and continue) to work on stack guards and similar solutions. See [1] and [2]. As with all security measures, its just a question of getting people to use them. -- Marcus Brubaker <marcus.brubaker-H217xnMUJC0sA/PxXw9srA at public.gmane.org> [1] http://www.immunix.org/stackguard.html [2] http://seclists.org/lists/linux-kernel/2003/May/0371.html and http://people.redhat.com/mingo/exec-shield/ -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

C considered harmful: was Debian attacker may have used new exploit
by henry-lqW1N6Cllo0sV2N9l4h3zg＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, 3 Dec 2003, Peter Hiscocks wrote: > This exploit, like others against Unix machines many years ago, was based on > a buffer overflow dumping the user into supervisor space. Actually, no, as I understand it (with the caveat that I haven't really gone investigating), this one is *not* a buffer overflow, exactly. It's the result of *integer* overflow in (essentially) a buffer-overflow check. A language with automatic buffer-overflow checks could easily have the same vulnerability, if the implementor wasn't careful. > This, in turn, is > a direct result of the fact that the C programming language does not check > or enforce limits on a string length or buffer size - that's left up to the > individual programmer. As has often been said, C gives you all the rope you need to hang yourself. > After all, C is not so much a systems programming language as a high-level > version of assembly language. Oddly enough, it has pushed most "real" systems programming languages out of the business. And this is *not* because of sharp marketing tactics or firm backing by a big organization or dot-com hype -- quite the contrary. It succeeded because people with work to do find it easier to get results in C than in "real" systems programming languages, and so it spread and prospered despite inept or nonexistent marketing, uncertain support, and a marked dearth of hype. It behooves people who aspire to design systems programming languages to *PAY* *ATTENTION* *DAMMIT*, rather than just casting aspersions on the intelligence and judgement of the customer. It is their own damn fault; their languages keep failing, and C keeps succeeding despite its nasty flaws, because they keep ignoring the needs of the real language users. People went with C because it did what they wanted, instead of telling them they shouldn't want that. > Years ago, Philipe Khan of Borland said that 'C is a disease and the > Americans are spreading it.' Maybe he had this kind of thing in mind. I don't think it is impossible to keep C's virtues while eliminating its more grievous faults. But it will not be done by people who look down their long aristocratic noses at C, and scorn it as a peasant's language of no interest to them. Henry Spencer henry-lqW1N6Cllo0sV2N9l4h3zg at public.gmane.org -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0

Debian attacker may have used new exploit
by jmm-TU2q2He6PgRlD5gtYiU6kEEOCMrvLtNR＠public.gmane.org 03 Dec '03

03 Dec '03

On Wed, Dec 03, 2003 at 05:11:38PM -0500, JoeHill wrote: > I nowhere engaged in such a practice, I argued against *any* limits being placed > on the free exchange of information, for reasons I have already stated, and > have provided references for. Not once did I claim or assume that the "other > side" of the argument was no disclosure at all. As Robert suggested would > happen, this *is* getting repetitive, and now you are accusing me of something > you seem to be doing yourself. > > So, to end the thread, placing limits on the free exchange of any information, > whether it is for some limited time or perceived good, is the kind of slippery > slope that leads to a regime **Hitler** would have loved ;-) You have argued against *any* limit. Until the "slippery slope" statment above, I have not seen any *justification* for such an argument that actually applied to delayed disclosure (a temporary limit for a deliberate purpose) rather than *only* to non-disclosure. A slippery slope argument is not particularly compelling unless you go on to show that there is difficulty in choosing any point in between the extremes and sticking to that point. As long as people *do* always come to the point where they disclose the problem, there is no slippery slope. Different people may have different amounts of leniency, but the end result is the same except for the exact timing. If you have any argument that justifies immediate disclosure over delayed disclosure, please state it. What penalty is there for making it possible to have a fix for a problem available before the general publication of the problem, as long as the publication will happen in a relatively short time frame? What benefit comes from not providing a window of time for fixing the problem before disclosure? But skip "non-disclosure is bad" arguments - they do not say anything against delayed disclosure. And skip "nobody has proved it is necessary" arguments - they at most say that immediate disclosure might not cause damage, but they do not state any advantage for immediate disclosure. -- The Toronto Linux Users Group. Meetings: http://tlug.ss.org TLUG requests: Linux topics, No HTML, wrap text below 80 columns How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml

1 0