The padlock module is designed to limit the functionality of Drupal forms by setting a validation error unless the form is allowed to be submitted in the module configuration. The module also provides a permission to bypass the padlock validation for roles with the elevated permission. Use Cases: Integration / Staging Sites / Training Sites Testing deployment scripts and processes. Allow the review of a form without the submission of the form. Locking specific forms without removing the entire permission set for that role.
This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release). There will be no bug fix release on this date; the next window for a Drupal core bug fix release is Wednesday, January 7.
the PSA also resulted in a large volume of press coverage – in fact much more coverage than the original disclosure of the vulnerability on October 15th. Not surprisingly, the general tone of the press coverage was quite negative. Unfortunately, some of the coverage was also inaccurate which we’d like to address here as well as provide additional context regarding our security processes. While we don’t know the total number of Drupal sites affected, the number is not near 12 million as stated in several publications.
SELinux provides confinement on an application if the application has been hacked, even if the application is running as root. If policy says the Apache process is only supposed to read Apache content, then even if a hacker gets uid = 0 (the root user), he will not be able to turn it into a spam bot; he will not be able to read credit card data in your home directory; and he will not be able to destroy log files. The hacked process will only be able to act as an Apache process.
This is not a module, it's a Drush command that makes it possible to check for known indications of your site having been exploited with the vulnerability fixed in SA-CORE-2014-005. See also SA-CORE-2014-005 FAQ Greg Knaddison's "Your Drupal site got hacked. Now what?" Bevan Rudge's workflow chart
Drupal.org hopes to deploy two-factor-authentication to enhance the security of the site. This tool will help to ensure that accounts with advanced permissions are only used by the intended individual. The Two Factor Authentication module for Drupal tfa was originally built by Growing Venture Solutions, has been dramatically enhanced to work for Acquia, and is being made “drupal.org-ready” with support from CARD.com.