>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #509010. --> Reported by: [JacobSingh](https://www.drupal.org/user/68912) >>> <p>This is a dependency of:<br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/395474" title="Status: Closed (fixed)">#395474: Plugin Manager in Core: Part 2 (integration with update status)</a></span> and<br> <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-3"><a href="https://www.drupal.org/project/drupal/issues/395478" title="Status: Closed (duplicate)">#395478: Plugin Manager in Core: Part 3 (integration with installation system)</a></span></p> <p>In an effort to be better than that other CMS which just released a damn sexy package manager, we've got to catch up. The efforts listed above should provide a nice UI and the functionality to do it. A missing piece is package signing, something WP.com doesn't do AFAIK.</p> <p>There have been a lot of discussions about this, and I'm sorry if this should be on another issue, but here is my idea about how and why we should use openSSL:</p> <p>1. It's available on the majority of sites. Acquia Network reports that over 85% of sites phoning home have it. I imagine 10% of the ones who don't are sandboxes. Those who don't have it, will get a big fat warning and in 99.9% of cases, there is not issue. If they don't have a way to sign packages, that's a risk they have to take. If someone feels really called to make it degrade into some text boxes to shove in MD5 sigs, be my guest (it won't be me).</p> <p>2. It doesn't require the user to know anything, or to go around hunting for md5 signatures or to do some funny JS tricks to get them from d.o. I think this is really important. The whole point of this venture AFAICT is to give "normal" users a very simple, usable way to keep up to date and install new extensions to Drupal. (A Drupal core updater is probably a D8 task given that Drupal is not setup to run from outside of itself very well).</p> <p>3. It's damn secure. The only weak spot is the private key on the server, but we plan to lock dww in the server cabinet and have the key installed in his brain Johnny Mnemonic style. Should work, plus he might just start looking like Keanu Reeves.</p> <p>4. It is possible to have a central key server, and mirror the files off to other places. This will be important for scalability.</p> <p>5. It really shouldn't be too hard. Included is a tarball which gives you all the pieces you need to try it out.</p> <p>I'm guessing that we would include the signatures in update-status reports, and for new installs, we would need a way to pull them via a webservice. That can be a follow up issue.</p> <p>For the time being, here are the goals:</p> <p>1. Create a key pair. Store the private on the server. Store the public in CVS as part of Drupal core.<br> 2. Modify the packaging scripts to create signatures of every release and store them like the MD5 is stored now.</p> <p>On the client side, I'll work on implementing the key verification and warning if SSL isn't installed in the issues mentioned above.</p> <p>How 'bout it! Are we ready to kick some ass and make Drupal as easy to update as Ubuntu? (joking)</p> <p>Best,<br> Jacob</p> > Related issue: [Issue #1538118](https://www.drupal.org/node/1538118) >>> [!note] Pre-migration files - [ssl\_fun.tar\_.gz](https://www.drupal.org/files/issues/ssl_fun.tar_.gz) >>>