Re: OT: Programming portability
Chris Zakelj wrote: I'm curious as to how programs actually get ported from one OS to another, Yes, some techniques make the job easier, but it depends on what the program does and whether you're doing a one-way port or an ongoing port. The following aren't necessarily the only ways to do porting, but it's how the Open* Portable projects are done. If it's a one-way port (ie the port will be done once and thereafter maintained separately), the usual method is to just change what needs changing to suit the target platform. This is effectively what happened when the original ssh-1.2.12 code was 'ported' to OpenBSD. In the case of OpenSSH and OpenNTPD Portable, they're ongoing ports (ie changes are regularly sync'ed from OpenBSD's to Portable's). There are 2 main ways to accomplish this: sprinkle the code with #ifdefs or implement the missing functionality in a compatibilty layer. In the Portable projects, the first preference is leave the common code alone and implement the required functionality in a portability layer. This has the advantage of keeping the common code clean and if done properly the components are reusable. (A number of functions used by OpenNTPD Portable came unmodified from OpenSSH Portable). Sometimes that's not possible or more effort than it's worth, so in those cases an #ifdef is used which imposes an ongoing maintenance cost (ie next time a change is made in that area in the main code, you'll have to manually resolve conflict when syncing changes). For example: OpenNTPD Portable was ported to run on QNX4 (a POSIXish embedded system) by Anthony O.Zabelin. The 2 main missing pieces were the adjtime() and poll() calls. Simplifying somewhat, the code that used adjtime looked like this: d_to_tv(d, tv); if (adjtime(tv, NULL) == -1) log_warn(adjtime failed); If we had used the #ifdef technique, that would have changed to something like this: #ifndef __QNX__ d_to_tv(d, tv); if (adjtime(tv, NULL) == -1) log_warn(adjtime failed); #else usec = (int)(d * 100); if (qnx_adj_time(usec, ADJUST_RATE, NULL, NULL) == -1) log_warn(qnx_adj_time failed); #endif Now one or two of those aren't too bad, but it rapidly becomes difficult to follow once you add a few more to the same piece of code. Instead, Anthony wrote a stand-alone replacement adjtime() function which is in the portability layer (openbsd-compat/port-qnx.c). This had a higher initial cost (it's 23 lines of code in a single function plus a Makefile change instead of 6 lines listed above) but it leaves the main code unchanged. It can also be tested separately and is reusable. I took the same approach with poll() and built a replacement on top of select(), which QNX4 did have. Hey presto, it now worked on QNX4, and the codebase is no harder to maintain. and if certain directions are easier than others. In general, the difficulty is directly proportional to how different the target platform is compared to the platforms already supported in the area in which the program operates. In most current OSes there's a slow convergance toward common APIs for standard languages so if you stick to those standard APIs you life will be easier. Newer/more featureful - older/less featureful is usually harder than the other way around unless the program was originally written to stick to a common subset. Beyond that it depends on the program. Porting a simple text filter from a bleeding-edge Linux to 10-year old BSD is likely to be simple, but other programs may be difficult to impossible. That is, how does one figure out what needs to be changed in order to make OpenNTPD work on Linux? I had the advantage of having worked on Portable OpenSSH for a couple of years so had a reasonable idea what to expect, so for OpenNTPD I just copied the code onto a Linux box, hacked the BSDisms out of the Makefile and tried to compile it. This highlighted some obvious problems (eg missing strl* functions, the lack of sa_len in struct sockaddr). I fixed these (stole the strl* functions from OpenSSH and changed sa-sa_len into SA_LEN(sa)) and tried again. After a few iterations of this process it compiled and after a couple more, amazingly enough, it worked. At that point I added basic autoconf support, put a tarball on my web page and mentioned it on [EMAIL PROTECTED] After that, other folks and myself repeated the process on other platforms, slowly expanding the list that it would run on. (The platform list on openntpd.org is in chronological order, earliest first). Is it generally easier to move a program from $some_bsd to $some_other_os, or from $some_other_os to $some_bsd? Depends on the type of program, and in particular what OS-level services it uses. OpenSSH, for example, has to deal with user authentication for which there is a large amount of variance between
Re: Upgrade to 3.7 and VPN no longer works
apply all patches listed on the errata pages for your 3.4 and 3.6 machines. There are patches for this issue. On Sun, Jun 19, 2005 at 01:34:06PM +1000, Dave Harrison wrote: I just upgraded my firewall to 3.7, but I've found my VPN is now not working. I keep seeing NAT detected messages, but both machines have real IPs so it doesn't make sense. The client machine is a 3.6 install, and the server machine was a 3.4 machine which I used the media CD to ...
Re: OT: Programming portability
On Sun, 19 Jun 2005 16:23:16 +1000, Darren Tucker wrote: Chris Zakelj wrote: I'm curious as to how programs actually get ported from one OS to another, Yes, some techniques make the job easier, but it depends on what the program does and whether you're doing a one-way port or an ongoing port. The following aren't necessarily the only ways to do porting, but it's how the Open* Portable projects are done. If it's a one-way port (ie the port will be done once and thereafter maintained separately), the usual method is to just change what needs changing to suit the target platform. This is effectively what happened when the original ssh-1.2.12 code was 'ported' to OpenBSD. In the case of OpenSSH and OpenNTPD Portable, they're ongoing ports (ie changes are regularly sync'ed from OpenBSD's to Portable's). There are 2 main ways to accomplish this: sprinkle the code with #ifdefs or implement the missing functionality in a compatibilty layer. In the Portable projects, the first preference is leave the common code alone and implement the required functionality in a portability layer. This has the advantage of keeping the common code clean and if done properly the components are reusable. (A number of functions used by OpenNTPD Portable came unmodified from OpenSSH Portable). Sometimes that's not possible or more effort than it's worth, so in those cases an #ifdef is used which imposes an ongoing maintenance cost (ie next time a change is made in that area in the main code, you'll have to manually resolve conflict when syncing changes). For example: OpenNTPD Portable was ported to run on QNX4 (a POSIXish embedded system) by Anthony O.Zabelin. The 2 main missing pieces were the adjtime() and poll() calls. Simplifying somewhat, the code that used adjtime looked like this: d_to_tv(d, tv); if (adjtime(tv, NULL) == -1) log_warn(adjtime failed); If we had used the #ifdef technique, that would have changed to something like this: #ifndef __QNX__ d_to_tv(d, tv); if (adjtime(tv, NULL) == -1) log_warn(adjtime failed); #else usec = (int)(d * 100); if (qnx_adj_time(usec, ADJUST_RATE, NULL, NULL) == -1) log_warn(qnx_adj_time failed); #endif Now one or two of those aren't too bad, but it rapidly becomes difficult to follow once you add a few more to the same piece of code. Instead, Anthony wrote a stand-alone replacement adjtime() function which is in the portability layer (openbsd-compat/port-qnx.c). This had a higher initial cost (it's 23 lines of code in a single function plus a Makefile change instead of 6 lines listed above) but it leaves the main code unchanged. It can also be tested separately and is reusable. I took the same approach with poll() and built a replacement on top of select(), which QNX4 did have. Hey presto, it now worked on QNX4, and the codebase is no harder to maintain. and if certain directions are easier than others. In general, the difficulty is directly proportional to how different the target platform is compared to the platforms already supported in the area in which the program operates. In most current OSes there's a slow convergance toward common APIs for standard languages so if you stick to those standard APIs you life will be easier. Newer/more featureful - older/less featureful is usually harder than the other way around unless the program was originally written to stick to a common subset. Beyond that it depends on the program. Porting a simple text filter from a bleeding-edge Linux to 10-year old BSD is likely to be simple, but other programs may be difficult to impossible. That is, how does one figure out what needs to be changed in order to make OpenNTPD work on Linux? I had the advantage of having worked on Portable OpenSSH for a couple of years so had a reasonable idea what to expect, so for OpenNTPD I just copied the code onto a Linux box, hacked the BSDisms out of the Makefile and tried to compile it. This highlighted some obvious problems (eg missing strl* functions, the lack of sa_len in struct sockaddr). I fixed these (stole the strl* functions from OpenSSH and changed sa-sa_len into SA_LEN(sa)) and tried again. After a few iterations of this process it compiled and after a couple more, amazingly enough, it worked. At that point I added basic autoconf support, put a tarball on my web page and mentioned it on [EMAIL PROTECTED] After that, other folks and myself repeated the process on other platforms, slowly expanding the list that it would run on. (The platform list on openntpd.org is in chronological order, earliest first). Is it generally easier to move a program from $some_bsd to $some_other_os, or from $some_other_os to $some_bsd? Depends on the type of program, and in particular what OS-level services it uses. OpenSSH, for example, has to deal with user authentication for which
snort homedir ?
Hi, i've installed snort and created the user/group snort. Since snort runs as a daemon a homdir is not necessary, isn't ? How can i remove / setup the user snort without a homedir ( /home/snort)? The homedir was setted-up automatically by 'adduser'. Thanks in advance mess-mate -- A horse! A horse! My kingdom for a horse! -- Wm. Shakespeare, Henry VI
Re: Eric Raymond talks about GPL and BSD licenses on MyFreeBSD.com
Johan M:son Lindman wrote: http://www.catb.org/~esr/guns/ Thanks for pointing that out, Johan. Of course, ESR being a gun nut makes his opinion about software licensing irrelevant at best, and wrong at worst. I mean, who would want the terms of a license as oppressive as the GPL written on their foreheads with an automatic gun? (Jeez, what's wrong with you people...?) Cheers Steffen.
Re: snort homedir ?
On Sun, Jun 19, 2005 at 03:17:48PM +0200, mess-mate wrote: Hi, i've installed snort and created the user/group snort. Since snort runs as a daemon a homdir is not necessary, isn't ? How can i remove / setup the user snort without a homedir ( /home/snort)? The homedir was setted-up automatically by 'adduser'. Thanks in advance Isn't this a question for a snort list? You can use vipw to change the snort users home dir to /sbin/nologin if not required. mess-mate -- A horse! A horse! My kingdom for a horse! -- Wm. Shakespeare, Henry VI
upgrading from OpenBSD/i386 from 3.3 and before by remote
Pretend for a moment I am not part of the OpenBSD team. This is completely unofficial and unsupported by the OpenBSD project. Or me. Or anyone else. I would guess a few people out there still have old OpenBSD/i386 systems which are running just fine, but are at a remote site without a serial console, and thus, unable to get over the 3.3 - 3.4 a.out to ELF transition without a trip on-site. Which, of course, you are putting off. You know you need to, but just haven't got around to it yet. Dale Rahn has written a small (COMPLETELY UNOFFICIAL) program which helps resolve that problem, and I have written up a (COMPLETELY UNOFFICIAL) overview of how to bring an a.out system to 3.7 or -current. http://www.holland-consulting.net/obsd/aout-up.html I repeat: This is completely unofficial. It is completely unsupported. If you blow out your machine using this, don't come running to us. If your boss blows out your brains after trying this, don't send your heirs running to us. If the stress of doing this upgrade causes insanity, don't come bouncing off the padded walls to us. However, it worked for me. Very well, I might add. And the process added to my bald spot, too. You've been warned. Nick. (did I mention this isn't part of the Official OpenBSD project?)
A system for patches....
Hello everybody... I had some trouble with the copy of /usr/src I fetched and so I had to refetch it. But now I'm not sure if I included all patches (even I've e.g. no em-Device (Btw: why are just critical patches listed?)). I guess there's no system to identify if somebody applied a patch or if he/she dosn't so I thought about a easy system wich could be implemented. The ports-tree uses checksums to check the integrety of a port. So why can't a script include all Checksums for e.g. patches? /usr/ports/infrastructure/out-of-date checks e.g. the packages. Somebody could write a shellscript wich includes the Checksums for a compiled (and patched) binary for each architecture. E.g. the EM-Driver... The file includes also just the Checksums for files wich where patched. That is (ofcourse) not the best solution but it could be implemented fastly and it would work. So if somebody (like me) f**ked up his copy of src he could refetch the copy and get the latest copy of that script and it would just tell me e.g. Checksum for */pci/em missmatch (I don#t know the complete path so don#t critic that). That would work if the users use just make build and if they don#t play with compiler-settings. Maybe I'm wrong because I don#t know how CPU-optimize the code is so maybe the binary is a different one for e.g. AMD-Athlon CPUs (e.g. compared to INTEL P4). But that's something wich could be solved because sysctl or dmesg could be used to get the right CPU. It is NO auto-patch solution but it would help to get e.g. the critical patches and to notice if they where already apllied or not. I would be happy if somebody else (even this somebody would kill -9 my idea) would answer and tell me his oppinion but the current status sucks a lot and it could be fixed easily (I think). I repeat: It is no autopatch solution and it should just help to make sure if the patches from stable where applied already or not. Sure it wont work for users who modify some parts (e.g. Apache) but for all other users it should work fine I think.. Kind regards, Sebastian
OT: Hardware keyloggers embedded in new keyboards?
http://www.amecisco.com/faq_hardwarekeylogger.htm#Q1
Re: A system for patches....
Hi Sebastian, I had some trouble with the copy of /usr/src I fetched and so I had to refetch it. But now I'm not sure if I included all patches (even I've e.g. no em-Device I'm not quite sure what you are talking about - neither on http://www.openbsd.org/errata37.html nor on http://www.openbsd.org/errata36.html i'm aware of any reference to em(4). (Btw: why are just critical patches listed?)). The patch branch is a good choice if you want to maintain a system to be as stable as possible. You do not want to have anything patched in there unless it is critical. On top of that, developers prefer improving current code over patching old code unless there are really good reasons to patch. We should not discourage that kind of lazyness. I guess there's no system to identify if somebody applied a patch or if he/she dosn't [...] Er, well, what about reading the patch itself and looking at one of the files referenced? That way, you will find out very quickly whether the patch was applied or not. In case you fear that somebody (possibly you?) screwed up something below /usr/src, you could check using the -ctime option of find(1). That will work very well unless you have shot yourself into your own foot abusing touch(1). But when you are really worried that the copy of /usr/src you are using for your patch branch might be damaged, you should probably just mv(1) /usr/src out of the way and install a clean copy from you CDROM, then apply once more all the patches from http://www.openbsd.org/errata??.html The ports-tree uses checksums to check the integrety of a port. As far as i know, no, that's not what it does. The ports system uses checksums to check the integrity of third-party distribution files. You download those from third-party ftp servers which might be compromised. If you damage _random_ files below /usr/ports, checksums won't rescue you, as far as i know. So why can't a script include all Checksums for e.g. patches? I think that won't lead you anywhere. As long as you use the patch branch, the number of patches is small, so you can (and should) look at each individual patch anyway, just before you apply it. Thus, automation is no issue in the first place. If, by contrast, you are running -current, many things are bound to change many times. In that case, checksums won't lead to anything but bogus error messages and quite probably a maintenance nightmare. My overall impression is that you are playing around with things you would better leave alone, at least if you are trying to set up a stable system. it could be fixed easily (I think). Helping you would be easier if you explained more clearly what you are trying to accomplish and why you are patching so much that you lose track of what you are doing. Why won't just getting /usr/src from your CRDOM and applying all the (two) patches by hand work for you? Yours Ingo
OpenBSD 3.7-RELEASE hangs on install
I'm currently trying to install OpenBSD 3.7 on an old HP Vectra machine using cd37.iso, and am running into a problem: the system hangs and stops responding on the line rootdev=0x1100 rrootdev=0x2f00 rawdev=0x2f02, right before the install/upgrade/shell prompt would normally be displayed. I can't get a dmesg from the OpenBSD install boot, as I don't have a serial cable handy, but I've successfully installed NetBSD-2.0 on it previously; its dmesg is at http://pastebin.com/301984 if that's at all helpful. I'll provide any more information if needed, but I can't think of anything else at the moment. Thanks in advance.
Re: OT: Hardware keyloggers embedded in new keyboards?
On 6/19/05, Dave Feustel [EMAIL PROTECTED] wrote: http://www.amecisco.com/faq_hardwarekeylogger.htm#Q1 Why just new ones? Do you think this device is new or something? Greg
Re: A system for patches....
On Mon, Jun 20, 2005 at 01:49:47AM +0200, Ingo Schwarze wrote: ... I'm not quite sure what you are talking about - neither on http://www.openbsd.org/errata37.html nor on http://www.openbsd.org/errata36.html i'm aware of any reference to em(4). That's true, but it looks like there is a minor, unannounced patch to sys/dev/pci/if_em.c -- version 1.39 is -release, but version 1.39.2.1 is tagged for -stable. See http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_em.c (Btw: why are just critical patches listed?)). The patch branch is a good choice if you want to maintain a system to be as stable as possible. You do not want to have anything patched in there unless it is critical. And, per FAQ #5.1, the stable branch includes ...some simple fixes that do not merit an errata entry. This must be one of those. ...install a clean copy from you CDROM, then apply once more all the patches from http://www.openbsd.org/errata??.html The other choice is to follow -stable, using AnonCVS, CVSup, or CTM. ...As long as you use the patch branch, the number of patches is small, so you can (and should) look at each individual patch anyway, just before you apply it. Thus, automation is no issue in the first place. I would agree, if one is manually applying the eratta patches manually. That's not *exactly* the same as following the CVS patch branch. But when following -stable via the CVS tree, there are indeed minor fixes that are not on the errata pages; these get installed as well. ...Helping you would be easier if you explained more clearly what you are trying to accomplish and why you are patching so much that you lose track of what you are doing. I absolutely agree. Our assumption is a botched attempt at installing -stable, but we really don't know. [EMAIL PROTECTED] suggested in his thread-starting e-mail: That would work if the users use just make build and if they don#t play with compiler-settings. Best practice is to first rebuild the -stable kernel before building a -stable userland (FAQ 5.3). -Josh Grosse- Yes but that's not exactly what I think about. I think about a enviroment where e.g. multiple Boxes have to be checked and where not all Boxes have e.g. Internetacces. I thought about placing a patches37.checksum wich includes all checksumes of the files wich where changed (e.g. also the EM-Driver). So somebody could write a Perl-Script wich fetchs this file and checks the checksumms versus the local files. So an admin could download just exactly what he/she needs by hand. I think about e.g. 3rd world ppl. who a) don#t have the bandwith to get a CVS-Update e.g. every week (Modem!) or who have e.g. a limit of e.g. 1GB. If somebody with a limit of 1Gb would fetch the stable-branch e.g. every day just to get ALL possible patches wich where NOT losted he/she would waste a lot of time and also traffic (even it's compressed). As descriped the file at e.g. the OpenBSD-Webserver should contain JUSt the checksums so that the Script (as I mentioned, e.g. Perl) is able to compare the checksums. The file at the server should (ofcourse) just include the files wich changed since the release. That would enable an admin to check if his OS is up2date and include also the minor-fixes. If the comparsion of the checksums failed the Script could provide an output like: Checksum for /path/to/e.g./em_driver missmatch. So the admin would know that there's a) an update and b) that he/she didn't included it... That's the whole Idea and because the file at the server contains just the checksums of the files wich where updated it isn#t big and shouldn't hurt (bandwith, traffic..). At least this solution is faster as CVS and saves CPU,Time,RAM and Bandwith for the server. Because if there's no Update why should e.g. I use cvs -q update... to check the Src? I hope I wa sbale to tell you more exactly how I mean it. I think that solution is easy, it will work (depends to the guys who maintain the files with the checksums) and it saves memory and co at the servers because ppl. don#t have to use CVS to check-out the src every day. They just have to runt hat script and if a checksum missmatch was detected they'll run CVS anyway.. Kind regards, Sebastian
Re: OT: Hardware keyloggers embedded in new keyboards?
Dave Feustel wrote: http://www.amecisco.com/faq_hardwarekeylogger.htm#Q1 This has nothing to do with OpenBSD. It isn't new. It isn't unique. In effect, you just spammed the list, advertising someone's product. If you are going to put totally off-topic stuff on the list, how 'bout making it interesting and new? Nick.
Re: A system for patches....
[EMAIL PROTECTED] wrote: Hello everybody... I had some trouble with the copy of /usr/src I fetched and so I had to refetch it. But now I'm not sure if I included all patches (even I've e.g. no em-Device (Btw: why are just critical patches listed?)). I guess there's no system to identify if somebody applied a patch or if he/she dosn't so I thought about a easy system wich could be implemented. huh? It is trivial to figure out if a patch has already been applied. Hint: Try applying the patch again, see what happens. Why do we need a complicated system? If you didn't read the documentation on how updates work, and the difference between patches and -stable, and and and...why do you think anyone else would read the documentation on your system? The ports-tree uses checksums to check the integrety of a port. So why can't a script include all Checksums for e.g. patches? /usr/ports/infrastructure/out-of-date checks e.g. the packages. Somebody could write a shellscript wich includes the Checksums for a compiled (and patched) binary for each architecture. E.g. the EM-Driver... The file includes also just the Checksums for files wich where patched. That is (ofcourse) not the best solution but it could be implemented fastly and it would work. So if somebody (like me) f**ked up his copy of src he could refetch the copy and get the latest copy of that script and it would just tell me e.g. Checksum for */pci/em missmatch (I don#t know the complete path so don#t critic that). Let's see... You want something that will only fetch the files which have been updated. You probably want it to respect any changes in your local tree. Might as well throw in the ability to see diffs between any two versions of a file.. and we now have invented... CVS(1)! (yeah, there are a lot of other features there, too). There already *is* a system... But, you have to read the documentation and learn how other people do things on their project...not just expect them to reinvent the world for how you thought of doing it differently. Nick.
IPSec Vulnerabilidade
Alguim sabe como solucionar a Vulnerabilidade encontrada no protocolo ESP do IPSec ? Andri
Re: A system for patches....
On Mon, Jun 20, 2005 at 03:13:31AM +0200, [EMAIL PROTECTED] wrote: I think about e.g. 3rd world ppl. who a) don#t have the bandwith to get a CVS-Update e.g. every week (Modem!) or who have e.g. a limit of e.g. 1GB. With multiple machines to support, with minimal access to the Internet: 1) Install -release from CD 2) Install source from CD 3) Apply patches from errata If you have multiple machines with the same architecture, you could build releases and do upgrades if you wished. If so, see FAQ section 5. This is *not* following -stable, as CVS is not used and the CVS tree is not being updated over the network. Instead, this is just applying critical security, reliability, and stability patches.
Re: S-Video TV Hookup
So there is currently no driver working for OpenBSD that allows TV-out with a ATI Mobility M3? I did look into the gatos program, and I got an error message saying I needed an updated linux kernel. How do I go about using the ports copy of gatos-bin? I extracted the ports file in the /home directory and went into the gatos-bin directory and typed make, but it didn't work. Also, if gatos would work, how would I configure it for video-out? Would it automatically start with XFree, or would I have to start it with some command?
Re: OT: Hardware keyloggers embedded in new keyboards?
I'm fairly sure this is a hoax. I have seen this referenced several times over the past few weeks and I have seen no evidence to indicate and truth to the matter. Apart from the obvious legal implications outside of the US how long do you think Dell, HP or any other manufacturer would have customers for if this were true? See: http://www.snopes.com/computer/internet/dellbug.asp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Feustel Sent: Monday, 20 June 2005 3:06 PM To: Greg Thomas Cc: OpenBSD-Misc Subject: Re: OT: Hardware keyloggers embedded in new keyboards? On Sunday 19 June 2005 07:24 pm, Greg Thomas wrote: On 6/19/05, Dave Feustel [EMAIL PROTECTED] wrote: http://www.amecisco.com/faq_hardwarekeylogger.htm#Q1 Why just new ones? Do you think this device is new or something? Greg The device is obviously not new. What *is* new is that it is being installed as oem equipment inside of keyboards for HP and Dell systems and also inside of 'used keyboards which can be unobtrusively switched in for older keyboards. Then the companies doing the switching can secretly monitor all the keystrokes of the user, picking up everything the user types. There is no way to detect the keylogger short of opening up the keyboard. Shortly I predict the keylogging functiion will be incorporated into the keyboard cpu so that even opening up the keyboard will not permit the presence of the logger to be detected. What's new is that this functionality now comes builtin to new systems, possibly at the behest of Homeland Security, which would in that case know the password needed to retrieve the logged keystrokes. So far I see no defense against this spying technique of password capture. Dave
Re: OT: Hardware keyloggers embedded in new keyboards?
Dave Feustel wrote: The device is obviously not new. What *is* new is that it is being installed as oem equipment inside of keyboards for HP and Dell systems and also inside of 'used keyboards which can be unobtrusively switched in for older keyboards. Then the companies doing the switching can secretly monitor all the keystrokes of the user, picking up everything the user types. There is no way to detect the keylogger short of opening up the keyboard. Shortly I predict the keylogging functiion will be incorporated into the keyboard cpu so that even opening up the keyboard will not permit the presence of the logger to be detected. What's new is that this functionality now comes builtin to new systems, possibly at the behest of Homeland Security, which would in that case know the password needed to retrieve the logged keystrokes. So far I see no defense against this spying technique of password capture. If you haven't noticed, companies (probably driven by lawyer paranoia) have been becoming more and more aware of the problems associated with employees misusing email. While as a person I find this rather intrusive and annoying, as an employee and (I shudder to think) potential PHB in 40 years, I find nothing wrong with it. My continued employment depends, in part, on the positive public image my predecessors have spent years building up, and to have it destroyed by a couple of people using company resources in inappropriate ways would really tick me off. Do they have a right to see what I do at home? Hell no, it's not their resources I'm using. But when I'm at the office, they've got every right, because it's their equipment, and their bandwidth. As for the homeland security argument, do you have any idea how much raw data they'd have to sift through before coming to something appearing to be a password? This really wanders into the realm of only the criminals have something to fear, simply because monitoring every computer user in the country would be a task only HAL could perform... and we all know how well that turned out.
