Remove patch source restriction. [#1990910]

Hi Patrick,

I had a lightbulb go off tonight regarding some pretty interesting stuff I want to try out with simplytest.me, but it hinges on a dynamically generated patch file, which for obvious reason (the dynamically generated bit) it can't be hosted on Drupal.org.

I suspect that there might be a source restriction, and upon searching through the code I did come across said restriction, and while I get it to a certain point, it also occurred to me that a patch hosted on D.o has no vetting process, so anything potentially evil someone may attempt with a patch could as easily be done on Drupal.org as it could on any other provider.

So I guess I wanted to see if there is anything I may have overlooked to why said restriction is in place, and also if it is an unquestionable restriction, discuss alternatives for what I'm trying to achieve, such as a services based API for approved users or similar.

Cheers,
Deciphered.

Comments

Comment #1

patrickd CreditAttribution: patrickd commented 9 May 2013 at 13:01

Drupal.org allows only certain extensions to be uploaded, for example it's not possible to upload executable files, archives or other stuff. That's why the restriction was was set, it was just the easiest and most secure way to go in my eyes.

For sure the patch itself could contain malicious / flawed code but that's just the way it is - I mean you can launch a sandbox with the devel project and execute PHP... so that's not really secure anyway.

The site basically makes some checks whether the given URL is hosted on Drupal.org and is a valid and existing text-file.
On the server it gets downloaded with a simple wget-command and then applied with "git apply"

For sure these restrictions are rather security-by-obscurity but I still don't like the idea of allowing all sources...
Maybe a white-list instead.. or better checks to make sure it's really a apply-able git patch

Comment #2

Deciphered CreditAttribution: Deciphered commented 9 May 2013 at 23:13

Well, I suppose at the minimum you'd want to restrict the filetype to a patch, but is there even any ill effects (other than doing something naught with the patch itself) that can happen running a malicious file through 'git apply'?

However, for the sake of not risking it, the whitelist approach should be fine, but I guess there will need to be some form of application process.

Comment #3

patrickd CreditAttribution: patrickd commented 10 May 2013 at 07:54

That's my biggest problem, I don't know, but that doesn't mean there aren't any possible.
It's a matter of risk and I think it's better to make a white-list than taking the risk, as removing the source restriction completely doesn't seem to be a major improvement to me.

The application process should basically be that anyone who wants his page whitelisted creates an issue here in the queue describing why. If it's a better reason than "just for fun", it's okay for me - this way we can at last keep track of the sites in the list.