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.
Those are all great points, but I want to differentiate matchist from "these sorts of services." We focus on making quality connections to people you would otherwise not meet (whether geographic barriers, time limits, etc). Services in the past have worked on automating these interactions and end up in a price war towards the bottom: we get to know devs as people and only give them projects they would pick themselves. We want to streamline freelance so that freelancers do what they do best instead of being in meetings all day.
My understanding is that GroupTalent works with bigger companies to subcontract freelance talent. We are not working with large companies, but entrepreneurs/agencies/smaller entities.
that's good to know. another difference is that GT works with teams (correct me if I'm wrong) and matchist is currently one developer matching per project
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.
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.