Thesis integrates with Wordpress, it is not derivative from it. Same way Linux modules integrate with the Linux kernel (and many of them are closed source).
If someone is using a public/open API, and not distributing any part of the software, it means they are not based on the other.
If that API is under the GPL then isn't use of it a derivative work? If the API is a GPL implementation of a standard API, e.g. the JDBC API, then it wouldn't be a derivative work, not sure if Themes call a wordpress specific API or not though.
I think that's a great question, and one that could probably spawn a ton of interesting legal/logical arguments.
At what point does dynamic linking make something a derived work - and how is dynamic linking fundamentally different, than, say, a remote procedure call (or SOAP or REST or whatever) over a network? The interface is different, but the principle is the same.
Also - the GPL does state that it's okay to link against things that are "standard parts" of the target system....
You know, lots of people talk about using keys instead of passwords... By doing that if you box is compromised, the attacker will get access to ALL your boxes.
So, the best option is to use an encrypted ssh key (so you have the type the pass everytime) or a good/different password for every box.
When you log in to an ssh host using a public/private key pair, the server only sees the public key. So by breaking and entering the attacker can disable your ability to log in in this fashion (by deleting the key) or can enable you to log in somewhere else (by copying the key, probably useless) but they cannot use that key to log in somewhere else absent modification of the SSH server. And even then I doubt they could get the private key, although they could probably run a MITM attack.
I believe s/he meant if the box you are using to log in is compromised, then all boxes your box has access to (by way of the private key it has in its file system) are compromised, whereas it seems you interpreted the comment to be implying that the host to which you are logging in (which only has the public key in its file system) has been compromised.
The point is that the computer on which you type becomes a lynch-pin.
Yes, if you have a computer with a private key that is available to the internet, and it gets knocked over, you're dead. Just as you would be if he knocked it over and installed a keylogger and you were using passwords. Cracked is cracked.
Assuming you are not running services on your main workstation, which is not that unreasonable (Ubuntu workstations are installed with 0 services available to the local network; my Mac has 0 services available by default), then you can get knocked over but it will probably happen because of an browser bug or something like that, i.e. not an active attack.
The whole point of keys is that knocking over one of the intermediate nodes in the network no longer gives you control over everything. Just because you rooted my server doesn't mean you can automatically log in to all my other machines, even if I'm using keys. Keys are better than passwords.
Good job researching those pesky brute force scans. Is there anyway you can post the complete list with all the data collected instead of just the top 50?
I expected a scan to go through the site looking at every possible bug, not just that 200/300 checks.
Looking at the full disclosure archives, lots of users mentioned that it is actually common for web scans to be that simple. I guess the technology is still new and most people don't care (as long as the result is a BIG GREEN - no bugs found).
Scanners cannot look for every possible bug. They can however, look for known bugs. And that's what most attempt to accomplish.
In a nutshell: The scanner looks for known files (thus you see a lot of 404's). If it finds these files, it may try another check (some query string or POST) to determine if it is the vulnerable version. The scanner then tries to inject some javascript for the XSS. If it sees the injected string in the body of the response, it may start modifiying the request until the javascript is actually valid, resulting in an alert window. If it doesn't see a response weith the injected code, the test is complete, move to the next. Finally, the scanner may look for backup files by taking the list of pages from the crawled site and appending things like .bak, .orig, etc.
If you were to take this scanner and run it against a site that returns status code 200 for every request, and echo's back the query string, I suspect you will see a more extensive list of checks that are performed.
What I would expect from this kind of scanner is that it takes every form on my website and try XSS with the actual parameters that I use, not just parameters that I probably would use.
That seems like a reasonable expectation. I guess I need to look at this article and scanner a little closer before I comment on what this particular tool does (or doesn't).
The reason they write poor code is because they are beginners and beginners always make mistakes, use functions incorrectly, etc. In any language they code, not just PHP.
PHP is often more visible because it is more used and easier to write... But if PHP wasn't that popular, we would see the same issue with Perl, Python, etc.
I could have been clearer with what I meant there, and I agree with you: it's not a problem specific to PHP, and in some ways it's unfair to label beginners' mistakes as problems in the first place.
The point I wanted to emphasize is that by reading lists like these new users might think that this is a good way to write PHP, whereas I strongly disagree with this list existing in the first place.
There's also the slightly selfish point of view of not wanting to have to clean up code like this should I come across it in future ;)
I agree with you. But beginners need to learn from somewhere and most advanced programmers are busy at work and not writing articles :)
Plus, did you ever read a PHP book? Most of them give bad examples and bad code practices too... I just read one that said to disable all apache logging (including error logging) for performance reasons.
PHP encourages shitty code because it is already shitty code in a shitty language. It's the broken windows effect. All you need to know is from Rasmus himself
"There are people who actually like programming. I don't understand why they like programming."
I was a professional programmer in PHP for just under 10 years so I'm not just bandwagon jumping. I don't get paid by yahoo to post here so I'm free to be as sloppy as I like.
Interesting discussion in there, but I think the PHP guys are right on this one. You should never rely on undefined behavior of any API for mission critical code.
Always use what is documented so you don't have to cry later..
The PHP guys are right in the same sense a store is right that it doesn't have to take a return without a receipt. But most stores will do so anyway in order to maintain good will. Whenever we come across undocumented or undefined behavior that will change in a new release, we try very hard to not change it unless it's absolutely necessary.
I would argue that it makes a lot more sense for a non-number to return NULL than to return 0. If it returns 0, how do you distinguish between "0" and ""? At least with a NULL return value you can use the function to see if you're even looking at a number at all.
Sure. And I haven't used PHP in about a decade. But it sounds to me like this was overlooked by them and so returned 0 for many years. Despite being undocumented behavior, fixing it causes a breaking change. On my team whenever we come into this situation and realize that fixing overlooked things can actually "break" people, we really think twice about the fix. Even if in theory the fix on its own is totally the right thing to do.
> fixing it causes a breaking change. On my team whenever we come into this situation and realize that fixing overlooked things can actually "break" people, we really think twice about the fix.
Answered in the 2nd comment from Rasmus:
If this was changed in a minor version, I'd
agree with you on the BC change, but we have been working on catching these weird edge-case scenarios that lead to unexpected bugs.
i.e. they thought about it and decided this version was an acceptable one for making breaking changes.
I'd take the other side... but I can understand them choosing either way.
My vote for the other side is because php guys didn't document the change. Other pages show exactly what happens in strange cases - like in "If delimiter is an empty string (""), explode() will return FALSE." There's no mention about the change on http://php.net/manual/en/function.number-format.php and they list the result as "string" without any other notes. Making the function backwards compatible wouldn't hurt anyone either, because it would restore the behaviour for people using "" and would change nothing for ones using normal values all the time and ones who started casting to a number because of this change. But yes - it's pretty much php guys' call.
Seems reasonable. And I don't think you guys got the humor when he said "Escalate". You all want to think you're SO smart and nobody else can pick his nose. Obviously he knew who he was talking to, do you really think he uses PHP and doesn't know who he was dealing with?
Anyway, saying they wouldn't fix it is fine, but the bitchy answers he got to legitimate questions just shows how juvenile R is.
When I first read it quickly I thought it sounded a fair complaint, then I saw this comment and figured I should think again. On 2nd read I picked up the subtleties re: undocumented behaviour, reason behind the change & effect reverting it would have and yes, I think I agree after all.
This would work if programmers actually documented their code.
I remember posting similar sentiments on Reddit about 3 years ago and getting downmodded to oblivion. In hindsight, I think I was wrong and the herd was right. If you restrict yourself to what's documented, you'll miss out on most of the interesting and cutting-edge stuff. And that's what lets you build a cool, differentiated, useful project.
Instead, I think you should budget time and money for crying later. ;-)
