Matt Farina

Learn more about Docker desktop and rancher desktop.

A monorepo is a single organization-wide source code repository. Google famously uses one. If you are thinking of using one, there are things you should think about first.

A beginners look at cloud computing concepts.

If you're using Go and working with Semantic Versioning you'll sometimes need to compare versions. Here we take a look at two community packages that do this.

LastPass, the password manager that lets you manage your passwords between different devices, was recently hacked. From this there has been a fair amount of FUD circulating and not enough rational thought. With that in mind, this seems like a good time to talk about password security and LastPass with some rational ideas. Since we can't get rid of passwords just yet we need to manage them well. 1. LastPass Detected The Breach No useful system is impenetrable. Computers not connected to the Internet, that don't even have a network card, have been hacked across an air gap using their speakers and mic. The most up to date systems still suffer from zero-day exploits. Two of the elements of an organization that takes security seriously are keeping certain pieces of data separate and detecting when a breach occurs. From the LastPass announcement of the breach we can see these two things in action. While some information was obtained the actual vaults of passwords were not downloaded. And, they detected there was a problem and enough monitoring in place to distinguish what was effected. I can't overstate how nice that is to hear. Many organizations won't detect if they have been breached. Even many of those that could detect a breach wouldn't be able to tell you what was affected. That's right, many of the places you put personal information couldn't do what LastPass did. 2. LastPass Responded To The Breach Even though the password vaults were not taken LastPass is having everyone change their vault password. They detected the problem and are going the extra mile to protect their users. Now, let's consider an alternative option. Consider a 1Password or KeePass user who stores their information in Dropbox or a similar service. A malicious program on one of their systems could have taken their vault and sent it to an attacker. Those users would not have known. Or, the service could have been hacked but since it's not password specific who would have suggested changing the master password? I'm not trying to defend LastPass. It's a matter of considering the alternatives and the security measures around them. Is a 1Password or KeePass alternative setup actually more secure in practice? 3. Different Passwords For Different Sites There's a good reason to have a different password or passphrase for different sites. You can't trust that a site you submit it to will store it securely so that it won't be misused to access other sites. With all the sites we connect to we it's difficult to remember a different password for each site. Congratulations if you can do that. For the rest of us we need a system to help. This is where a password manager is useful. That is, until we can stop using passwords for something better. So, use a password manager if you can't otherwise have a different password for each site. It's more secure than using the same password everywhere. Note, I'm not recommending a particular password manager on purpose. Use a good one. 4. Security Is Not About Perfection There is no such thing as perfect security. Security needs to be practical. For example, for most people it's more security to use a password manager than to use the same password everywhere. Neither is perfect but when you weigh the differences the password manager comes out as more secure. In a distributed device world where we need passwords on more than one system it's good to go with a system that does this for you. A system that focuses on security and handling issues that come up. You could roll your own solution. But, will it be more secure? For most people the professional solution is the more secure one. When considering password security choose the one that's more secure for you rather than seeking the perfect option. 5. When Not To Use A Password Manager There are some places I would recommend not using a password manager. For example, I would recommend not using one for your financial sites. Those few places that are very important use a passphrase. 6. Encrypt Your Password Store In our multi-device world you'll likely need to share your password datastore between devices. And, any device can be hacked even if you don't need to use multiple devices. Imagine a virus on a computer looking for your password excel file and uploading that to someone bad. It happens. Use an encrypted datastore. This is why password managers are important. They are designed to store your data in an encrypted manner. This way, if someone gets your data store they will have a very hard time reading it. Before they can get to anything they'll need to break the encryption which isn't so easy. That means, even if an attacker had gotten the password vaults from LastPass, which they didn't, they would not have been able to read the data in them. 7. Limit Your Attack Vector One of the problems with LastPass is that they are a known password manager. That makes them a target if someone wants to try and get passwords. Alternatives that store their distributed information in general purpose systems pose a different attack vector. For example, if you use 1Password or KeePass and store your information in Dropbox you can still be hacked. Dropbox has been externally hacked in the past and other applications can access your Dropbox folder. Using alternatives to LastPass doesn't mean you won't be attacked. Take a few minutes and consider the attack vectors of the different solutions you're considering and how each of those will detect a breach and respond to that. For example, I could self host my encrypted file on the Internet somewhere. This would be managed by me and wouldn't be a known system for someone to target. But, the IPv4 addresses are regularly checked for known vulnerabilities so attackers and get onto a system a poke around. That is the entire IPv4 space, which is still the only space routable for all things, is regular checked. Will I keep everything on that system up to date? Will I detect if someone broke into the system? Will I respond appropriately? All of this needs to be taken into account. Final Thoughts On LastPass I'm not trying to defend LastPass. I'm trying to give a little more of a holistic picture of security. It's complicated and any alternatives to a LastPass or LastPass-like solutions need to have their security considered. Viewing the options with security and attacks in mind keeps everything in perspective.

