Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • It Has Been X Days Widget

    It Has Been X Days Widget

    Yesterday I talked about ordering posts by post meta in a weirdly unique situation. Today I’m going to tell you about an even weirder one.

    As I mentioned, what I’m working with is a list of all the dead characters recorded on a site. One of the aspects of this is to allow for us to show a widget that tells visitors how many days it’s been since the last death, and who it was. There are a lot of ways to do this, and one of them is manually updating, but no one likes this. If an event can be automated, everyone wins.

    Since I’d already done the lion’s share of the work, forking it over into a widget and grabbing the last (i.e. most recent) death was easier.

    The Code

    I broke this up into two classes because it’s habit. I have no other reason.

    class Dead {
    	public function __construct() {
    		add_action( 'widgets_init', array( $this, 'register_widget' ) );
    	}
    
    	public function register_widget() {
    		$this->widget = new Dead_Widget();
    		register_widget( $this->widget );
    	}
    
    	public static function dead_queers() {
    		// Get all our dead queers
    		$dead_chars_loop = new WP_Query( array(
    			'post_type'       => 'post_type_characters',
    			'posts_per_page'  => -1,
    			'meta_query'      => array(
    				array(
    					'key'     => 'chars_death_year',
    					'value'   => $thisyear,
    					'compare' => 'REGEXP',
    				),
    			),
    		) );
    		$dead_chars_query = wp_list_pluck( $dead_chars_loop->posts, 'ID' );
    
    		// List all queers and the year they died
    		if ( $dead_chars_loop->have_posts() ) {
    			$death_list_array = array();
    
    			// Loop through characters to build our list
    			foreach( $dead_chars_query as $dead_char ) {
    
    				// Date(s) character died
    				$died_date = get_post_meta( $dead_char, 'lezchars_death_year', true);
    				$died_date_array = array();
    
    				// For each death date, create an item in an array with the unix timestamp
    				foreach ( $died_date as $date ) {
    					$date_parse = date_parse_from_format( 'm/d/Y' , $date);
    					$died_date_array[] = mktime( $date_parse['hour'], $date_parse['minute'], $date_parse['second'], $date_parse['month'], $date_parse['day'], $date_parse['year'] );
    				}
    
    				// Grab the highest date (aka most recent)
    				$died = max( $died_date_array );
    
    				// Get the post slug
    				$post_slug = get_post_field( 'post_name', get_post( $dead_char ) );
    
    				// Add this character to the array
    				$death_list_array[$post_slug] = array(
    					'name' => get_the_title( $dead_char ),
    					'url' => get_the_permalink( $dead_char ),
    					'died' => $died,
    				);
    			}
    
    			// Reorder all the dead to sort by DoD
    			uasort($death_list_array, function($a, $b) {
    				return $a['died'] <=> $b['died'];
    			});
    		}
    
    		// Extract the last death
    		$last_death = array_slice($death_list_array, -1, 1, true);
    		$last_death = array_shift($last_death);
    
    		$diff = abs( time() - $last_death['died'] );
    		$years = floor($diff / (365*60*60*24));
    		$months = floor(($diff - $years * 365*60*60*24) / (30*60*60*24));
    		$days = floor(($diff - $years * 365*60*60*24 - $months*30*60*60*24)/ (60*60*24));
    
    		$days_since = '';
    		if ( $years != 0 ) $days_since  .= $years .' '. _n( 'year, ', 'years, ', $years );
    		if ( $months != 0 ) $days_since .= $months .' '. _n( 'month', 'months', $months );
    		if ( $years != 0 ) $days_since  .= ',';
    		if ( $months != 0 ) $days_since .= ' and ';
    		if ( $days != 0 ) $days_since   .= $days .' '. _n( 'day', 'days', $days );
    
    		$return = 'It has been <strong>'. $days_since .'</strong> since the last death: <a href="'.$last_death['url'].'">'.$last_death['name'].'</a> - '.date('F j, Y', $last_death['died'] );
    
    		echo $return;
    	}
    }
    new Dead();
    
    class Dead_Widget extends WP_Widget {
    
    	protected $defaults;
    
    	function __construct() {
    		$this->defaults = array(
    			'title'		=> 'Bury Your Dead',
    		);
    
    		$widget_ops = array(
    			'classname'   => 'dead-queer deadwidget',
    			'description' => 'Displays days since the last death',
    		);
    
    		$control_ops = array(
    			'id_base' => 'dead-person',
    		);
    
    		parent::__construct( 'dead-person', 'Days Since Last Dead', $widget_ops, $control_ops );
    	}
    
    	function widget( $args, $instance ) {
    		extract( $args );
    		$instance = wp_parse_args( (array) $instance, $this->defaults );
    
    		echo $before_widget;
    
    		if ( ! empty( $instance['title'] ) ) {
    			echo $before_title . apply_filters( 'widget_title', $instance['title'], $instance, $this->id_base ) . $after_title;
    		}
    
    		echo Dead::dead_chars();
    
    		echo $after_widget;
    	}
    
    	function update( $new_instance, $old_instance ) {
    		$new_instance['title']      = strip_tags( $new_instance['title'] );
    		return $new_instance;
    	}
    
    	function form( $instance ) {
    		$instance = wp_parse_args( (array) $instance, $this->defaults );
    		?>
    		<p>
    			<label for="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>">Title:</label>
    			<input type="text" id="<?php echo esc_attr( $this->get_field_id( 'title' ) ); ?>" name="<?php echo esc_attr( $this->get_field_name( 'title' ) ); ?>" value="<?php echo esc_attr( $instance['title'] ); ?>" class="widefat" />
    		</p>
    		<?php
    	}
    }
    

    Which looks like this:

    Bury Your Queers

    An Explanation

    Some things to note.

    While I only allow for customizing the title, I’ve left my arguments as an array in order to let me extend it later. What if, for example, I want to display the featured image as well?

    I’ve also left in some ‘default’ calls to Genesis’ StudioPress theme with regards to the widget layout. That’s because I wrote this for a StudioPress theme.

    The whole reason the death year is an array is that, as I mentioned the other day, people may die multiple times. Insert Buffy singing “Hey I died twice” here. I have to get all the dates, pick the largest number (which is the most recent date, remember Unix timestamps are forever increasing), and save that one. Once I find the ultimate largest number, I know that’s my character to save. Problem is I have to go through them all to figure out who died last.

    I’m inordinately happy about getting to use array_slice() to grab the final item in an array, and ditto array_shift() to move the multidimensional array to a single dimension.

    Using array_shift() changed this:

    Array ( 
        [gina] => Array (
            [name] => Gina 
            [url] => https://example.dev/character/gina/ 
            [died] => 1481068800 
        )
    )
    

    to this:

    Array ( 
        [name] => Gina 
        [url] => https://example.dev/character/gina/ 
        [died] => 1481068800 
    ) 
    

    And getting to finally use _n() in a non-translation sense was fun.

    The reason the dead characters are in a function in the first class is that I plan to extend this code later on, maybe making a shortcode or a JSON API call. Who knows!

    Finally, I mentioned that there were two ways to list the dead characters. One was by a taxonomy of character clichés and the other was by the death date post meta. In this case, I opted to sort by the taxonomy because if someone has a death date but is not marked as dead, then they were dead and came back to life.

  • Display Posts, Ordered By Post Meta

    Display Posts, Ordered By Post Meta

    One of the things I’ve been working on over on my tv project was getting better lists of characters who died. Initially all that we recorded was the year. However we started getting the idea of a timeline and a calendar and a ‘this year in queer TV’ section, and I realized I needed more precise data.

    I’m going to skip the headache part here, but I changed the year dropdown to a calendar date field that stored the date as MM/DD/YYYY. While some calculations would have been easier with the time saved as a UNIX timestamp, having it be text let me search as text to collect all the death for a year. There were pros and cons to both sides of the coin of how to save the data. The other trick was I needed to save the data as an array. Just in case someone died twice.

    Suffice to say, here’s your scenario. I have meta data in the post containing the date of character death, and I want to display it in a specific way, not supported out of the box by the default queries.

    Display all the dead in a list ordered by date

    The simple part in WordPress is to get a loop of all posts in a type that have the meta for death. Using WP_Query I grabbed the array and instead of saving all the post’s data, I extracted the data I needed:

    • character name and URL
    • date of death
    • list of shows and their respective URLs

    This I turned into a very simple array that I can use in multiple situations:

    $dead_chars_loop = new WP_Query( array(
    	'post_type'       => 'post_type_characters',
    	'posts_per_page'  => -1,
    	'meta_query'      => array(
    		array(
    			'key'     => 'chars_death_year',
    			'value'   => $thisyear,
    			'compare' => 'REGEXP',
    		),
    	),
    ) );
    $dead_chars_query = wp_list_pluck( $dead_chars_loop->posts, 'ID' );
    
    foreach( $dead_chars_query as $dead_char ) {
    	$show_info = get_post_meta( $dead_char, 'chars_show', true );
    	$died = get_post_meta( $dead_char, 'chars_dead', true );
    
    	$output_array[$post_slug] = array(
    		'name'  => get_the_title( $dead_char ),
    		'url'   => get_the_permalink( $dead_char ),
    		'shows' => $show_info,
    		'died'  => $died,
    	);
    }
    

    This array is made by looping through those WP_Query results and, for each character, grabbing the post meta data for shows and death. The simple array $output_array contains only the data I need for display. So no post content, no author, nada. Just the name, the URL, the shows, and the death. That said, I’m omitting my insane extra loop for generating $show_info with its links because it deserves its own post. Suffice to say, it’s weird. Oh and $thisyear is a page variable based on the URL you visit. If you go to /this-year/2015/ it will populate as ‘2015’ and so on.

    Side note. Characters actually have both a taxonomy for being dead and a lost meta for the date. That was a happy accident that allowed me to search for everyone who had died, and perhaps wasn’t currently dead. The time traveling Sara Lance is jokingly called Schroedinger’s Bisexual, since she is both alive and dead at any one given point in time.

    Fix The Date

    Okay! With my simple array of data, I can output the list however I want, depending on the way I ordered the query. The problem is that the query has a limited number of possible sorts, and they all have to do with the post subject, the title, not random post meta. Plus my post meta was saved in a way that wasn’t easily sortable.

    To solve this, I converted the date into a Unix timestamp:

    // Date(s) character died
    $died_date = get_post_meta( $dead_char, 'chars_death_year', true);
    $died_date_array = array();
    
    // For each death date, create an item in an array with the unix timestamp
    foreach ( $died_date as $date ) {
    	$died_year = substr($date, -4);
    	if ( $died_year == $thisyear ) {
    		$date_parse = date_parse_from_format( 'm/d/Y' , $date);
    		$died = mktime( $date_parse['hour'], $date_parse['minute'], $date_parse['second'], $date_parse['month'], $date_parse['day'], $date_parse['year'] );
    	}
    }
    

    I put this in the foreach( $dead_chars_query as $dead_char ) {...} section and it transformed my date from 01/01/2017 to it’s commiserate Unix timestamp.

    Fix The Order

    The next step was to re-order my array based on the value of the death time. I wanted to go from smallest value to largest, as Unix timestamps increase over time.

    For this I used uasort to order the entire array by the date:

    // Reorder all the dead to sort by DoD
    uasort($death_list_array, function($a, $b) {
    	return $a['died'] <=> $b['died'];
    });
    

    This produced my desired results. Excellent. But now I have the date in a non-human readable format!

    Fix It On output

    Thankfully making the date human readable wasn’t all that messy. Once I have my finished array, I output it and clean it up:

    <ul>
    	<?php
    	foreach ( $death_list_array as $dead ) {
    		echo '<li><a href="'.$dead['url'].'">'.$dead['name'].'</a> / '.$dead['shows'].' / '.date( 'd F', $dead['died']).' </li>';
    	}
    	?>
    </ul>
    

    Voila!

    This Year example for 2014

    An ordered list of dead characters.

  • A Case for REST API

    A Case for REST API

    WordPress 4.7.1 and 4.7 were vulnerable via the REST API. Any unauthenticated user could modify the content of any post or page on a site. Since the release of the information, a surprisingly large number of users failed to update to 4.7.2 and, thus, were hacked.

    I say surprisingly because WordPress enabled automatic updates quite a while ago (WordPress 3.7), which will automatically secure your WordPress install. There have been 18 automated releases since then (which is why we have 3.7.18) and the vast majority have addressed security in one way, shape, or form.

    But this post isn’t about the reasons why someone might need to disable the automatic updates. No, this is about the argument I saw stem from the vulnerability, whereby people said it was proof the REST API should be disabled by default.

    And to them I say “No.”

    The REST API Probably Has More Vulnerabilities

    Look, I’m not going to lie to you. The odds are high that the REST API, which is a very new feature, probably has some serious issues still. But, as my friend Helen pointed out to those arguing for it to be disabled by default.

    Why should this be treated differently from XML-RPC? Have you gone through the history of the XML-RPC setting?

    While the REST API may introduce new vulnerabilities to WordPress, and even ones that are horrifyingly accessible to non-logged in users, it is not the first nor the last feature WordPress has added that puts a site at risk. The API, being brand new and not used or tested as much as other aspects of WordPress, is going to be dangerous to exist, but realistically not more or less than any other part of WordPress.

    Go through the list of all WordPress security releases. A lot of issues have been fixed. This is just the first one for the REST API.

    In 2008, XML-RPX in pre-2.3.3 systems allowed remote attackers to edit posts of other blog users, if registration was enabled. That’s a long time ago, and since then the majority of the exploits have revolved around DDoS and pingbacks. But yes, back in the day, this new feature was also problematic.

    Do You Trust WordPress?

    Everyone makes mistakes. Every code has bugs. Everything is vulnerable. The question you have to ask is not “Why did WordPress let this happen?” nor “Why did they put me in danger?” but “Did they handle this well?”

    The heart of the matter is not if you trust WordPress not to screw up, but that you trust them to react responsibly, quickly, and with the appropriate concern. Some security issues are massive. Others are not. With over 26% of the internet using WordPress, fixing the security issues quickly and properly is a huge concern.

    So you have to ask “Do I trust WordPress to fix security issues?” And “Do I trust WordPress has my best interests, with regards to security, at heart?”

    I do, but it’s a question of risk.

    Risk = {si, λi, xi}

    My father, a risk analyst, asks three important questions:

    • What can go wrong?
    • How likely is it?
    • What are the consequences?

    Obviously a lot can go wrong. So much, in fact, that it can be impossible to wrap your head around the vastness of the possibilities and subsequent probabilities. Even just listing the things you think might go wrong is incomplete. You know you’re not thinking of everything, so you have to start with the big picture.

    Most of us aren’t capable of calculating the risk and reliability of WordPress. Those Six Sigma experts aren’t either. There’s no way I could actually explain well enough how to determine the risk of using WordPress. If I could, I’d start with asking people “What can go wrong if I disable automatic updates?” and “What can go wrong if I don’t disable automatic updates?”

    The likelihood of the REST API being vulnerable is a little higher than other aspects of WordPress core, but much lower than plugins and themes. The consequences are generally higher than that of plugins and themes, but there’s an extra factor you must consider.

    • How quickly can it be fixed?

    If you leave WordPress auto-updates on, then the answer is “As quickly as humanly possible.” And that, I feel, lowers the overall risk.

    Planned Disclosure

    To those arguing WordPress should have told everyone sooner, this is not the first time WordPress waited a while before announcing a security issue. Take, for example, The Case of the Trojan Emoji. That’s not a Sherlock Holmes mystery, that’s the true case of where WordPress hid a major security fix inside the additions of emoji support.

    There’s a big difference between the Trojan Emoji in 4.2 and the RESTless Backdoor we faced in 4.7, and that is the exploitability. The vulnerability fixed with emojis was hard to do. The one in the API was super easy. In both cases, however, the moment the vulnerability is disclosed, a ticking clock begins to see when people get hacked.

    Sometimes folks tell me I’m hyperbolic or exaggerating when I say ‘attacks will begin within minutes.’ I think that my claim was proven valid, considering how many sites were hacked, and how quickly it happened. Within days of the announcement,

    Remember, security is nuanced. It’s never as simple as “Hey, I found a vulnerability! Patch it!” It requires testing, validation, more testing, and more testing. A good patch doesn’t introduce worse problems (yes, that’s happened before).

    Rarely Used Code Is More Vulnerable

    I bring this guy up every time people argue why WordPress turns on features by default. The WordPress argument is that if they don’t turn it on, people won’t use it. The reason that matters can be found in the works of Herbert Hecht.

    Hecht wrote papers about rare conditions and their effect on software failures. The tl;dr summary for you is this: Rarely used code fails more often.

    Now, Hecht specially was referring to the early days of software use, which the REST API certainly falls under, but the basic philosophy is valid. The less the code is use, the more at risk it is, specifically because it’s used so rarely. People are less familiar with it, they don’t know how to fix it or even test it for all the possibilities, because they don’t yet know what they are.

    Are those reasons to not use the REST API? Not always. You have to consider the risk of using it for yourself. Will your site go down? How bad is that if it happens? Are you doing everything you could to protect yourself?

    Should You Disable The REST API?

    No. Unless you’re certain you’ll never use it, ever, leave it on. It will be fixed, and as long as you apply security patches promptly, you’ll be fine.

  • When a Page is an Endpoint

    When a Page is an Endpoint

    In making a site with non-standard WordPress pages, I ran into a common problem. How do I make a page that calls the data? To put it in a different way, I needed a URL (say, domain.com/stats/) to show site statistics. A ‘virtual page’ if you will.

    The Easy Way

    The first way I did this was the ‘easy’ way, though I’m loathe to really call it that. I made a page in WP Admin called ‘stats’ and I set that page to use a custom page template that, instead of calling post content, called my stats code. Custom page templates are pretty powerful, and having the page be a page meant I could allow editors to write and edit the page all they wanted.

    But the downside is that making ‘sub’ pages gets messy, and what happens if someone changes the slug or deletes the page or changes the template? No. There had to be a better way that let me force generate the page.

    The ‘Better’ Way

    This brings me to custom endpoints.

    Now there is a huge problem with this, and it’s that if you want to make your custom virtual pages look like the rest of your WordPress site, it’s … messy. This is why BuddyPress generates pages automatically for you. It needs the pages. No matter what, I was going to have to make pages. But there is a distinct difference between 19 pages and 5.

    My (unique) situation was that I wanted to have a series of sub pages. That would let me make one page, for example, for ‘roles’ and then automagically generate pages for /role/regular/ and /role/guest/ and so on. And yet, this brings up the other major problem.

    You see, it would also mean the slugs /about/regular/ could exist. Obviously there are ways around it but the point to hammer home here is that endpoints are not meant for this. They’re meant for if you want a custom endpoint (hah) on every page of a type.

    The (Really) Better Way

    Thankfully, there’s a better way!

    Rewrite rules and custom query vars will let me do everything I wanted, with only one page for each item.

    The Setup

    I have five types of pages with ‘extra’ sub pages: newest, role, star, stats, and thumbs. Each one has a few accepted types, but I don’t need to really worry about that just yet, because how I handle it differs on each page (more on that in a second). First I made a list of all my pages, the ‘kind’ of extra they had, and their custom template. Because yes, each page has a custom template.

    • page slug: newest, extra: newtype, template: newtype.php
    • page slug: role, extra: roleype, template: roletype.php
    • page slug: star, extra: starcolor, template: starcolor.php

    You’ll notice I went with a theme there. It makes it easier to remember what’s what. Each template is heavily customized for the data within, since each page is wildly different from each other. The one check I make on every page though is that the ‘extra’ value matches what I think it should. For example, here’s the stats header:

    $statstype = ( isset($wp_query->query['statistics'] ) )? $wp_query->query['statistics'] : 'main' ;
    $validstat = array('death', 'characters', 'shows', 'lists', 'main');
    
    if ( !in_array( $statstype, $validstat ) ){
    	wp_redirect( get_site_url().'/stats/' , '301' );
    	exit;
    }
    

    That means if you go to /stats/humbug/ it redirects you back to the main stats page.

    Cool, right? So the question next is how did I get /stats/characters/ to work if there’s no commensurate page?

    The WordPress Way

    The answer is add_rewrite_rule and query_vars. I made an array with all my page slugs and their extra, which you’ll remember was the same name as the template file. This let me use a series of loops and checks so my code is simpler.

    My query arguments are this:

    $query_args = array(
    	'newest'	=> 'newtype',
    	'role'		=> 'roletype',
    	'star'		=> 'starcolor',
    	'stats'		=> 'statistics',
    	'thumbs'	=> 'thumbscore',
    		);
    

    Notice how that matches exactly what my design was above? That’s why I take the time to plan all this out.

    The next thing I did with all this was to set up my query variables. These loop through the query array and set up a variable for each one.

    add_action ('query_vars', 'helf_query_vars');
    function helf_query_vars($vars){
    	foreach ( $query_args as $argument ) {
    		$vars[] = $argument;
    	}
    	return $vars;
    }
    

    What that does is makes a URL like this work: http://example.com/?pagename=stats&statistics=death

    It also means this works: http://example.com/stats/?statistics=death

    Neither of those are particularly ‘pretty’ permalinks, though, are they? That means it’s time for add_rewrite_rule!

    foreach( $query_args as $slug => $query ) {
        add_rewrite_rule(
            '^'.$slug.'/([^/]+)/?$',
            'index.php?pagename='.$slug.'&'.$query.'=$matches[1]',
            'top'
        );
    }
    

    This code is actually in an init function, but what it does is make a custom rewrite rule so we can call the URL like this: http://example.com/stats/death/

    Which is what I want.

    The Whole Code

    The following is actually the code I use. Feel free to fork! I put it into a class and did some extra work to call the right templates on the right pages.

    class LWTVG_Query_Vars {
    
    	// Constant for the query arguments we allow
    	public $query_args = array();
    
    	/**
    	 * Construct
    	 * Runs the Code
    	 *
    	 * @since 1.0
    	 */
    	function __construct() {
    		add_action( 'init', array( $this, 'init' ) );
    
    		$this->query_args = array(
    			'newest'	=> 'newtype',
    			'role'		=> 'roletype',
    			'star'		=> 'starcolor',
    			'stats'		=> 'statistics',
    			'thumbs'	=> 'thumbscore',
    		);
    	}
    
    	/**
    	 * Main Plugin setup
    	 *
    	 * Adds actions, filters, etc. to WP
    	 *
    	 * @access public
    	 * @return void
    	 * @since 1.0
    	 */
    	function init() {
    		// Plugin requires permalink usage - Only setup handling if permalinks enabled
    		if ( get_option('permalink_structure') != '' ) {
    
    			// tell WP not to override
    			add_action ('query_vars', array($this, 'query_vars'));
    
    			foreach( $this->query_args as $slug => $query ) {
    			    add_rewrite_rule(
    			        '^'.$slug.'/([^/]+)/?$',
    			        'index.php?pagename='.$slug.'&'.$query.'=$matches[1]',
    			        'top'
    			    );
    			}
    
    			// add filter for page
    			add_filter( 'page_template', array( $this, 'page_template' ) );
    
    		} else {
    			add_action( 'admin_notices', array( $this, 'admin_notice_permalinks' ) );
    		}
    	}
    
    	/**
    	 * No Permalinks Notice
    	 *
    	 * @since 1.0
    	 */
    	public function admin_notice_permalinks() {
    		echo '<div class="error"><p><strong>Custom Query Vars</strong> require you to use custom permalinks.</p></div>';
    	}
    
    	/**
    	 * Add the query variables so WordPress won't override it
    	 *
    	 * @return $vars
    	 */
    	function query_vars($vars){
    		foreach ( $this->query_args as $argument ) {
    			$vars[] = $argument;
    		}
    		return $vars;
    	}
    
    	/**
    	 * Adds a custom template to the query queue.
    	 *
    	 * @return $templates
    	 */
    	function page_template($templates = ""){
    		global $wp_query, $post;
    
    		if ( array_key_exists( $post->post_name, $this->lez_query_args ) )
    			$the_template = $this->lez_query_args[$post->post_name].'.php';
    
    		foreach ( $this->lez_query_args as $argument ) {
    			if( isset( $wp_query->query[$argument] ) ) {
    				$templates = dirname( dirname( __FILE__ ) ) . '/page-templates/' . $the_template;
    			}
    		}
    
    		return $templates;
    	}
    
    }
    
    new LWTVG_Query_Vars();
    

    PS: Yes, I totally built it all out in endpoints before I got smarter.

  • Drop DES Ciphers

    Drop DES Ciphers

    My (former) coworker read my recent post about the forward secrecy and noted the following:

    @p0pr0ck5: you really ought to get rid of the DES ciphers too.

    As it happened I was looking into that!

    What Is DES?

    DES stands for Data Encryption Standard. It’s a symmetric-key algorithm using 56-bit keys, which means it applies its magic to a block of data at once, rather than one bit at a time.

    Back in the 1970s, The National Bureau of Standards (in the US) created DES because it occurred to them that secure data was a good idea. A bunch of brains were invited to meet their proposal for a standard, and of them IBM (yes, that IBM) came up with a winner.

    What’s the Problem?

    It’s 2017, not 1971, and data is bigger and more complex. First off, 56-bit keys are too small. AES, the current standard, uses 128-bit and 256-bit keys. But perhaps more importantly, we don’t do symmetric encryption anymore. Sending the keys over the same channel you’re going to encrypt is dangerous and easy to snipe.

    Back in the late 1990s, a big machine could break a DES key in 22 hours. Today, using a cloud network on Amazon, it could be done in seconds, and be worth it.

    Oh and if you’ve heard of 3DES and are wondering if that’s better, it’s not. Remember the massive Target hack in late 2013? A bunch of credit cards were stolen and it turned out Target stored their PINs in 3DES. So no. Not safe at all.

    Why Did You Have It?

    Because Windows XP is a sack of shit and up until last year, I had to support it.

    Seriously, that was it. Now that everyone I know who use some XP (and NT) are on modern OS’s (or blocked from the server… or dead) I don’t have to worry so much.

    How Do We Ditch It?

    Remember, these are the default chiphers:

    ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
    

    In there you have the following: ECDHE-ECDSA-DES-CBC3-SHA, ECDHE-RSA-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, and DES-CBC3-SHA

    While I already have !DES in my cipher suite (as I posted a few days ago), I should remove it fully. But that also means in the Pre Main Include section, I need to change my value for SSLCipherSuite to match!

    When I tested, I noticed that I was still pulling a TLS suite with 3DES: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

    To fix that, I changed HIGH to +HIGH:+MEDIUM:-LOW and that gave me the following:

    ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:+HIGH:+MEDIUM:-LOW:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4:!DSS
    

    The -LOW is the magic sauce to say “Don’t use anonymous insecure ciphers.” when you’re on cPanel, you see.

  • On Uninstalling WordPress Plugins (and Data)

    On Uninstalling WordPress Plugins (and Data)

    Someone asked me why WordPress always says it’s going to delete files and data when it only removes the files and not the database options. There are two parts of the answer to this, one being a little historical and the other being a bit unhelpful.

    The Message: Delete Files and Data

    Once upon a time, when you uninstalled a WordPress plugin, it looked something like this:

    The Delete Plugin Screen

    That was a very simple screen. You were asked to delete the plugin files, you clicked that you were, done.

    Now you see this thanks to Shiny Updates:

    Shiny Updates - Delete Hello Dolly

    It’s a different message, telling you it’s deleting data!

    What Is The Data?

    The part you don’t see is that WordPress would also remove all the data as well as those files.

    Any time WordPress showed you that message to delete files and data, it was saying that it found a file called uninstall.php which would, presumably, delete the data set by the plugin. By this I mean the options and settings you chose for your plugin. Some plugins have data and others don’t. For example, Hello Dolly has no data, just files. It doesn’t need an uninstall file. On the other hand, a plugin like Jetpack has a lot of settings it should remove from the database on cleanup.

    Why Do We See ‘and Data’ If There’s None?

    Okay, so if Hello Dolly has no data to delete, why did we see that message? In part, this stems from the following idea:

    Delete plugin files AND data

    We wanted it to be more clear as to what was being deleted when you delete, and that was part of a proposed change to WordPress core to tell you if and when database settings are removed on uninstall, and let you leave it alone if needed. Wouldn’t that be nice? Letting you pick which way to go?

    Well. There’s a problem with that dream, and the name of the problem is “Plugin Frameworks.” No, not the CMB2 stuff, I mean the boilerplate plugin frameworks that are oh so popular.

    I hate them. Because they always have an uninstall, and most of the time people leave it alone. That’s right, your brilliant boilerplate will flag an alert that it’s deleting data when it’s not. This doesn’t impact the functionality of the base idea, but it does change the message.

    So Why Does It Say Data?

    Because when you uninstall a plugin, if it was well written, it removes the files and the data.