and kde already maintains their own qt-copy CVS, which, while it generally isn't too divergent from TT's official versions does sometimes get things like font-AA first. The infrastructure for it to be a real fork is quite soundly in place, should such a move every be necessary (hopefully it never will be though!)
afaik, this bug has been actively exploited for at least a week or more - there was a link being broadly crossposted in the diablo2 forums that led to a page which tried it (or something very like it, but I suspect the same hole) and passively installed a trojan.
So if it's the same bug, I saw attempts to exploit it a week or more ago, and I think the posts were older than that. Still nice that they admitted it and fixed it though.
most good players won't read these either - since they check the error-protection bits just like a CDROM would:-)
you have to play these in drives that are sloppy and just assume things worked because they won't check out when the consistency checks are made - that's what stops a normal CDROm from reading them.
kfm used to, and that pissed people off so now it doesn't (isn't it nice to listen to your users?).
So now konqueror is just a nice filemanager, kdesktop puts the icons on your desktop if you want them there. Both use the same libraries, inherit their views from the same classes, etc so it's still consistent, and you can run one, the other, or both at your choice. If they want to talk to each other, that's what DCOP is for.
Makes using konqueror as a nice filemanager and web browser outside of KDE positively nice:-)
KDE really doesn't force you to use their WM either. It was true to some extent in KDE1 that stupid things would happen (like kpanel launching for no obvious reason) if you didn't run the full DE, but I've been happily using KDE{2.0-pre,2.0,2.1-pre} apps in blackbox for quite some time now.
KDE has some classes to help apps find their files via configureable search paths - basically, you just set $KDEDIRS to something like/usr:/usr/local:/usr/local/kthingy
and it checks them in that order. Works like a charm.
As far as interapplication communication, that's all done via the dcopserver, which uses a UNIX domain socket that lives somewhere in ~/.kde I think.
I have the bulk of my KDE apps installed into/usr (as they were packaged) but have had no troulbe installing others elsewhere if they came from source. It's simple enough (except for the odd app with a crappy configure script that won't do --prefix right, but those are rare and the apps generally still runs once I do get the files where I want them)
Re:Filesystem inaccuracy
on
2.2 vs 2.4
·
· Score: 2
can't be, that's not supported in-kernel yet (there are finally some userspace tools like the old hfsutils for it, but that's all afaik).
well, to simplify matters quite a bit (though allowing a miniscule chance that a malicous key could generate the same fingerprint, this would be *really* hard to do), just send them the key fingerprint and let them compare the fingerprint shown by their client during that first connection with what you told them to expect.
of course it has to run as root - how else could it give your your own account perms when you connect to it (instead of whatever menail ones it would otherwise have)?
this is not a problem in ssh.
this is not a problem in ssl.
It is a very old, very well known attack approach, which both already guard against (that's what the 'host key changed' message is all about in ssh). If you see that message and haven't been notified (and sent a new key fingerprint to veryfy against by the admins), you *MUST* assume that a man-in-the-middle attack is being employed - it's what the message means!
Someone in the middle of your connection pretends to be the server to you, and pretends to be the client to your server. Poof, two valid connections, he forwards your data (he has it in plaintext, as he is your server), and you notice only one thing to tell you that something is amiss - that he *did't* know the right server key (ssh has caches it from previous connections to that server's IP, ssl can check the CA's notes about whose key it is) and had to send you a different one.
So your client warns you that the key has been changed. You need to get the key fingerprint from the server admin (out-of-band, not over the same potentially compromised network) and compare it to the one you recieved (you did do that when you first connected to the machine too, right? it should have come along with your account credentials, if not you needed to ask for it if you cared a bit about security) and make sure it matches the new print the server is offering.
to get a fingerprint for a host, use ssh-keygen -l -f/etc/ssh/ssh_host_key
SSL is in a similar situation - the key bears the DNS name if the site it is for, and your browser will warn you if it recieves a key for the wrong site, or not signed by a recognized CA. You didn't turn those off did you? If not, then one or the other will come up when confronted with a man-in-the-middle attack (either he'll send a properly signed key, but not for the right site, or he'll have a forged and unsigned key for the site you were really going to) and you'll know what you're facing.
for ssl, if in doubt, click the little padlock in your browser, and read the key - see that it's for the site you think it is, and signed by a recognized CA.
If you don't use these tools correctly, you may as well not use them at all. Everything is in place to detect these attacks (which are not new), but if people simply ignore warning messages that indicate the presence of known attacks, there's not much else that can be done
I'm planning to try a NeXT-ish browse mode for konqueror as soon as I get a little time and here... it's looking quite simple to do, so I'm hopeful I may even get it into 2.1.
Never seen the Amiga or RiscOS ones though, any info?
I think that the debian packages (at least) are including some pre-realse work with this too. At least, it was noted in the changelog a while back that we were now 'including render extension'.
umm... you have a debug build.
There is a hell of a lot of fairly useless junk in a debug build (yes, that's still the default)
read the./configure --help, turn off debug, turn off tests, enable optimization, (if you want to) turn off mailnews, and see a much more reasonable build:-)
KDE2 gets built with them off - however, Qt seems to enable them by default, even though it doesn't use them.
The info about how bug of improvement is very real - Qt shed about 3.2 megs on my system, and kde2 as a whole over 15 megs (apparently the exception table is per-process and is not shared memory)
Here is a patch against qt2.2.1 to disable the exception code on linux/g++
Slashdot Mirror
and kde already maintains their own qt-copy CVS, which, while it generally isn't too divergent from TT's official versions does sometimes get things like font-AA first. The infrastructure for it to be a real fork is quite soundly in place, should such a move every be necessary (hopefully it never will be though!)
afaik, this bug has been actively exploited for at least a week or more - there was a link being broadly crossposted in the diablo2 forums that led to a page which tried it (or something very like it, but I suspect the same hole) and passively installed a trojan.
So if it's the same bug, I saw attempts to exploit it a week or more ago, and I think the posts were older than that. Still nice that they admitted it and fixed it though.
most good players won't read these either - since they check the error-protection bits just like a CDROM would :-)
you have to play these in drives that are sloppy and just assume things worked because they won't check out when the consistency checks are made - that's what stops a normal CDROm from reading them.
licq (http://www.licq.org/) all the way - I can't stand the real Win32 client (or mac, but macos has it's own unofficial ones too).
you saw NFSv3, unless you saw something extra-special :-).
v3 was new in 2.4 and still has a special config option.
QT 2.3 is the bomb :-)
This looks *really* nice.
actually, konqueror doesn't.
:-)
kfm used to, and that pissed people off so now it doesn't (isn't it nice to listen to your users?).
So now konqueror is just a nice filemanager, kdesktop puts the icons on your desktop if you want them there. Both use the same libraries, inherit their views from the same classes, etc so it's still consistent, and you can run one, the other, or both at your choice. If they want to talk to each other, that's what DCOP is for.
Makes using konqueror as a nice filemanager and web browser outside of KDE positively nice
KDE really doesn't force you to use their WM either. It was true to some extent in KDE1 that stupid things would happen (like kpanel launching for no obvious reason) if you didn't run the full DE, but I've been happily using KDE{2.0-pre,2.0,2.1-pre} apps in blackbox for quite some time now.
Works great.
KDE has some classes to help apps find their files via configureable search paths - basically, you just set $KDEDIRS to something like /usr:/usr/local:/usr/local/kthingy
/usr (as they were packaged) but have had no troulbe installing others elsewhere if they came from source. It's simple enough (except for the odd app with a crappy configure script that won't do --prefix right, but those are rare and the apps generally still runs once I do get the files where I want them)
and it checks them in that order. Works like a charm.
As far as interapplication communication, that's all done via the dcopserver, which uses a UNIX domain socket that lives somewhere in ~/.kde I think.
I have the bulk of my KDE apps installed into
can't be, that's not supported in-kernel yet (there are finally some userspace tools like the old hfsutils for it, but that's all afaik).
most of that memory is pixmaps that the server is holding on behalf of the other apps on your system.
so, the earlier poster is correct when he talked about 'memory wrapped up in the X process'
well, to simplify matters quite a bit (though allowing a miniscule chance that a malicous key could generate the same fingerprint, this would be *really* hard to do), just send them the key fingerprint and let them compare the fingerprint shown by their client during that first connection with what you told them to expect.
their browsers do... and warn them... unless they click OK and continue anyway.
In which case they deserve whatever they get.
of course it has to run as root - how else could it give your your own account perms when you connect to it (instead of whatever menail ones it would otherwise have)?
this is not a problem in ssh.
/etc/ssh/ssh_host_key
this is not a problem in ssl.
It is a very old, very well known attack approach, which both already guard against (that's what the 'host key changed' message is all about in ssh). If you see that message and haven't been notified (and sent a new key fingerprint to veryfy against by the admins), you *MUST* assume that a man-in-the-middle attack is being employed - it's what the message means!
Someone in the middle of your connection pretends to be the server to you, and pretends to be the client to your server. Poof, two valid connections, he forwards your data (he has it in plaintext, as he is your server), and you notice only one thing to tell you that something is amiss - that he *did't* know the right server key (ssh has caches it from previous connections to that server's IP, ssl can check the CA's notes about whose key it is) and had to send you a different one.
So your client warns you that the key has been changed. You need to get the key fingerprint from the server admin (out-of-band, not over the same potentially compromised network) and compare it to the one you recieved (you did do that when you first connected to the machine too, right? it should have come along with your account credentials, if not you needed to ask for it if you cared a bit about security) and make sure it matches the new print the server is offering.
to get a fingerprint for a host, use ssh-keygen -l -f
SSL is in a similar situation - the key bears the DNS name if the site it is for, and your browser will warn you if it recieves a key for the wrong site, or not signed by a recognized CA. You didn't turn those off did you? If not, then one or the other will come up when confronted with a man-in-the-middle attack (either he'll send a properly signed key, but not for the right site, or he'll have a forged and unsigned key for the site you were really going to) and you'll know what you're facing.
for ssl, if in doubt, click the little padlock in your browser, and read the key - see that it's for the site you think it is, and signed by a recognized CA.
If you don't use these tools correctly, you may as well not use them at all. Everything is in place to detect these attacks (which are not new), but if people simply ignore warning messages that indicate the presence of known attacks, there's not much else that can be done
kde2's konqueror (a very nice browser IMO) alreday has this, as well as selective cookie blocking and loads of other per-site preferences.
As a matter of fact, GETOSPACE works just fine (I know this, since I was down in dmasound recently to fix kde2's soundserver.
:-) If you know of any other problems, drop me a line at puetzk@iastate.edu
I also hooked up GETCAPS, and fixed a small bug on our SETFRAGMENT behavior.
So hopefully, it's all better now
I use ogg vorbis myself without any trouble at all, though I haven't ever tried ogg123 (I ues the xmms plugin). Will have to investigate that.
I'm planning to try a NeXT-ish browse mode for konqueror as soon as I get a little time and here... it's looking quite simple to do, so I'm hopeful I may even get it into 2.1.
Never seen the Amiga or RiscOS ones though, any info?
I think that the debian packages (at least) are including some pre-realse work with this too. At least, it was noted in the changelog a while back that we were now 'including render extension'.
I would also be very interested in seeing similar graphs (preferably from the same source) made with Vorbis encoders, to see how they stack up.
ah, so what you're wanting is apt-get (the debian GNU/linux package manager).
:-)
I can apt-get install task-kde (or use any of the GUI's for apt).
Or I can apt-get install kword
or konsole
or konqueror
it will figure out what other library packages it needs, and just take care of it
umm... you have a debug build. There is a hell of a lot of fairly useless junk in a debug build (yes, that's still the default) read the ./configure --help, turn off debug, turn off tests, enable optimization, (if you want to) turn off mailnews, and see a much more reasonable build :-)
RC1 was rejected, so the schedule slipped a week to make room for an RC2
KDE2 gets built with them off - however, Qt seems to enable them by default, even though it doesn't use them.
The info about how bug of improvement is very real - Qt shed about 3.2 megs on my system, and kde2 as a whole over 15 megs (apparently the exception table is per-process and is not shared memory)
Here is a patch against qt2.2.1 to disable the exception code on linux/g++
diff -ru qt2.2-2.2.1.orig/configs/linux-g++-shared qt2.2-2.2.1/configs/linux-g++-shared
--- qt2.2-2.2.1.orig/configs/linux-g++-shared Tue Oct 10 21:28:49 2000
+++ qt2.2-2.2.1/configs/linux-g++-shared Tue Oct 10 21:33:10 2000
@@ -76,7 +76,7 @@
SYSCONF_LINK_LIB_STATIC = rm -f $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) ; \
$(SYSCONF_AR) $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) $(OBJECTS) $(OBJMOC)
# Compiling application source
-SYSCONF_CXXFLAGS = -pipe -O2
+SYSCONF_CXXFLAGS = -pipe -O2 -fno-exceptions
SYSCONF_CFLAGS = -pipe -O2
# Default link type (static linking is still be used where required)
SYSCONF_LINK_LIB = $(SYSCONF_LINK_LIB_SHARED)
diff -ru qt2.2-2.2.1.orig/configs/linux-g++-shared-debug qt2.2-2.2.1/configs/linux-g++-shared-debug
--- qt2.2-2.2.1.orig/configs/linux-g++-shared-debug Wed Oct 4 04:55:22 2000+++ qt2.2-2.2.1/configs/linux-g++-shared-debug Tue Oct 10 21:34:49 2000
@@ -76,7 +76,7 @@
SYSCONF_LINK_LIB_STATIC = rm -f $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) ; \
$(SYSCONF_AR) $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) $(OBJECTS) $(OBJMOC)
# Compiling application source
-SYSCONF_CXXFLAGS = -pipe -g
+SYSCONF_CXXFLAGS = -pipe -g -fno-exceptions
SYSCONF_CFLAGS = -pipe -g
# Default link type (static linking is still be used where required)
SYSCONF_LINK_LIB = $(SYSCONF_LINK_LIB_SHARED)
diff -ru qt2.2-2.2.1.orig/configs/linux-g++-static qt2.2-2.2.1/configs/linux-g++-static
--- qt2.2-2.2.1.orig/configs/linux-g++-static Tue Oct 10 21:28:49 2000
+++ qt2.2-2.2.1/configs/linux-g++-static Tue Oct 10 21:34:06 2000
@@ -76,7 +76,7 @@
SYSCONF_LINK_LIB_STATIC = rm -f $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) ; \
$(SYSCONF_AR) $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) $(OBJECTS) $(OBJMOC)
# Compiling application source
-SYSCONF_CXXFLAGS = -pipe -O2
+SYSCONF_CXXFLAGS = -pipe -O2 -fno-exceptions
SYSCONF_CFLAGS = -pipe -O2
SYSCONF_LINK_LIB = $(SYSCONF_LINK_LIB_STATIC)
SYSCONF_LINK_TARGET = $(SYSCONF_LINK_TARGET_STATIC)
diff -ru qt2.2-2.2.1.orig/configs/linux-g++-static-debug qt2.2-2.2.1/configs/linux-g++-static-debug
--- qt2.2-2.2.1.orig/configs/linux-g++-static-debug Wed Oct 4 04:55:21 2000+++ qt2.2-2.2.1/configs/linux-g++-static-debug Tue Oct 10 21:34:32 2000
@@ -76,7 +76,7 @@
SYSCONF_LINK_LIB_STATIC = rm -f $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC)
; \
$(SYSCONF_AR) $(DESTDIR)$(SYSCONF_LINK_TARGET_STATIC) $(OBJECTS) $(OBJMOC)
# Compiling application source
-SYSCONF_CXXFLAGS = -pipe -g
+SYSCONF_CXXFLAGS = -pipe -g -fno-exceptions
SYSCONF_CFLAGS = -pipe -g
SYSCONF_LINK_LIB = $(SYSCONF_LINK_LIB_STATIC)
SYSCONF_LINK_TARGET = $(SYSCONF_LINK_TARGET_STATIC)
parent is false - just check http://gcc.gnu.org/steering.html and you'll see that both of these people are still listed on the committee