It means if you have a PHP script or application (Wordpress, Drupal, etc) on your server, and there's code in the script or application that uses one of the `pcre_` functions, and that the regular expression passed to that `pcre` function uses user input to create a regular expression, then an attacker can theoretically run any unix command on the server. This means your user information (including any passwords in text files) is vulnerable, and it puts the attacker in a great position to gain full access to the server.
Until PCRE or PHP release a patch for this, you remain vulnerable. You'd want to defend against this at the web server level -- think `MOD_SECURITY` rules that scan requests, look for known "bad" regular expressions, and then stop that request from reaching the PHP application. If you have a good hosting company hopefully they're already doing this for you.
Yes and no. The PHP language and run-time continue to value backwards compatibility and, ultimately, a PHP application is still just a collection of PHP files sitting on a web server somewhere. If you want to work like it's 2006 you can.
However -- Modern PHP (Laravel included) bring a few winkles to the table and most deployments will have extra complications for folks expecting to just "FTP a file" (also, I hope you meant SFTP a file (-:)
For example, Laravel (similar to rails) has migrations for creating and updating your database schema. You don't need to use migrations, but if you do your deployment becomes a bit more complicated.
Also -- although PHP namespaces have come a long way, they're still not up-to-par with (or, in PHP group-speak "have different goals than") ruby or python's module system. The Composer packaging system has stepped in to fill this gap, but this means a modern PHP deployment needs to
1. Generate composer autoload cache files
2. Fetch, download and install any updated composer packages (i.e. third party libraries)
Again, there's nothing stopping you from working locally and SFTPing or rsyncing all your local files (composer packages/autoload files included) to the server, but most teams develop a more formal deployment process than that.
How you host your PHP application is going to effect how you deploy. There's still many, many PHP hosting companies offering `mod_php` based hosting, but there's also a large number of projects who use a Fast-CGI/FPM approach (either with Apache or nginx). The difference in process models brings a different in the unix permissions model, and that often means there's extra steps needed to ensure file based cache system can write to their storage engines.
And speaking of caching, 20% of any "serious" PHP developer's time is spent sorting out the various framework level caching systems, as well as PHP based opt-code caching. I mention this here mainly to point out that some sort of cache refresh and/or warming is common in signifigant/long-standing PHP systems.
Deployment's still easier in PHP than in other frameworks, but if you're expect a wild west "just edit files on the server and you're good to go", expect push-back from your modern, professional, PHP developers :)
We're looking for a lawyer to help finish up our merger. The previous guy did 90% of the work and then stopped responding to our emails!!! This shouldn't take an experienced lawyer more than a few hours.
One of the most damaging things in cultures where agreement is more valued than honesty is how it can sap the morale of your workers to the point where they turn into exactly the uncooperative super-negative people you were trying to avoid in the first place.
TL;DR; If you have the talent to do the sort of work these sorts of services require, then you have the ability to do it without them.
Just my two cents here (with the caveat I could be talking out of my behind since I don't know these people), but I'd discourage anyone considering a career in freelance design/development from using these sorts of services.
The hardest part of making a long term go at this sort of work is learning how to sell yourself and having the hard discussions about business, money, and commitments. Using these sorts of services rob you of that experience, and your working relationship ends up being more employee than independent, but without the hard fought protections employees deserve.
What these services promise you is high quality projects, and an escrow service for getting paid. You can, and should, set these sorts of protections yourself. If you are going to try out these sorts of services as training wheels, be sure to carefully read anything they have you sign, and make sure it could never be used to impact your future, 100% independent career.
That's solid advice, but only follow it once a sense of trust and rapport has developed between you and the client.
There's far too many things a potential client may not be telling you about the project, and it's incredibly hard for the independent freelancer to do enough business development, or for the client to do enough vetting, to know which random internet person is trustworthy. This is especially true when you're just starting out.
A one week sprint that solves a small, immediate need the client has will keep the project manageable, and protects both the freelancer and the client from a potentially bad situation. Worse case scenario, one of you is out a week's work. Best case scenario, after a few sprints a rapport and trust develops, and you can start providing your clients with estimates for larger pieces of work, knowing they'll be treated as estimates and not fixed bids.
Don't eliminate the appearance of uncertainty when you're legitimacy uncertain. That's bad communication. If a client needs solid estimates out of the gate they don't need an independent freelancer. They need a full-service agency.
HINT: For the purpose of this hint we'll assume your script is a bash script. If you've exploited the setuid program to run your script, bash may execute with the elevated permissions, but any program bash runs will run with your permissions.
I'm not sure how useful public shaming and griping are, but I do think it works on the iamayoungconsultantandnoonetalksaboutthis.com level. I'd have found the stories super useful as an insecure 25 year old "forced" into the freelance market.
Put another way, republishing an otherwise unavailable CC-licensed/open-source-licensed work is explicitly respecting the author's wishes, the author that published it under that license.
I doubt (but obviously don't know) Mark wanted to excise his work from human memory, he just didn't want the personal responsibility of maintaining those resources/participating in their development as a leader. That's the wish worth respecting.
Run the numbers, calculate the percentage of your income lost, and just consider it another unavoidable cost of doing business. I imagine you don't like paying Paypal, Google Checkout, or merchant account transaction fees, but I also imagine you don't feel personally slighted at having to pay them. Put people exploiting your refund policy in the same bucket.
If this is a subscription service, automate the refund process such that you can you can send a single email with a link that will let them provide feedback, cancel their service, and refund their money.
If you're selling software bits consider a serial number system that will allow you to remotely disable people who have requested refunds. Also, keep your refund policy but stop advertising it. This way you prevent bottom feeders from even knowing it's an option. If you notice this is costing you more sales than you gain, go back to advertising it and re-read paragraph one.
File under: Unintended Consequences. Also, Postel's law could probably be tricked into admitting itself as an accomplice.
1. Browser based Javascript provides a location object for managing and accessing the current browser location, and this location object is available as a global variable.
2. Browser based Javascript also provides a special case in the interpreter/processer/etc., where setting the location object equal to itself will reload the current page. This is also true for certain properties of the location object (href)
3a. There is also a more conventional reload method on the location object which accepts either a location object or string href. Also, many of the "go to this URL methods" exposed to Javascript will interpret "go to the url I'm at" as a request to reload the page. Many of these methods will accepts a location object, or a string representation of a URL as a paramater.
3b. location.href is a string representation of a URL
3. There are many ways to access global variables in Javascript. There are many ways to assign a value in javascript. There are many ways to call a method in javascript.
4. All of the above can be combined into lots (likely more than the 535) of ways to achieve the same thing.
I can't comment specifically on the Fuel framework, but it's probably going to take years (if ever) for "the right" way to use namespaces to emerge among the PHP communities. There's been a decade plus of ingrained name-spacing by convention that PHP developers will need to shed
You can't read Gruber in the same context you did five or six years ago. At this point he's an established journalisty blogger who depends on a network of sources, some of whom are within Apple Inc. That means, like most working journalists, he needs to consider the tone he takes with any individual article vs. what that article is going to do to his network of sources. The result is his writing still contains the smart incisive analysis it always has, but he also has to bend over backwards to make sure he's presenting what the the internal Apple take on the situation is. Compared to what you or I might say about Apple's behavior over a few beers, yeah, he comes off sounding like an apologist, but compare his coverage to what other in-the-tank tech writers say about Apple and he still comes off as an independent voice covering the company AND someone who can provide a level of context other people can't (details on Nitro's implementation)
It's probably a part of a longer term pricing strategy. It's hard to start charging "real" money (even $40/$50) for an application you were formerly giving away for free. People feel like you've taken something away. By charging a micro-payment disposable price of $5 (Happy Meal, Latte, etc.) they deflect a lot of that criticism and avoid some of the negative publicity. Over the next 10 years they can slowly raise the price, each time keeping is reasonable.
Apple's leveraging the work they put into building the App Store infrastructure (and business deals with credit card companies) to do something a lot of other companies couldn't (make something that was free cost something again without too much fallout).
Half of me says awesome, while the other half is slightly-creeped-out that scammers no longer need to stop at "nah, writing scraping scripts for bank websites would be way too much work!".
I'm not speaking for Stallman of GNU here, this is pure conjecture based on too many years of following these discussions. The "problem" with public domain software, (and BSD/MIT) style licenses, is people can take that code, make changes, and seal it back up into proprietary binaries where users lose access to the source code. The ideal world that the Richard Stallman character wants is one where if you're using something that was built with code, you have access to that code, and can't be stopped from using that code. Everything that people in the GNU camp do is towards that goal. Their choice to assert a GPL copyright (or copyleft, if you want to get really hippie) is a pragmatic one, because they recognize that the power dynamics of business lead companies to stop sharing most of what they're working on.
Until PCRE or PHP release a patch for this, you remain vulnerable. You'd want to defend against this at the web server level -- think `MOD_SECURITY` rules that scan requests, look for known "bad" regular expressions, and then stop that request from reaching the PHP application. If you have a good hosting company hopefully they're already doing this for you.