Except it's none of those in this case. It's Sigma "buying" one copy of the OS and then making and distributing additional products under a specific license (it must me under license since it'd be illegal under copyright law for them to do that without a license). That license specifies the terms that they may distribute under, to wit the "resellers" must receive it under the same license Sigma received it under. The "resellers" are likewise making and distributing additional copies of it after having received only one, which means they must have accepted the license terms too (again, they may not legally make and distribute additional copies without a license). The best those "resellers" could do is claim that Sigma didn't inform them of the license terms and that their copyright infringement is unknowing.
If it was past the 3-year timeframe specified in the GPL and you hadn't been distributing the program since you lost the source, you'd've presented the text of the GPL with the relevant paragraph highlighted, and the judge would've dismissed their case or found for you.
Within the 3-year limit, it'd depend. If you'd distributed the program with source and merely made the source available on it's own, again they'd lose because the 3-year-limit paragraph wouldn't apply. If you weren't including the source with the program and it wasn't available anywhere else, well, technically you'd be in trouble for failing to live up to your end of the GPL but practically it'd depend on what happened. In general you wouldn't be held liable for events beyond your reasonable control. Still, backups are a very good idea.
We make a big deal of companies failing to live up to the terms of the GPL, but the author has responsibilities under the terms of the GPL too and we'd better live up to them just as much as we expect everyone else to.
cron.hourly is a directory. Thus how I could mount a volume over it.
Vast majority? Home users on fully-wired networks, perhaps, but home users with a wireless access point or laptop users who plug into networks they don't control are wide-open to exploits.
The right thing to do is configure it to only trust specific known DHCP servers, or to only trust specific known LDAP and netinfo servers and refuse to talk to any others regardless of what DHCP says. The information on the vulnerability pretty much covered everything you can do.
I wouldn't have to overwrite/etc/passwd, setting an LDAP authentication server via the DHCP parameters would cause that LDAP server to take precedence. If I put an entry in it for "root", your local password file wouldn't ever be checked when checking root's password while your own account would be unaffected (no entry for it in LDAP, so automatic fallback to the local password file).
As for cron, hardly heroic. Trivial in fact. cron reads known files for it's scripts, and it runs known scripts. Mount a directory on top of cron.hourly with a malicious script in it and wait for the turn of the hour. There's usually no scripts in there, so the overwrite wouldn't be noticeable.
I'd rate the exploitability of this as "trivial to exploit, easily automatable", especially considering that it's the default configuration and few people change it without being told to.
/ isn't/etc. Basic Unix, and OSX is Unix. Your account would be fine, you wouldn't notice a thing. And you can change your password all day, won't make a difference because in the vulnerable configuration it's the password in my LDAP server that would be checked, not the one you set locally. That's what makes this vulnerability so vicious.
Sleep mode would require some more work, I'd have to play games with mountpoints to get one of root's cron jobs to execute one of my programs, but it can be done once you can control mountpoints.
Oh, forgot the most important one: it doesn't matter whether you've enabled sshd or not. Remember that this vulnerability allows them to control network mounts on your machine via the relevant DHCP parameters. That means that they can mount their startup directories over top of yours, and theirs have things configured to start sshd. Presto, your machine now has sshd running and ready to accept logins even if you've disabled it, because your configuration no longer applies.
Logins are the least of the problems. Once they can change the authorization information on your machine, they can gain access to anything you have accessible but protected by authorization. Many people have their machines set up so that certain things like file shares are accessible but require a valid username and password to gain access to them, to make it easier to copy things around between multiple machines. Normally this would be safe, but this vulnerability allows an attacker to gain access by his control of the passwords.
And I can think of at least 2 reasons off-hand to have sshd enabled on a laptop. The same reasons I'd have it enabled on a desktop, in fact.
Apple wouldn't even have had to release a patch. Just change the default settings and/or include a prominent notice about the problem so users knew what they had to do based on their situation. On a vulnerability like this, response time should be a week tops, a few days preferably. A month without at least a workaround for users is completely unacceptable to anyone who cares at all whether their machine gets rooted.
I suspect the reason why this info was released was simple: Apple went and released the 10.3 upgrade with a known remote-root vulnerability in it after having acknowledged the existence of the vulnerability.
To me, knowing that this vulnerability exists would be critical. I don't run a Mac, but I attach to possibly hostile networks routinely. Normally I can firewall my machine to block attacks, but I can't firewall off DHCP and still use the network. Were I using a Mac and OSX, I'd very much want to know that I needed to take immediate steps to avoid giving someone the keys to my machine just by plugging in at the local coffee house.
Release of this information may constitute a problem for Apple, and may mean a lot of fast work for OSX users. Not releasing it, though, would mean a lot more work for OSX users who get their machines rooted, and a lot more work for the rest of us who have to fend off attacks and other crud routed through those rooted boxes.
Sharing music and movies is illegal, ethically wrong etc etc. Please, accept the fact.
I don't accept that as a fact. Sharing music and movies that the copyright holder allows to be shared, or that's in the public domain, is perfectly legal, ethical and right. It's only unauthorized sharing of copyrighted material that's wrong. This is a distinction the various RIAA-type groups want to blur and confuse as much as possible.
They're not sending the letter to the manufacturers, just the distributors/vendors who sell the products to the county. Since the manufacturers aren't going to do custom production for as small a quantity as LA County buys and they know the distributors/vendors have to buy drives regardless, I don't see the manufacturers changing their terminology. The vendors aren't going to take on the costs of custom documentation etc., so I suspect LA County will soon be in the position of either reversing that request or not being able to buy hard drives at anything below quadruple list price.
I recall some changes in the laws this year, but I can't recall details so I don't know whether that proposal actually went through or not. I do know that not requiring proof of identity and/or residency is an open invitation to massive vote fraud. As for selective checking, the answer to that is simple: don't be selective. Check all IDs for everyone, no exceptions. If everyone gets asked, it can't be discriminatory (except perhaps against noncitizens in the country illegally, and I don't think we should be kludging the voting laws to work around an immigration problem).
Again, this doesn't match what happened. I was registered, was on the registered-voters list for the precinct, hadn't moved since the previous election. They still required ID. They were requiring ID of everyone, no exceptions. And the list was being updated continuously, since you signed beside your entry to indicate you'd gotten your ballot, and was not posted anywhere that I could see besides in the book in front of the poll worker.
The only thing they really need electronic voting for is speed. They want the results faster than manual counting would allow. If you want a system at least as good as what we had, all you need is a system that produces machine+human-readable ballots.
When you vote, the machine when finished prints out a ballot with both machine-readable (barcode, perhaps) and human-readable versions of your vote. You confirm that it matches your vote, then drop it in the ballot box. The voting machine can hold an electronic tally internally which can be read after close of polls for a fast result. If there's a question of validity, you machine-scan the machine-readable portions of the printed ballots. As a check, you can compare the human-readable and machine-readable portions of a sample of the printed ballots to make sure the two really do match. If you select the sample randomly, it'd be statistically improbable for the voting machines to deliberately put incorrect machine-readable versions down without getting caught at it.
You can use smart-cards or whatnot for enabling a vote on the machine, and the traditional methods work for spoiled ballots. A one-use magnetic card like the airlines use for tickets would be even cheaper.
Given that it's not all that hard to design a system like that, I have to wonder why Diebold and the rest are so adamant about not doing it.
Asking for ID would be illegal in CA? Every election I've voted in here, they require a driver's license or other ID matched against the registration roll before they'll even give you a ballot. That's really the only way to avoid graveyard voting.
Remember that the receipt is actually a printed ballot, put into a ballot box at the polling place just like the current ballots. If the machine printed out one thing but recorded another, then during the inevitable recount (in CA a recount is automatic if the margin is less than a certain amount) they'll find a discrepancy between the results of the recount and the results reported by the machine. You start seeing that in several recounts, especially if it changes the outcome of the election, and there'll be enough of an outcry that an investigation will have to be started.
One catch: if I have proper security measures in place, any attempt by the router to connect to a server on my computer (eg. the AV software) will be blocked by the firewall on the client computer. What will the admins do if policy prohibits opening up client computers to incoming connections?
It isn't that broad. The company would, for example, have to specify exactly what resources were used and when. If they tried to claim "company time" outside of normal work hours, they'd be asked to produce the documentation where they specified that working those hours at home was part of the job description (just "as needed" wouldn't cut it). If they managed to document that, their victory would probably be followed immediately by a visit from the Wage and Hour people, however (again, in CA, the law has a very clear definition for who is exempt from overtime rules, and employment agreements and company policies can't make you exempt if the law says you're not). If they claimed it was related to his work, they'd be asked to provide documentation of exactly what work he was doing that the project was related to. If the company can't document it, they're unlikely to win a 2870 case. They might be able to make a case if he'd previously been assigned to a company project where the information/experience gained was crucial to the outside project, but mere access to information usually won't qualify without that extra.
There's the rub, though, the employee has to be willing and able to fight it through the process. You usually do this only when you're leaving the company anyway, because politically it's a major CLM.
Except that California law applies in this case, and California law is quite clear on the point. The employer may lay claim to things developed using company resources, or which directly relate to what you're doing for them now or which you're involved in R&D on. Any claim to things beyond what's allowed in 2870 is illegal and unenforceable. Salaried status is irrelevant as far as 2870 is concerned, an employer is not allowed to consider salaried employees to be "on the clock" 24 hours a day. In fact, where I work, right along with the IP-rights agreement they had to give me a 5-page explanation of 2870 that ended by saying, essentially, "The terms outlined here are the maximum allowed by law, any agreement your employer may ask you to sign that demands more than allowed here is illegal and void.". This has gone to court before, and the overreaching companies have consistently lost.
Years old? Exchange 2000 is probably running 75% or more of corporate Exchange installations. Exchange 2003 just came out this year, and the corporate world isn't even thinking about migrating to it until next year at the earliest.
Will Exchange 2003 even run on Windows 2000 (which is what most corporations are running on servers)?
Hmm, let's see. This is supposed to be private information at the moment. Should a person (or a company) have the right to keep sensitive information private if it poses no harm to anyone? I'm inclined to answer yes.
I'm inclined to answer yes to that question too, but that isn't the question in this case. The question is, once BestBuy has failed to keep the information private, do they have a right to force someone else to take on the duty of non-disclosure even though they haven't signed a non-disclosure agreement? That, I'm inclined to answer a big loud "No!" to. If BestBuy wants to keep their prices private, the onus is on them to keep them private, not the rest of us.
Disclosure of trade secrets only applies when the disclosing party had a duty not to disclose. That means, almost always, that they had a signed non-disclosure agreement. The other case would be where the information was obtained illegally and the disclosing party knew it was obtained illegally. In short, it's BestBuy's responsibility to keep it's secrets secret, and if they don't that's not Fatwallet's problem.
The only problem is the audit trail. All the Linux code is kept in either CVS or BitKeeper, both of which maintain a trail in the repository of exactly who changed what and when. IBM maintains at least that much of an audit trail as well. If SCO tries that, all IBM has to do is pull out the change log and trace the code back to it's original check-in. If the check-in was prior to SCO's code's alleged creation date, or was by someone with no access to SCO code, SCO has a world of explaining to do to the judge.
Probably not a derivative work under copyright law, but you'd run afoul of trademark on the characters (even if not registered). That's been a long-settled point of copyright law: you can't copyright characters, only the stories they appear in.
True, but when I see retyping like that they typically copy everything exactly. There's just enough differences in names and structural elements (braces and such) that someone had to think to get those variations. And there's still point 3, that the "copied" functions are very simple, things like basic wrappers that pass their arguments off to the real function. I could have come up with identical code without ever having seen theirs.
Slashdot Mirror
Except it's none of those in this case. It's Sigma "buying" one copy of the OS and then making and distributing additional products under a specific license (it must me under license since it'd be illegal under copyright law for them to do that without a license). That license specifies the terms that they may distribute under, to wit the "resellers" must receive it under the same license Sigma received it under. The "resellers" are likewise making and distributing additional copies of it after having received only one, which means they must have accepted the license terms too (again, they may not legally make and distribute additional copies without a license). The best those "resellers" could do is claim that Sigma didn't inform them of the license terms and that their copyright infringement is unknowing.
If it was past the 3-year timeframe specified in the GPL and you hadn't been distributing the program since you lost the source, you'd've presented the text of the GPL with the relevant paragraph highlighted, and the judge would've dismissed their case or found for you.
Within the 3-year limit, it'd depend. If you'd distributed the program with source and merely made the source available on it's own, again they'd lose because the 3-year-limit paragraph wouldn't apply. If you weren't including the source with the program and it wasn't available anywhere else, well, technically you'd be in trouble for failing to live up to your end of the GPL but practically it'd depend on what happened. In general you wouldn't be held liable for events beyond your reasonable control. Still, backups are a very good idea.
We make a big deal of companies failing to live up to the terms of the GPL, but the author has responsibilities under the terms of the GPL too and we'd better live up to them just as much as we expect everyone else to.
cron.hourly is a directory. Thus how I could mount a volume over it.
Vast majority? Home users on fully-wired networks, perhaps, but home users with a wireless access point or laptop users who plug into networks they don't control are wide-open to exploits.
The right thing to do is configure it to only trust specific known DHCP servers, or to only trust specific known LDAP and netinfo servers and refuse to talk to any others regardless of what DHCP says. The information on the vulnerability pretty much covered everything you can do.
I wouldn't have to overwrite /etc/passwd, setting an LDAP authentication server via the DHCP parameters would cause that LDAP server to take precedence. If I put an entry in it for "root", your local password file wouldn't ever be checked when checking root's password while your own account would be unaffected (no entry for it in LDAP, so automatic fallback to the local password file).
As for cron, hardly heroic. Trivial in fact. cron reads known files for it's scripts, and it runs known scripts. Mount a directory on top of cron.hourly with a malicious script in it and wait for the turn of the hour. There's usually no scripts in there, so the overwrite wouldn't be noticeable.
I'd rate the exploitability of this as "trivial to exploit, easily automatable", especially considering that it's the default configuration and few people change it without being told to.
/ isn't /etc. Basic Unix, and OSX is Unix. Your account would be fine, you wouldn't notice a thing. And you can change your password all day, won't make a difference because in the vulnerable configuration it's the password in my LDAP server that would be checked, not the one you set locally. That's what makes this vulnerability so vicious.
Sleep mode would require some more work, I'd have to play games with mountpoints to get one of root's cron jobs to execute one of my programs, but it can be done once you can control mountpoints.
Oh, forgot the most important one: it doesn't matter whether you've enabled sshd or not. Remember that this vulnerability allows them to control network mounts on your machine via the relevant DHCP parameters. That means that they can mount their startup directories over top of yours, and theirs have things configured to start sshd. Presto, your machine now has sshd running and ready to accept logins even if you've disabled it, because your configuration no longer applies.
Logins are the least of the problems. Once they can change the authorization information on your machine, they can gain access to anything you have accessible but protected by authorization. Many people have their machines set up so that certain things like file shares are accessible but require a valid username and password to gain access to them, to make it easier to copy things around between multiple machines. Normally this would be safe, but this vulnerability allows an attacker to gain access by his control of the passwords.
And I can think of at least 2 reasons off-hand to have sshd enabled on a laptop. The same reasons I'd have it enabled on a desktop, in fact.
Apple wouldn't even have had to release a patch. Just change the default settings and/or include a prominent notice about the problem so users knew what they had to do based on their situation. On a vulnerability like this, response time should be a week tops, a few days preferably. A month without at least a workaround for users is completely unacceptable to anyone who cares at all whether their machine gets rooted.
I suspect the reason why this info was released was simple: Apple went and released the 10.3 upgrade with a known remote-root vulnerability in it after having acknowledged the existence of the vulnerability.
To me, knowing that this vulnerability exists would be critical. I don't run a Mac, but I attach to possibly hostile networks routinely. Normally I can firewall my machine to block attacks, but I can't firewall off DHCP and still use the network. Were I using a Mac and OSX, I'd very much want to know that I needed to take immediate steps to avoid giving someone the keys to my machine just by plugging in at the local coffee house.
Release of this information may constitute a problem for Apple, and may mean a lot of fast work for OSX users. Not releasing it, though, would mean a lot more work for OSX users who get their machines rooted, and a lot more work for the rest of us who have to fend off attacks and other crud routed through those rooted boxes.
Sharing music and movies is illegal, ethically wrong etc etc. Please, accept the fact.
I don't accept that as a fact. Sharing music and movies that the copyright holder allows to be shared, or that's in the public domain, is perfectly legal, ethical and right. It's only unauthorized sharing of copyrighted material that's wrong. This is a distinction the various RIAA-type groups want to blur and confuse as much as possible.
They're not sending the letter to the manufacturers, just the distributors/vendors who sell the products to the county. Since the manufacturers aren't going to do custom production for as small a quantity as LA County buys and they know the distributors/vendors have to buy drives regardless, I don't see the manufacturers changing their terminology. The vendors aren't going to take on the costs of custom documentation etc., so I suspect LA County will soon be in the position of either reversing that request or not being able to buy hard drives at anything below quadruple list price.
I recall some changes in the laws this year, but I can't recall details so I don't know whether that proposal actually went through or not. I do know that not requiring proof of identity and/or residency is an open invitation to massive vote fraud. As for selective checking, the answer to that is simple: don't be selective. Check all IDs for everyone, no exceptions. If everyone gets asked, it can't be discriminatory (except perhaps against noncitizens in the country illegally, and I don't think we should be kludging the voting laws to work around an immigration problem).
Again, this doesn't match what happened. I was registered, was on the registered-voters list for the precinct, hadn't moved since the previous election. They still required ID. They were requiring ID of everyone, no exceptions. And the list was being updated continuously, since you signed beside your entry to indicate you'd gotten your ballot, and was not posted anywhere that I could see besides in the book in front of the poll worker.
The only thing they really need electronic voting for is speed. They want the results faster than manual counting would allow. If you want a system at least as good as what we had, all you need is a system that produces machine+human-readable ballots.
When you vote, the machine when finished prints out a ballot with both machine-readable (barcode, perhaps) and human-readable versions of your vote. You confirm that it matches your vote, then drop it in the ballot box. The voting machine can hold an electronic tally internally which can be read after close of polls for a fast result. If there's a question of validity, you machine-scan the machine-readable portions of the printed ballots. As a check, you can compare the human-readable and machine-readable portions of a sample of the printed ballots to make sure the two really do match. If you select the sample randomly, it'd be statistically improbable for the voting machines to deliberately put incorrect machine-readable versions down without getting caught at it.
You can use smart-cards or whatnot for enabling a vote on the machine, and the traditional methods work for spoiled ballots. A one-use magnetic card like the airlines use for tickets would be even cheaper.
Given that it's not all that hard to design a system like that, I have to wonder why Diebold and the rest are so adamant about not doing it.
Asking for ID would be illegal in CA? Every election I've voted in here, they require a driver's license or other ID matched against the registration roll before they'll even give you a ballot. That's really the only way to avoid graveyard voting.
Remember that the receipt is actually a printed ballot, put into a ballot box at the polling place just like the current ballots. If the machine printed out one thing but recorded another, then during the inevitable recount (in CA a recount is automatic if the margin is less than a certain amount) they'll find a discrepancy between the results of the recount and the results reported by the machine. You start seeing that in several recounts, especially if it changes the outcome of the election, and there'll be enough of an outcry that an investigation will have to be started.
One catch: if I have proper security measures in place, any attempt by the router to connect to a server on my computer (eg. the AV software) will be blocked by the firewall on the client computer. What will the admins do if policy prohibits opening up client computers to incoming connections?
It isn't that broad. The company would, for example, have to specify exactly what resources were used and when. If they tried to claim "company time" outside of normal work hours, they'd be asked to produce the documentation where they specified that working those hours at home was part of the job description (just "as needed" wouldn't cut it). If they managed to document that, their victory would probably be followed immediately by a visit from the Wage and Hour people, however (again, in CA, the law has a very clear definition for who is exempt from overtime rules, and employment agreements and company policies can't make you exempt if the law says you're not). If they claimed it was related to his work, they'd be asked to provide documentation of exactly what work he was doing that the project was related to. If the company can't document it, they're unlikely to win a 2870 case. They might be able to make a case if he'd previously been assigned to a company project where the information/experience gained was crucial to the outside project, but mere access to information usually won't qualify without that extra.
There's the rub, though, the employee has to be willing and able to fight it through the process. You usually do this only when you're leaving the company anyway, because politically it's a major CLM.
Except that California law applies in this case, and California law is quite clear on the point. The employer may lay claim to things developed using company resources, or which directly relate to what you're doing for them now or which you're involved in R&D on. Any claim to things beyond what's allowed in 2870 is illegal and unenforceable. Salaried status is irrelevant as far as 2870 is concerned, an employer is not allowed to consider salaried employees to be "on the clock" 24 hours a day. In fact, where I work, right along with the IP-rights agreement they had to give me a 5-page explanation of 2870 that ended by saying, essentially, "The terms outlined here are the maximum allowed by law, any agreement your employer may ask you to sign that demands more than allowed here is illegal and void.". This has gone to court before, and the overreaching companies have consistently lost.
Years old? Exchange 2000 is probably running 75% or more of corporate Exchange installations. Exchange 2003 just came out this year, and the corporate world isn't even thinking about migrating to it until next year at the earliest.
Will Exchange 2003 even run on Windows 2000 (which is what most corporations are running on servers)?
Hmm, let's see. This is supposed to be private information at the moment. Should a person (or a company) have the right to keep sensitive information private if it poses no harm to anyone? I'm inclined to answer yes.
I'm inclined to answer yes to that question too, but that isn't the question in this case. The question is, once BestBuy has failed to keep the information private, do they have a right to force someone else to take on the duty of non-disclosure even though they haven't signed a non-disclosure agreement? That, I'm inclined to answer a big loud "No!" to. If BestBuy wants to keep their prices private, the onus is on them to keep them private, not the rest of us.
Disclosure of trade secrets only applies when the disclosing party had a duty not to disclose. That means, almost always, that they had a signed non-disclosure agreement. The other case would be where the information was obtained illegally and the disclosing party knew it was obtained illegally. In short, it's BestBuy's responsibility to keep it's secrets secret, and if they don't that's not Fatwallet's problem.
The only problem is the audit trail. All the Linux code is kept in either CVS or BitKeeper, both of which maintain a trail in the repository of exactly who changed what and when. IBM maintains at least that much of an audit trail as well. If SCO tries that, all IBM has to do is pull out the change log and trace the code back to it's original check-in. If the check-in was prior to SCO's code's alleged creation date, or was by someone with no access to SCO code, SCO has a world of explaining to do to the judge.
Probably not a derivative work under copyright law, but you'd run afoul of trademark on the characters (even if not registered). That's been a long-settled point of copyright law: you can't copyright characters, only the stories they appear in.
True, but when I see retyping like that they typically copy everything exactly. There's just enough differences in names and structural elements (braces and such) that someone had to think to get those variations. And there's still point 3, that the "copied" functions are very simple, things like basic wrappers that pass their arguments off to the real function. I could have come up with identical code without ever having seen theirs.