No, Windows Vista failed because of massive bloatware, continuing failures to properly _use_ the new security features, the redesigned GUI's that Microsoft failed to document or use consistently, massive overuse of RAM for features no one except Microsoft wanted (such as the hideous search handling), and the plans to include WinFS, which distorted quite a few filesystem components but turned out to be an exceptionally bad idea and was thrown out. (XML-based filesystems: how foolish can you be?)
Windows 7 is taking over Windows Vista, as it should. It's also finally cutting into Windows XP because XP has been lacking the few features that people actually wanted, such as completely discarding Internet Explorer 6, vendor support for 64-bit drivers, and better support for multiple cores.
Oh, my. That depends on if you can, and are willing, to work as a long-term employee. I've certainly met a few brilliant people who do quite well at short-term, high intensity projects, but who chafe under longer-term projects. As a consultant, they can go in, work on a complex project that requires their expertise short-term, and hand off the project at the end. This is particularly true for some network engineers and website designers and storage engineers I've met in the last 5 years, who could give a company help setting up new facilities and were happy to take fairly large paychecks, get out when it started getting dull and mundane, and move on to another project. But they were able to charge considerably more than my significant salary because of their level of expertise, and their focus on a specific project.
A few were complete failures, but some of them were pleasures to work with and introduced _me_ to some new approaches and technologies I'd had no opportunity to explore: those few were well worth the high consulting fees to us, but we or our partners didn't need their skills full-time, so did not try to hire them permanently.
And from harsh experience, I'd like to point out that that "possibily in tome to earn more" is bait on the hook to actually work for _less_. Health insurance, travel allowances, life insurance, 401K matching funds, vacation time, and unemployment can all add up to quite a lot of money a contractor won't get, especially since the time in between contracts can be very awkward fiscally. So unless you're earning something like 150% in that contracting work compared to full-time work, it's not much of a fiscal benefit.
Or who wrote the original software. I've been programming long enough to see my old software being scrapped a few times, and to see the results of new software forced to follow old standards. Even when I would have preferred to use more oopen standards, small differences in appearance or usability for non-technical people forced design choices I disliked, and which have effectively cast in bronze as the specification for the same tools going forward.
To understand how much of Java _actually_ works, you have to understand the software it's written. Start with "The C Programming Language" by Kernighan and Ritchie.
When you feel more secure about both languages, and have increased your employability by a factor of 3, I suggest you learn how _not_ to do several of the extremely bad practices common to Java programmers, such as redefining functions of the same name locally, and making the same function name do different things with different capitalization.
Re:Was it a cause of his legal trouble?
on
Our Low-Tech Tax Code
·
· Score: 5, Informative
That's not how I read the article. The law creates tax issues for individual programmers who incorporate: if your business has only one employee and is less than one year old, the IRS comes looking for you. And as a matter of policy, the IRS is harassing _the employers_ of such contracting companies. The result is to discourage individual programmers from incorporating on their own.
Partly due to the economic issues lately, I've had _a lot_ of recruiting companies trying to recruit me to leave my work and come help them earn their recruiting fees. It's taken me a lot to stop laughing, sadly, when they say how lucrative it is: salary equal to my current salary, but without benefits or vacation, unemployment, and on a "temp to perm" basis for a company that is already falling apart due to letting their qualified engineers go at the start of the crisis is not a good place to go. I've reviewed the potential for consulting, and while it makes sense for some, it's not the wonderful and economically sound decision that many recruiters would have you believe.
The fingerprint I leave on a door or a counter is not usually tied directly to your name, your address, your phone number, your social security number, and a list of your emergency contacts. That organized information is quite valuable, for legal and illegal purposes, but usually not for a purpose that you or I would actually want.
A lot of "operating systems" store passwords, with badly written applications. Go take a look at "The-25-Most-Dangerous-Programming-Errors" thread a few days ago on Slashdot, and the long thread I started there about how most setups of Subversion store your passwords in cleartext, on the server for svnserve, and on the UNIX and Linux clients for svnserver, HTTP, HTTPS, and some SSH access.
Whoever wrote that letter is obviously a fool. But show up, and bring a camera, preferably a camera crew, and some gelatin. Then replicate this experiment described by Bruce Schneier.
Good for you: I'm glad you're thinking ahead about your career. What you're seeing from Pidgin is, unfortunately, commonplace thinking among developers who are convinced that no one sensible would leave themselves vulnerable by using a password that matters, and local security is not their problem. The thinking is similar to that of the Subversion authors, who unfortunately make it far too easy to accidentally store such passwords and who really need some sort of trivial access to their central servers.
Unfortunately, Subversion became popular as a big advancement over CVS (which it was). And NFS remains the de facto UNIX and Linux file-sharing standard, despite its lack of security. I don't have the funding to throw out the NetApps and departmental network applicances where I work, and the infrastructure resources to switch everyone to CIFS. NFS merely enhances the risk profoundly, it doesn't eliminate the risks from backup tapes and whatever media you use to store home directory information.
A better approach is to enforce the use of svn+ssh, and to provide the tools to manage it gracefully. Or switch to "git", which is not only noticeably more efficient and reliable and allows disconnected development, but merges code better, allows throwing out of material, has built-in features for GPG-signing code releases, and has tools to handle shared SSH account access gracefully such as a restricted shell for that common repository user, and "gitosis" for the keys. Subversion has none of that.
Linus Torvalds and the other authors of "git" actually paid attention to security. For Subversion, and as you point out Pidgin", it was an afterthought they chose not to deal with themselves. And you can tell which are classic examples of violations of those security rules mentioned, and which actually paid _attention_ to the security issues.
No, it's interesting that the manager showed up and seized the equipment without an opportunity for employees to clear personal data or office possessions. That's pretty unusual.
I've seen small companies closing their doors under different, but similarly awful circumstances. (Power being cut, losing their network feed due to non-payment, unpaid-for equipment being seized, etc.) An important rule for employees facing such troubles is to make sure you have all legal documents in off-site backup. Follow your contracts, but make sure your payment records, stock information, signed contracts, etc. are available offline. And consider whether to back up your work and email offsite or on separate media: I've actually been offered a return consulting job to come back and reconstruct work that I'd done and they'd deleted all source code for, as part of purging my old accounts. Since I;d been there as a corporate partner, and they tried to pay me under the table and not notify my company, I contacted our sales and legal departments. It turned out they hadn't paid six months of outstanding bills, and hiring me behind my company's back would have been much cheaper for them and much more profitable for me, but would have left my employer with much less leverage to get paid.
Fortunately for me, the key work I'd done had actually already been submitted to the relevant open source project's main codelines, so it wasn't lost. And they hadn't noticed the explanations in my contract about what working on GPL tools nad publishing them to that client meant, that they were under GPL. We actually managed to get them to cough up at least some of the backpay, mostly for explaining where to to get the updates.
I'm afraid they did: they merely duplicated CVS's careless approach to passwords and deliberately implemented the same password for SSH, HTTP, and HTTPS access. It is in fact _possible_ to use SSH keys for access, but ssh+svn access remains the only way for Subversion to enforce it properly. Barring Kerberized authentication, the other protocols should have been turned off by default years ago.
This is completely unworkable: it massively increases the amount of data that needs to be passed between client and server, and the amount of work the server must do, and makes movement far more pause-filled. If we were all on gigabit Ethernet on a local network, and all had top-of-the-line game machines, it might be workable. But not for reasonable hardware and modest network connections.
Also, certain triangles would be pretty recognizably face images.
"Misdirected pashion[sic]" is exactly what gets people convicted of child molestation, which has an amazing rate of repeat offenders. So is pyromania, abusing animals, and flying 747's into skyscrapers. Having "misdirected passion" as a youth does not make one safe as an adult: it's a reasonable hint that you might pull that sort of stunt again, especially if you did something so foolish as to actually get convicted of a felony and were unable to "plead out".
There are felonies that would not concern me so much: being caught a few times in college of dealing marijuana wouldn't bother me near so much as the "Anonymous" vandalism. And a civil disobedience arrest for peacefully blocking the road at a Vietnam War protest, or publishing photos of the NSA agents at Defcon? I'd probably offer to buy you lunch in the interview process. The key is the nature of the crime, and whether it's something I could live with as an employer or co-worker.
Yes, I see. In order to use an open source tool securely, I have to force all my clients to use the Windows tool TortoiseSVN, because the default tool for UNIX and Linux is so badly written. I do like TortoiseSVN, it is a well designed tool.
Unfortunately, I suggest you take a look at any sites that use "svn://" access to their Subversion repositoy. Those typically use plaintext passwords stored on the server in repo/conf/passwd. So it's not just client security that the Subversion authors mishandle, it's server side security as well.
It sounds like you're using an SSH key for svn+ssh, and you're being prompted for that SSH key password, not a "user" password for svn_ssh. That is how that tool usually works: the key creates a local svnserve daemon on the server to SSH-tunnel a temporary tunnel for you, and the actual communications is done on that svnserve tunnel. Oh, dear, you've been reminding me of all this intricacy working around such fundamental implementation flaws.
It sounds like you need a "key agent" for your svn+ssh access. If you're using Windows, investigate the use of the "Pageant" tool, which plays very nicely with TortoiseSVN. If you're on UNIX or Linux, investigate the use of "ssh-agent" or the "keychain" Perl script to manage your SSH keys.
And just because a directory is not "world-readable" does not mean others can't read it. Remember, many sites use NFS. Anyone who can get root on _any NFS client_ can change their user privileges to any other user on that network, and access the NFS files as that user. And an accessible ~/.subversion/auth/ directory is just the right place to steal passwords to springboard to _other_ systems. Given that any fool can set up an SSH based subversion repository on any machine they have shell access to, and you as an admin may not know that your users have done so and are storing their passwords in the clear, it's just a nightmare of security issues. And it needn't have happened.
Your suggestions are sensible. Unfortunately, in fact, they are very often _not_ done. People don't like remembering multiple passwords, so I've had numerous corporate partners try to insist on using their normal login and email passwords, and insist that "we trust the people we work with" and therefore refuse to switch to a more secure approach. And "remote access to to your local file system" is _extremely_ common, most commonly via NFS but also via precisely this kind of password access on remote systems on which you do work.
Interfering with the local repo is an interesting risk, but most sensible programmers review their submitted code changes before publishing them, so it's more likely to be noticed than someone with your password doing it themselves. And since your password is stored for HTTP, HTTPS, svnserve, and potentially for SSH access, they don't have to wait. They can usually submit the changes unattended.
No, because they insist on having NFS mounted home directories, and not securing or controlling it. Start up a live CD on any system in the building, NFS mount the home directories from any server, and I have the ability to read any home directory files I wish, either as the local "root" user or by doing an "su" to an appropriate uid.
Then there's the backup tapes, which are often poorly secured and rarely configured to skip $HOME/.subversion/auth or to skip passphrase free SSH keys.
Have you looked at any of the "Anonymous" videos? I stand by the claim that that idiot was "too self-righteous and foolish to be trusted with my equipment". I also stand by the claim that he, and his peers, were a "cracker group". It's certainly "cracking" that Brian got convicted of. (http://www.wired.com/threatlevel/2010/01/guilty-plea-in-scientology-ddos-attack/). And he certainly didn't act alone. So yes, at the time, they were a "cracker group".
The "Anonymous" group seems to have cleaned up its act, or its membership has changed, and now they're focusing on legal protests against Scientology abuse. Good for them, whoever the rest of them are. But Brian is still an idiot that I wouldn't want to hire: his conviction is demonstration of his foolishness, and that's unlikely to go away. If you want to support someone who's been convicted, by Scientology, of more justified action against them, try Cynthia Kisser (former director of Cult Awareness Network, an effective cult fighting group destroyed by Scientology lawsuits and whose website is now owned by the cult).
I'd agree with you conceptually, but despite episodes of "Boston Legal", it would take surprising cleverness to be convicted of child molestation for an 18 year old guy to be convicted in a sexual event with a 16 year old girl. Even if it's actually forcible rape, the ease of "pleading out" and getting a lesser sentence is so large that I'd be surprised if anyone here can name even a single such case.
The "asking if it wants you to remember the password" is actually new. It didn't do that until version 1.6.x. RHEL still ships with version 1.4.2, by default, which just stores it without asking.
Your site administrators are apparently competent enough to have installed the a more recent, non-vendor provided release of Subversion on your site. Good for you: but it would still be amusing to "su" to the various usernames in/etc/passwd and home directores in any NFS shared/home directory, scrape the passwords in $HOME/.subversion, and email them to their owners to mention how poor the security is for the sites using such password based access. It's especially funny to use the passwords to access those site's webmail servers, and send them their passwords using their own accounts.
No, I don't do this to my clients or partners. But I do show up at security meetings with the printout of passwords, as a demonstration of proof of the concept.
_Allow_ svn+ssh. Too many sites have managers unwilling to do so, and insistent on using HTTP with the user's own system passwords used in clear-text via HTTP, and stored in clear-text on build servers, because they cannot be bothered to allow competent managers to _enable_ svn+ssh.
The problem isn't that servers won't allow svn+ssh access, it's that managers for such sites won't allow the "svn" user to be configured and used in such circumstances. I've run into exactly that situation on several occastions: I've set up git->svn translation systems for use in such locations, because such sites are usually so stupid they do all their work in "trunk", anyway, and the gateway works fine there.
No, stupid behavior leads to failing background checks. Keep cause and effect in the correct order.
In most cases, even a felony for something foolish in your teens will not override years of professional experience. And many crimes do not necessarily lead to a repeat of the crime: some crackers, for example, have gone on to productive careers in software development or security.
But if you are a convicted child molester, I _do not want_ you anywhere unsupervised with children. The recidivism rate is too high. And if you have pulled the sort of stunts that, say Brian Thomas Mettenbrink, a member of the cracker group "Anonymous", was convicted of, I don't want you anywhere near my systems. You'd have proven you were too self-righteous and vindictive to be trusted with my equipment.
Slashdot Mirror
No, Windows Vista failed because of massive bloatware, continuing failures to properly _use_ the new security features, the redesigned GUI's that Microsoft failed to document or use consistently, massive overuse of RAM for features no one except Microsoft wanted (such as the hideous search handling), and the plans to include WinFS, which distorted quite a few filesystem components but turned out to be an exceptionally bad idea and was thrown out. (XML-based filesystems: how foolish can you be?)
Windows 7 is taking over Windows Vista, as it should. It's also finally cutting into Windows XP because XP has been lacking the few features that people actually wanted, such as completely discarding Internet Explorer 6, vendor support for 64-bit drivers, and better support for multiple cores.
VNC tends to be significantly faster than SSH+X11. It does present some security issues in normal use, but the concepts have been around for years.
Oh, my. That depends on if you can, and are willing, to work as a long-term employee. I've certainly met a few brilliant people who do quite well at short-term, high intensity projects, but who chafe under longer-term projects. As a consultant, they can go in, work on a complex project that requires their expertise short-term, and hand off the project at the end. This is particularly true for some network engineers and website designers and storage engineers I've met in the last 5 years, who could give a company help setting up new facilities and were happy to take fairly large paychecks, get out when it started getting dull and mundane, and move on to another project. But they were able to charge considerably more than my significant salary because of their level of expertise, and their focus on a specific project.
A few were complete failures, but some of them were pleasures to work with and introduced _me_ to some new approaches and technologies I'd had no opportunity to explore: those few were well worth the high consulting fees to us, but we or our partners didn't need their skills full-time, so did not try to hire them permanently.
And from harsh experience, I'd like to point out that that "possibily in tome to earn more" is bait on the hook to actually work for _less_. Health insurance, travel allowances, life insurance, 401K matching funds, vacation time, and unemployment can all add up to quite a lot of money a contractor won't get, especially since the time in between contracts can be very awkward fiscally. So unless you're earning something like 150% in that contracting work compared to full-time work, it's not much of a fiscal benefit.
Or who wrote the original software. I've been programming long enough to see my old software being scrapped a few times, and to see the results of new software forced to follow old standards. Even when I would have preferred to use more oopen standards, small differences in appearance or usability for non-technical people forced design choices I disliked, and which have effectively cast in bronze as the specification for the same tools going forward.
To understand how much of Java _actually_ works, you have to understand the software it's written. Start with "The C Programming Language" by Kernighan and Ritchie.
When you feel more secure about both languages, and have increased your employability by a factor of 3, I suggest you learn how _not_ to do several of the extremely bad practices common to Java programmers, such as redefining functions of the same name locally, and making the same function name do different things with different capitalization.
That's not how I read the article. The law creates tax issues for individual programmers who incorporate: if your business has only one employee and is less than one year old, the IRS comes looking for you. And as a matter of policy, the IRS is harassing _the employers_ of such contracting companies. The result is to discourage individual programmers from incorporating on their own.
Partly due to the economic issues lately, I've had _a lot_ of recruiting companies trying to recruit me to leave my work and come help them earn their recruiting fees. It's taken me a lot to stop laughing, sadly, when they say how lucrative it is: salary equal to my current salary, but without benefits or vacation, unemployment, and on a "temp to perm" basis for a company that is already falling apart due to letting their qualified engineers go at the start of the crisis is not a good place to go. I've reviewed the potential for consulting, and while it makes sense for some, it's not the wonderful and economically sound decision that many recruiters would have you believe.
The fingerprint I leave on a door or a counter is not usually tied directly to your name, your address, your phone number, your social security number, and a list of your emergency contacts. That organized information is quite valuable, for legal and illegal purposes, but usually not for a purpose that you or I would actually want.
A lot of "operating systems" store passwords, with badly written applications. Go take a look at "The-25-Most-Dangerous-Programming-Errors" thread a few days ago on Slashdot, and the long thread I started there about how most setups of Subversion store your passwords in cleartext, on the server for svnserve, and on the UNIX and Linux clients for svnserver, HTTP, HTTPS, and some SSH access.
Whoever wrote that letter is obviously a fool. But show up, and bring a camera, preferably a camera crew, and some gelatin. Then replicate this experiment described by Bruce Schneier.
http://www.schneier.com/crypto-gram-0205.html#5
Good for you: I'm glad you're thinking ahead about your career. What you're seeing from Pidgin is, unfortunately, commonplace thinking among developers who are convinced that no one sensible would leave themselves vulnerable by using a password that matters, and local security is not their problem. The thinking is similar to that of the Subversion authors, who unfortunately make it far too easy to accidentally store such passwords and who really need some sort of trivial access to their central servers.
Unfortunately, Subversion became popular as a big advancement over CVS (which it was). And NFS remains the de facto UNIX and Linux file-sharing standard, despite its lack of security. I don't have the funding to throw out the NetApps and departmental network applicances where I work, and the infrastructure resources to switch everyone to CIFS. NFS merely enhances the risk profoundly, it doesn't eliminate the risks from backup tapes and whatever media you use to store home directory information.
A better approach is to enforce the use of svn+ssh, and to provide the tools to manage it gracefully. Or switch to "git", which is not only noticeably more efficient and reliable and allows disconnected development, but merges code better, allows throwing out of material, has built-in features for GPG-signing code releases, and has tools to handle shared SSH account access gracefully such as a restricted shell for that common repository user, and "gitosis" for the keys. Subversion has none of that.
Linus Torvalds and the other authors of "git" actually paid attention to security. For Subversion, and as you point out Pidgin", it was an afterthought they chose not to deal with themselves. And you can tell which are classic examples of violations of those security rules mentioned, and which actually paid _attention_ to the security issues.
No, it's interesting that the manager showed up and seized the equipment without an opportunity for employees to clear personal data or office possessions. That's pretty unusual.
I've seen small companies closing their doors under different, but similarly awful circumstances. (Power being cut, losing their network feed due to non-payment, unpaid-for equipment being seized, etc.) An important rule for employees facing such troubles is to make sure you have all legal documents in off-site backup. Follow your contracts, but make sure your payment records, stock information, signed contracts, etc. are available offline. And consider whether to back up your work and email offsite or on separate media: I've actually been offered a return consulting job to come back and reconstruct work that I'd done and they'd deleted all source code for, as part of purging my old accounts. Since I;d been there as a corporate partner, and they tried to pay me under the table and not notify my company, I contacted our sales and legal departments. It turned out they hadn't paid six months of outstanding bills, and hiring me behind my company's back would have been much cheaper for them and much more profitable for me, but would have left my employer with much less leverage to get paid.
Fortunately for me, the key work I'd done had actually already been submitted to the relevant open source project's main codelines, so it wasn't lost. And they hadn't noticed the explanations in my contract about what working on GPL tools nad publishing them to that client meant, that they were under GPL. We actually managed to get them to cough up at least some of the backpay, mostly for explaining where to to get the updates.
Wait: are we talking about a game company, or SCO?
Oh, yes. Both.
I'm afraid they did: they merely duplicated CVS's careless approach to passwords and deliberately implemented the same password for SSH, HTTP, and HTTPS access. It is in fact _possible_ to use SSH keys for access, but ssh+svn access remains the only way for Subversion to enforce it properly. Barring Kerberized authentication, the other protocols should have been turned off by default years ago.
This is completely unworkable: it massively increases the amount of data that needs to be passed between client and server, and the amount of work the server must do, and makes movement far more pause-filled. If we were all on gigabit Ethernet on a local network, and all had top-of-the-line game machines, it might be workable. But not for reasonable hardware and modest network connections.
Also, certain triangles would be pretty recognizably face images.
"Misdirected pashion[sic]" is exactly what gets people convicted of child molestation, which has an amazing rate of repeat offenders. So is pyromania, abusing animals, and flying 747's into skyscrapers. Having "misdirected passion" as a youth does not make one safe as an adult: it's a reasonable hint that you might pull that sort of stunt again, especially if you did something so foolish as to actually get convicted of a felony and were unable to "plead out".
There are felonies that would not concern me so much: being caught a few times in college of dealing marijuana wouldn't bother me near so much as the "Anonymous" vandalism. And a civil disobedience arrest for peacefully blocking the road at a Vietnam War protest, or publishing photos of the NSA agents at Defcon? I'd probably offer to buy you lunch in the interview process. The key is the nature of the crime, and whether it's something I could live with as an employer or co-worker.
Yes, I see. In order to use an open source tool securely, I have to force all my clients to use the Windows tool TortoiseSVN, because the default tool for UNIX and Linux is so badly written. I do like TortoiseSVN, it is a well designed tool.
Unfortunately, I suggest you take a look at any sites that use "svn://" access to their Subversion repositoy. Those typically use plaintext passwords stored on the server in repo/conf/passwd. So it's not just client security that the Subversion authors mishandle, it's server side security as well.
It sounds like you're using an SSH key for svn+ssh, and you're being prompted for that SSH key password, not a "user" password for svn_ssh. That is how that tool usually works: the key creates a local svnserve daemon on the server to SSH-tunnel a temporary tunnel for you, and the actual communications is done on that svnserve tunnel. Oh, dear, you've been reminding me of all this intricacy working around such fundamental implementation flaws.
It sounds like you need a "key agent" for your svn+ssh access. If you're using Windows, investigate the use of the "Pageant" tool, which plays very nicely with TortoiseSVN. If you're on UNIX or Linux, investigate the use of "ssh-agent" or the "keychain" Perl script to manage your SSH keys.
And just because a directory is not "world-readable" does not mean others can't read it. Remember, many sites use NFS. Anyone who can get root on _any NFS client_ can change their user privileges to any other user on that network, and access the NFS files as that user. And an accessible ~/.subversion/auth/ directory is just the right place to steal passwords to springboard to _other_ systems. Given that any fool can set up an SSH based subversion repository on any machine they have shell access to, and you as an admin may not know that your users have done so and are storing their passwords in the clear, it's just a nightmare of security issues. And it needn't have happened.
Your suggestions are sensible. Unfortunately, in fact, they are very often _not_ done. People don't like remembering multiple passwords, so I've had numerous corporate partners try to insist on using their normal login and email passwords, and insist that "we trust the people we work with" and therefore refuse to switch to a more secure approach. And "remote access to to your local file system" is _extremely_ common, most commonly via NFS but also via precisely this kind of password access on remote systems on which you do work.
Interfering with the local repo is an interesting risk, but most sensible programmers review their submitted code changes before publishing them, so it's more likely to be noticed than someone with your password doing it themselves. And since your password is stored for HTTP, HTTPS, svnserve, and potentially for SSH access, they don't have to wait. They can usually submit the changes unattended.
No, because they insist on having NFS mounted home directories, and not securing or controlling it. Start up a live CD on any system in the building, NFS mount the home directories from any server, and I have the ability to read any home directory files I wish, either as the local "root" user or by doing an "su" to an appropriate uid.
Then there's the backup tapes, which are often poorly secured and rarely configured to skip $HOME/.subversion/auth or to skip passphrase free SSH keys.
Have you looked at any of the "Anonymous" videos? I stand by the claim that that idiot was "too self-righteous and foolish to be trusted with my equipment". I also stand by the claim that he, and his peers, were a "cracker group". It's certainly "cracking" that Brian got convicted of. (http://www.wired.com/threatlevel/2010/01/guilty-plea-in-scientology-ddos-attack/). And he certainly didn't act alone. So yes, at the time, they were a "cracker group".
The "Anonymous" group seems to have cleaned up its act, or its membership has changed, and now they're focusing on legal protests against Scientology abuse. Good for them, whoever the rest of them are. But Brian is still an idiot that I wouldn't want to hire: his conviction is demonstration of his foolishness, and that's unlikely to go away. If you want to support someone who's been convicted, by Scientology, of more justified action against them, try Cynthia Kisser (former director of Cult Awareness Network, an effective cult fighting group destroyed by Scientology lawsuits and whose website is now owned by the cult).
I'd agree with you conceptually, but despite episodes of "Boston Legal", it would take surprising cleverness to be convicted of child molestation for an 18 year old guy to be convicted in a sexual event with a 16 year old girl. Even if it's actually forcible rape, the ease of "pleading out" and getting a lesser sentence is so large that I'd be surprised if anyone here can name even a single such case.
The "asking if it wants you to remember the password" is actually new. It didn't do that until version 1.6.x. RHEL still ships with version 1.4.2, by default, which just stores it without asking.
Your site administrators are apparently competent enough to have installed the a more recent, non-vendor provided release of Subversion on your site. Good for you: but it would still be amusing to "su" to the various usernames in /etc/passwd and home directores in any NFS shared /home directory, scrape the passwords in $HOME/.subversion, and email them to their owners to mention how poor the security is for the sites using such password based access. It's especially funny to use the passwords to access those site's webmail servers, and send them their passwords using their own accounts.
No, I don't do this to my clients or partners. But I do show up at security meetings with the printout of passwords, as a demonstration of proof of the concept.
_Allow_ svn+ssh. Too many sites have managers unwilling to do so, and insistent on using HTTP with the user's own system passwords used in clear-text via HTTP, and stored in clear-text on build servers, because they cannot be bothered to allow competent managers to _enable_ svn+ssh.
The problem isn't that servers won't allow svn+ssh access, it's that managers for such sites won't allow the "svn" user to be configured and used in such circumstances. I've run into exactly that situation on several occastions: I've set up git->svn translation systems for use in such locations, because such sites are usually so stupid they do all their work in "trunk", anyway, and the gateway works fine there.
No, stupid behavior leads to failing background checks. Keep cause and effect in the correct order.
In most cases, even a felony for something foolish in your teens will not override years of professional experience. And many crimes do not necessarily lead to a repeat of the crime: some crackers, for example, have gone on to productive careers in software development or security.
But if you are a convicted child molester, I _do not want_ you anywhere unsupervised with children. The recidivism rate is too high. And if you have pulled the sort of stunts that, say Brian Thomas Mettenbrink, a member of the cracker group "Anonymous", was convicted of, I don't want you anywhere near my systems. You'd have proven you were too self-righteous and vindictive to be trusted with my equipment.