Checksum Iframe

Indeed the problem with pre-filling md5 is that the module then becomes vulnerable to DNS poisoning attacks. Allowing an admin to say "don't worry about md5" could be interesting, but it's also a bit of a security weakness and I'm not sure it's that great of an idea.

Another solution would be to use https when downloading the files, though I think that the fact that drupal.org uses a self-signed SSL certificates wouldn't work very well for that.

I am inclined to mark this as "by design" (yes, we want it to be a bit manual so as not to make things too vulnerable) or "postponed" (an alternative design/future solution may be considered)

drupal.org is being redesigned. Perhaps they will splash out on an SSL cert? That would be cool and solve the issue I guess. So I would say postpone until then.

What an interesting discussion though. I would bet that if you could take statistics you would discover that 99% of packages downloaded from drupal don't have their MD5 sum verified. Now we want to enforce it for people using this module. However I also understand if you say "we shouldn't be insecure just because everyone else is insecure."

A lot of open source software runs on a principal something like "secure by default, opportunity to make it as insecure as you want" which I quite like. But in the end I believe we owe a lot to those writing the module and they can make whatever decisions they like, the rest of us have to be grateful for what we've got.

EDIT: Actually now that I think about it - I'm not sure how downloading over HTTPS via PHP works but in SSL theory, as long as you know which certificate you should be presented with it doesn't matter whether it's self-signed or not. It's like a pre-shared key. What I mean is, I can create a self-signed certificate for drupal.org, I keep the private key and give you the public key over a secure channel. The fact that it's not signed by a real CA doesn't matter. You code the public key into the module and the module simply checks the public key is correct when it connects.

I see two potential solutions to this problem. One, is to use an iframe (for the project page), and still have the user copy/paste the checksum. This would significantly reduce the tedium, but not completely, while retaining all of its security.
The other is to use AJAX (as was mentioned before) to grab the checksum (a patch for which I could easily code), which would *completely* remove the tedium -- the user would just need to wait the few seconds while the AJAX loads.
I believe this second way would be best, and I don't think it would be any less secure.
Can anyone see potential vulnerabilities in the second solution?

What about DNS cache poisioning? This was the main reason we mandated manual entry of the checksum.

AJAX would still be vulnerable to that, right?

