Linux license cost is free and there are lots of resources (people mainly) are available
sorry to be pedantic, but this is a common and incorrect assumption regarding Linux TCO. If you're running a production server, you get a production license/support agreement. You can't, and shouldn't expect there to be zero cost in a production environment.
You can't forget that proper management of exceptions can lead to forming new standards. For example, if IE is the standard (heavans no) and FireFox has grown to 80% marketshare internally (tracked through exceptions) it could be a valid case to change the standard.
IT does book profit but the problem is that if we make accounting more efficient with our hard work all the accountants get nice bonuses and we get to go fuck ourselves.
You mean like how the Sales guys get the bonuses, while the accountants get screwed? Or how the execs get to not go to jail when internal audit discovers and issue before the next external audit?
That's incorrect, IBM has allowed employees to choose whatever OS they want - including official support for Linux and Windows, as well as skunkworks support for Mac.
So tell me, who do I hurt if I pay once for a CD or DVD, then rip or pirate it and play the unlocked files on any/every device I own? Who do I hurt when I lend my copy to a friend (who, if he finds he likes it, may even purchase his own copy)?
Your assumption is that your friend will buy a copy. Hollywood is afraid they might actually have to make movies that people want to buy.
That is not true at all. My company (IBM) has both technical and managerial paths. Look up IBM Distinguished Engineer and IBM Fellow in wikipedia when you get some time. Technology companies usually maintain two paths.
Thrown out of a passing aeroplane? Really? Have you tried opening the windows on an aeroplane recently? I suppose someone could have flown over in a bi-plane... but really?
If the customer had used a proper PKI with key recovery/escrow this could have been avoided. The solution is NOT to make weak passwords so that you can crack them when you lose your passphrase. How on earth is this modded informative?!
Last post on this topic - clearly you and I have a different understanding of security. No HTTP POST/GET variable are typed - you can throw whatever you want in them. Lazy assumptions about length won't help you either. Point is, there is an extra set of data to parse. Whenever there is data to parse, there is the potential for an exploit. See my solution above, and lets move on.
Can you explain to me how a malicious person's manipulation of the hash value could damage anything? How would they know what to change it to?
Any input taken should be scrutinized for injection, overflows etc. Another input from "out there" another set of variable to scrub. A sloppily coded hash/verification could be a vector for SQL injection for example.
I suppose they could just hash the form fields and hope, but that's easily defeated by adding in a server side session variable as salt.
If you have a session to begin with... just store it server side
Also, while this isn't exactly the best practice, the question made it clear that it was a fairly small internal web app. So worrying about malicious users on that scale is likely not an issue
assumptions regarding the scope, confidentiality, integrity or availability requirements weren't part of my answer. Only that from a security perspective, anytime you have another piece of information that's user submitted, requires a thorough check/scrub/sanitization prior to being processed.
Storing the hash of the original data client side is bad from a security perspective. A malicious user could manipulate the hash as they sought fit. I'd keep the hash in a server side session specific variable. I realize the damage that could be done seems small, but I wouldn't trust *anything* - especially a critical part of your locking mechanism - to a variable that could be manipulated client side.
Are you part of the security team? If not, perhaps this is more the domain of your security guys than yourself. I'd also get the buy in of HR. As with most policy changes (especially ones with a reprimand) you gotta make sure HR is on side. Legal for good measure too - ie are you asking something which is illegal of the employee? I know its a stretch, but CYA.
In another example IBM seems to like Opera for many of it's Linux/workstation machines as it's cross-architecture/platform embedded reader... again, they could "encourage" Leneovo to add that to thinkpads for their in-house teams.
IBM more heavily embraces Chrome and Mozilla internally than Opera. And Lenovo's preload has nothing to do with the image that IBM uses internally, save the drivers.
Yes, because as with the "traditional" definition http://en.wikipedia.org/wiki/Glass_ceiling Lars overcame institutionalized discrimination in order to succeed.
the issue for me has never been disk bloat, but rather the inherent security vulnerabilities of installing more stuff than you actually need. More stuff means more stuff to patch, means more vulnerabilities.
Slashdot Mirror
Linux license cost is free and there are lots of resources (people mainly) are available
sorry to be pedantic, but this is a common and incorrect assumption regarding Linux TCO. If you're running a production server, you get a production license/support agreement. You can't, and shouldn't expect there to be zero cost in a production environment.
You can't forget that proper management of exceptions can lead to forming new standards. For example, if IE is the standard (heavans no) and FireFox has grown to 80% marketshare internally (tracked through exceptions) it could be a valid case to change the standard.
IT does book profit but the problem is that if we make accounting more efficient with our hard work all the accountants get nice bonuses and we get to go fuck ourselves.
You mean like how the Sales guys get the bonuses, while the accountants get screwed? Or how the execs get to not go to jail when internal audit discovers and issue before the next external audit?
Your logic is highly flawed.
That's incorrect, IBM has allowed employees to choose whatever OS they want - including official support for Linux and Windows, as well as skunkworks support for Mac.
If you're paying them by the milestone - great. If you're paying them by the hour, start cracking down.
So tell me, who do I hurt if I pay once for a CD or DVD, then rip or pirate it and play the unlocked files on any/every device I own? Who do I hurt when I lend my copy to a friend (who, if he finds he likes it, may even purchase his own copy)?
Your assumption is that your friend will buy a copy. Hollywood is afraid they might actually have to make movies that people want to buy.
I'm running F12 x64 and I downloaded the Chrome beta. Why hasn't anyone pointed out that the lack of an x64 Gears plugin is rather silly?
ehm, back in my day we called it the Big Kernel Lock. You kids!
now get off my lawn!
That is not true at all. My company (IBM) has both technical and managerial paths. Look up IBM Distinguished Engineer and IBM Fellow in wikipedia when you get some time. Technology companies usually maintain two paths.
or it was thrown out of a passing aeroplane.
Thrown out of a passing aeroplane? Really? Have you tried opening the windows on an aeroplane recently? I suppose someone could have flown over in a bi-plane... but really?
That is just nonsense.
If the customer had used a proper PKI with key recovery/escrow this could have been avoided. The solution is NOT to make weak passwords so that you can crack them when you lose your passphrase. How on earth is this modded informative?!
Why would X have worked on any builds of OpenWRT???
Palm has circumvented the published API for doing this (for god knows what reason). And they've done so by "faking" a USB VENDOR ID.
Why not just used the published method as BlackBerry / RIM does?
Last post on this topic - clearly you and I have a different understanding of security. No HTTP POST/GET variable are typed - you can throw whatever you want in them. Lazy assumptions about length won't help you either. Point is, there is an extra set of data to parse. Whenever there is data to parse, there is the potential for an exploit. See my solution above, and lets move on.
Can you explain to me how a malicious person's manipulation of the hash value could damage anything? How would they know what to change it to?
Any input taken should be scrutinized for injection, overflows etc. Another input from "out there" another set of variable to scrub. A sloppily coded hash/verification could be a vector for SQL injection for example.
I suppose they could just hash the form fields and hope, but that's easily defeated by adding in a server side session variable as salt.
If you have a session to begin with... just store it server side
Also, while this isn't exactly the best practice, the question made it clear that it was a fairly small internal web app. So worrying about malicious users on that scale is likely not an issue
assumptions regarding the scope, confidentiality, integrity or availability requirements weren't part of my answer. Only that from a security perspective, anytime you have another piece of information that's user submitted, requires a thorough check/scrub/sanitization prior to being processed.
Storing the hash of the original data client side is bad from a security perspective. A malicious user could manipulate the hash as they sought fit. I'd keep the hash in a server side session specific variable. I realize the damage that could be done seems small, but I wouldn't trust *anything* - especially a critical part of your locking mechanism - to a variable that could be manipulated client side.
Are you part of the security team? If not, perhaps this is more the domain of your security guys than yourself. I'd also get the buy in of HR. As with most policy changes (especially ones with a reprimand) you gotta make sure HR is on side. Legal for good measure too - ie are you asking something which is illegal of the employee? I know its a stretch, but CYA.
In another example IBM seems to like Opera for many of it's Linux/workstation machines as it's cross-architecture/platform embedded reader... again, they could "encourage" Leneovo to add that to thinkpads for their in-house teams.
IBM more heavily embraces Chrome and Mozilla internally than Opera. And Lenovo's preload has nothing to do with the image that IBM uses internally, save the drivers.
I can assure you that IBM (and Lotus as a result) do have a provision surrounding this.
So the OPEN SOURCE community will benefit from BINARY diffs.
uhuh. I think we're just fine with patch/diff.
oh, what's that? You meant the people that DISTRIBUTE BINARY version of OPEN SOURCE programs will benefit? Ahhh, now I see.
The only way the OS even knew your floppy drive existed was through the bios.
If you stayed in real mode
... this would be about a Windows security issue based on the headline.
>I don't install 'borrowed programs' in a production environment
'borrowed programs' shouldn't be installed anywhere - prod, test, uat whatever. Non-production piracy is still piracy.
Yes, because as with the "traditional" definition http://en.wikipedia.org/wiki/Glass_ceiling Lars overcame institutionalized discrimination in order to succeed.
I think you need to start paying attention.
the issue for me has never been disk bloat, but rather the inherent security vulnerabilities of installing more stuff than you actually need. More stuff means more stuff to patch, means more vulnerabilities.