Recently, I had to take some content in markdown, specifically markdown extra, and convert it to a series of PDFs styled with a specific branding. While some will argue that PDFs are dead and “long live the web”, many of us still need to produce PDFs for one reason or another. In this case I had to take markdown extra, with some html sprinkled in, clean it up, and convert it to a styled PDF. What follows is how I did that using QueryPath for the cleanup and DOMPDF to make the conversion. The Setup At the root of this little app was a PHP script with the dependencies managed through composer. The composer.json file looked like: { "name": "foo/bar", "description": "Convert markdown to PDF.", "type": "application", "require": { "php": ">=5.3.0", "michelf/php-markdown": "1.4.*", "dompdf/dompdf" : "0.6.*", "querypath/querypath": "3.*", "masterminds/html5": "1.*" } } Turning the Markdown into HTML Within the script I started with a file we’ll call $file. Form here it was easy using the official markdown extra conversion utility. $markdown = file_get_contents($file); $markdownParser = new \Michelf\MarkdownExtra(); $html = $markdownParser->transform($markdown); This produces the html needed to go inside the body of an html page. From here I wrapped it in a document because I could easily link to a CSS file for styling purposes. DOMPDF supports quite a bit of CSS 2.1. $html = ' ' . $html . ' ’; pdf.css is where you can style the PDF. If you know how to style web pages using CSS you can manage to style a PDF document. Cleaning Up The Content There were a number of places html had been injected into the markdown that was either broken, unwanted in a PDF, or an edge case that DOMPDF didn’t support. To make these changes I used QueryPath. For example, I needed to take relative links, normally used in generation of a website, and add a domain name to them: $dom = \HTML5::loadHTML($html); $links = htmlqp($dom, 'a'); foreach ($links as $link) { $href = $link->attr('href'); if (substr($href, 0, 1) == '/' && substr($href, 1, 1) != '/') { $link->attr('href', $domain_name . $href); } } $html = \HTML5::saveHTML($dom); Note, I used the HTML5 parser and writer rather than the built-in one designed for xhtml and HTML 4. This is because DOMPDF attempts to work with HTML5 and I wanted to keep that consistent from the beginning. Converting to PDF There is a little setup before using DOMPDF. It has a built in autoloader which should be disabled and needs a config file. In my case I used the default config file and handled this with: define('DOMPDF_ENABLE_AUTOLOAD', false); require_once __DIR__ . '/vendor/dompdf/dompdf/dompdf_config.inc.php'; The conversion was fairly straight forward. I used a snippet like: $dompdf = new DOMPDF(); $dompdf->load_html($html); $dompdf->render(); $output = $dompdf->output(); file_put_contents(‘path/to/file.pdf', $output); DOMPDF has a lot of options and some quirks. It wasn’t exactly designed for composer. For example, if you want to work with custom fonts you need to get the project from git and install submodules. Despite the quirks, needing to cleanup some of the html, and brand the documents, I was able to write a conversion script that handled dozens of documents quickly. Almost all of my time was on html cleanup and css styling.