Now that I think about it, AJAX probably wont work for this. Currently, AJAX requires that the requests are made to the same domain, but we want to get data from drupal.org. Now there are two fixes for this:
We grab the page serverside and serve it up unchanged to our AJAX to parse (which I believe is subject to the security problems outlined above)
Drupal implements JSON on up updates.drupal.org (which gets around AJAX's same-domain restriction.

This second one would be ideal, but I'm not sure how likely it is to happen (though I believe it would be relatively simple for them to do......)

So for the time being, iframes are probably the best way to go.
Meanwhile, how do we convince updates.drupal.org to implement JSON?

Continuing the SSL idea... from my short research it seems you need to use libcurl to check security certs. There's a bit of code here where the guy uses this:

$this->connection=curl_init("https://drupal.org");
curl_setopt($this->connection, CURLOPT_SSL_VERIFYPEER, TRUE);
curl_setopt($this->connection,CURLOPT_CAINFO,"cacert.pem");
curl_setopt($this->connection, CURLOPT_VERBOSE, TRUE); 

In the case of drupal.org, I think it's using a cert signed by cacert.org. You just have to include the public key file available here http://www.cacert.org/index.php?id=3 in your module and reference it in the third line of the above code and you can be certain that you are talking to drupal.org (DNS cache poisoning not possible).

That's the technical side. I don't know about the architectural issues, like whether introducing dependencies on libcurl is acceptable.

how standard is libcurl?
And also, we can detect libcurl and get the checksums automatically if it's there, and manually if it's not.

Heres a little patch to add an iframe above each md5sum input on install page 2 -- which i think is a great improvement over the current situation. Now, if I can get the ajax thing working, or maybe the SSL, this will become unneeded, but I think for the moment it would greatly improve the interface.

Attached are the patch and a screenshot.

That looks like a good compromise to me. It makes the interface quite busy, but on the other hand it involves many fewer pages/tabs/clicks which makes it easier - especially for people who are uncomfortable with tabs.

So, I've committed the iframe patch, which is currently the best solution available. If anyone thinks of a better way to do it, feel free to let me know.

In answer to #12 - I installed the home module yesterday and (co-incidentally) I discovered that it required libcurl (without stating that explicitly in any doco - it just complained about its absence and fell over).

I just had to go into php.ini and uncomment the line where it is enabled. (XAMPP on windows). So that was simple. I'm sure you'd be able to auto-detect it... phpinfo() does something like this.

"I just had to go into php.ini..." is fine on your own server but may be a problem on hosting. Could libcurl be optional?

I maintain a module that required it in the past (currency exchange), and changed it over to use drupal_http_request() which has more chance of working on more hosts. curl will not be available in all installation.

We can do something like this:

if (function_exists('curl_init')) {
  // Use curl to get the checksums
}
else {
  // Do it the way we do it today, painful copy and paste, with a drupal_set_message() or something to 
  // the effect that curl is not enabled, and it would be a better experience if they enable it
}

all this libcurl stuff is still hypothetical, b/c drupal doesn't have https, right?

Yes, drupal.org does not have a proper SSL certificate.

But, still, even if it did, requiring curl would make for one more added dependency.

Let us discuss this in a new issue, since this one is marked as fixed, and it is about iframes.

d.o has a certificate, just that it is not signed by a widely used root certificate.

Try https://drupal.org/node/292920 - it works.

Plus, if we needed a widely accepted cert for something like this we could get it.

the problem w/ not having a *signed* cert, is Plugin Manager will have no way of verifying that d.o is who it says it is. The purpose of getting the md5sums via ssl is to prevent middleman attacks.
If drupal.org got certified, then we might well be able to remove this (somewhat annoying) step of getting md5sums

Well... do you use SSH? Do you consider it secure? It's actually a lot less secure that using HTTPS to contact drupal.org.

SSH has no checking of certificates against any authority. The only check is to make sure that the certificate presented this time is the same as the one that was presented last time. That's what the message is about the first time you SSH into a host, something like "Do you want to connect to this host?" Then "Caching this host's fingerprint". Your computer just remembers the certificate to check that it's the same next time. I could be the man-in-the-middle on every single SSH connection you make to a certain server and you would never know.

HTTPS on drupal.org is on the other hand far more secure. drupal.org uses an SSL certificate signed by cacert.org. If you trust cacert.org, then you can trust that you are talking to drupal.org when you go to https://drupal.org. There is no chance for "man in the middle".

It's easy to mistakenly believe that drupal.org has an invalid or non-functioning security certificate, because if you visit it in your browser, your browser says something like: "drupal.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted."

However you will discover the truth if you read between the lines. The company that produced your browser decided to trust certain root certification authorities, like "Verisign", so any certificate that Verisign signs is automatically accepted by your browser. The company that produced your browser did not decide to trust "cacert.org", which signed the drupal.org certificate. That's why you get the error. However, if we choose to trust cacert.org then we can put their public key in the module and we have 100% assurance that we are really talking to drupal.org.

Summary: Drupal uses a totally valid SSL certificate. To the extent that you trust cacert.org, you can trust that https://drupal.org is secure. I think that cacert.org is worthy of our trust. Therefore, we can use HTTPS in a fully secure manner.

awesome. Ill start working on a patch to use ssl/curl if its available.

OK, have opened a new thread here: #312414: Use HTTPS to download packages.

By the way, in response to #24 I wasn't really attempting to discuss or criticise the use of SSH in the module, rather to use SSH as an general example to explain my point, because most people consider SSH to be very secure.