The IT community is small. Once you get down to metro areas, they're stupendously small. A quick look through Linked In gives some good insight in that arena:
Your Connections 120 Two degrees away 10,500+ Three degrees away 1,154,500+
Don't get blacklisted over something stupid when there are viable alternatives.
Since there's a QA department where you work, it's probably safe to assume there's a development department. Talk to your manager and the manager of the development team, see what options are available for you to move toward programming at your current company.
This is probably the method with the lowest barrier to entry.
If you're talking about Hibernate own configuration vs EJB3.0 (JPA) I chose JPA because it's a standard. There's certainly something to be said for that.
I use Glassfish's built-in JPA over Hibernate because it built-in, and works fine for my needs.
The altered screenshots have a certain grungy, gloomy richness to them, while the originals have a pale, blown-out look to them.
Oh, and I really only want a D3 for the fucking amazing graphics. The originals look like a top down WoW clone, which looked like a first/third person clone of WC3 with higher resolution models.
The barrier to entry for web development (even web 2.0) is much lower than your standard desktop environment. You can build damn near anything out of a dozen components (tags) and a little more than two dozen properties (styles).
A fun game is to download all the private keys off a shared hosting server, since they often leave that directory world-readable.
Couldn't you put all the keys into one file and encrypt it when you export it from openssl? When you restarted the server you'd have to type in the PW for that encrypted file, for Apache, but otherwise it would stay encrypted. I know you can do this with a single key, but I'm not sure about multiple keys in one file.
World readable private keys also seem unlikely for any shared hosting provider of significant size. Then again, I haven't h4x0r3d any shared hosting servers recently.
Certificates don't do that, they guarantee you're talking to the domain you expect to be talking to. CA signed certs prevent man in the middle attacks.
That's it all certs do. If the box you're talking to was hacked, tough. That's outside the scope of SSL certs.
I wasn't involved in the auditing process when the company I worked for started it's CA, but I believe that assessor is WebTrust. The fees are... significant; as are the physical and technical security requirements.
CA signed certificates aren't quite a license to print money, but almost.
Complying with SOX, PKI, and PCI security requirements all at the same time was an interesting experience.
The basic premise of a CA is giving everyone a trusted third party.
How do I know you are who you say you are, and not a man in the middle? With a self-signed cert, there's no assurance unless the cert has already been saved. With a CA signed cert, there's assurance of identity.
Just because there's an RFC for it, doesn't mean it's a good idea.
Additionally, what worked in 1989 isn't necessarily a good idea today. On second thought, I wouldn't even say it was a terribly good idea then. Other than the theme based names, that RFC isn't too bad.
If/when I run a company where I need to hire IT folk, this will be one of my interview questions. If someone says a good naming scheme would be planets, elements, or some other theme based nonsense, (s)he's getting the boot.
Having worked at two companies now with 8,000+ servers each, unless you're changing server roles all the time, function based names are best. Even in a small environment, I would recommend this scheme. Pad the names to at least two digits, more if your expectations require; i.e. 01, 02, 03. Site names based on local airport codes are also good. If you have multiple sites in one geographical area, suffix the names with 01, 02, 03,...
Some would argue against this for purposes of "security". I think this is flawed for several reasons: 1. It's security through obscurity, which is no security. 2. If someone's freely in your network, the jig is already up. 3. It only serves to complicate things when you get bigger, and inevitably go to function based names.
If you know that you're talking to the proper site, which is verifiable via the key's fingerprint, you can accept that certificate permanently. From that point on, it's as good as a CA signed certificate.
However, if you get a bad certificate the first time around you're hosed.
Slashdot Mirror
If the company you're at won't work to keep you, find another company looking for a QA person that's more open to making the move you want.
The IT community is small. Once you get down to metro areas, they're stupendously small. A quick look through Linked In gives some good insight in that arena:
Your Connections 120
Two degrees away 10,500+
Three degrees away 1,154,500+
Don't get blacklisted over something stupid when there are viable alternatives.
Since there's a QA department where you work, it's probably safe to assume there's a development department. Talk to your manager and the manager of the development team, see what options are available for you to move toward programming at your current company.
This is probably the method with the lowest barrier to entry.
Here's a whole boatload of examples of people defending themselves from criminals.
L. Bob Rife approves.
Jesus Christ, they paid money for that?
Might be time to reconsider your stance on the issue, folks on the left.
If it came with a Weighted Companion Cube skin, I'd consider buying one just for the hell of it.
The game can be dark, as long as it's easy to see where needed and appropriate.
If you're talking about Hibernate own configuration vs EJB3.0 (JPA) I chose JPA because it's a standard. There's certainly something to be said for that.
I use Glassfish's built-in JPA over Hibernate because it built-in, and works fine for my needs.
The altered screenshots have a certain grungy, gloomy richness to them, while the originals have a pale, blown-out look to them.
Oh, and I really only want a D3 for the fucking amazing graphics. The originals look like a top down WoW clone, which looked like a first/third person clone of WC3 with higher resolution models.
I've already got a pretty good setup rolled with MochiKit/DWR/Spring/JPA. The biggest selling point for GWT, to me, is the ability to debug in my IDE.
Firebug kills my browser.
We're going to be looking at it soon for an Intranet project, specifically ExtJS GWT. We'll see how it goes.
The barrier to entry for web development (even web 2.0) is much lower than your standard desktop environment. You can build damn near anything out of a dozen components (tags) and a little more than two dozen properties (styles).
Heh, I wouldn't figure they would. It would be a logistical nightmare in the event of a power loss. Still, I think it's technically possible.
You could also protect the directory from access by anything but the Apache user, and use SuExec for sites.
I imagine most larger hosting providers do.
A fun game is to download all the private keys off a shared hosting server, since they often leave that directory world-readable.
Couldn't you put all the keys into one file and encrypt it when you export it from openssl? When you restarted the server you'd have to type in the PW for that encrypted file, for Apache, but otherwise it would stay encrypted. I know you can do this with a single key, but I'm not sure about multiple keys in one file.
World readable private keys also seem unlikely for any shared hosting provider of significant size. Then again, I haven't h4x0r3d any shared hosting servers recently.
Certificates don't do that, they guarantee you're talking to the domain you expect to be talking to. CA signed certs prevent man in the middle attacks.
That's it all certs do. If the box you're talking to was hacked, tough. That's outside the scope of SSL certs.
Difficult to impossible to eavesdrop unless you're using a man in the middle attack. Then you end up on the wall of sheep.
I wasn't involved in the auditing process when the company I worked for started it's CA, but I believe that assessor is WebTrust. The fees are... significant; as are the physical and technical security requirements.
CA signed certificates aren't quite a license to print money, but almost.
Complying with SOX, PKI, and PCI security requirements all at the same time was an interesting experience.
The basic premise of a CA is giving everyone a trusted third party.
How do I know you are who you say you are, and not a man in the middle? With a self-signed cert, there's no assurance unless the cert has already been saved. With a CA signed cert, there's assurance of identity.
Sorry, but you have no idea what you're talking about.
GD gives you a full blown SSL cert that works just like what you would get from Verisign.
$30 for a standard cert, $200 for a "wildcard" cert which lets you SSLize all your subdomains.
Just because there's an RFC for it, doesn't mean it's a good idea.
Additionally, what worked in 1989 isn't necessarily a good idea today. On second thought, I wouldn't even say it was a terribly good idea then. Other than the theme based names, that RFC isn't too bad.
The comments on this article make me stabby.
If/when I run a company where I need to hire IT folk, this will be one of my interview questions. If someone says a good naming scheme would be planets, elements, or some other theme based nonsense, (s)he's getting the boot.
Having worked at two companies now with 8,000+ servers each, unless you're changing server roles all the time, function based names are best. Even in a small environment, I would recommend this scheme. Pad the names to at least two digits, more if your expectations require; i.e. 01, 02, 03. Site names based on local airport codes are also good. If you have multiple sites in one geographical area, suffix the names with 01, 02, 03, ...
Examples:
nagios01.sfo.example.com
nagios02.sfo.example.com
nagios01.phx.example.com
dns01.lga01.example.com
dns01.lga02.example.com
Some would argue against this for purposes of "security". I think this is flawed for several reasons:
1. It's security through obscurity, which is no security.
2. If someone's freely in your network, the jig is already up.
3. It only serves to complicate things when you get bigger, and inevitably go to function based names.
If you know that you're talking to the proper site, which is verifiable via the key's fingerprint, you can accept that certificate permanently. From that point on, it's as good as a CA signed certificate.
However, if you get a bad certificate the first time around you're hosed.
That said, usually, you'll be fine.