Today I'm excited to introduce the Sky client, making it easy to integrate with any Sky API you build. I'm also announcing Panda Sky v2.6, featuring a couple new command line features to help with testing.
Sky 2.5 introduces a new, handy feature: log tailing. You can now look at your entire deployment's log trace from the comfort of your own terminal.
Happy New Year! I'm proud to announce Sky v2.4. This version includes support for mixins - entities that extend Sky's deployment and command line features. This post will show you what kind of features are now available, as well as a preview of Sundog, a new project aiming to be a functional version of the AWS SDK.
I first encountered mixins working with Flavors Lisp, back in 1988, which introduced the term to world of programmers. The author of Flavors, Harry Cannon, was inspired by an insanely popular local ice-cream shop, Steve's. Every frozen yogurt shop now has them, as do many programming languages and libraries. Now, that's the kind of cross-discipline impact I like to see!
We are really excited by the potential of serverless architectures to provide a simpler and more reliable way to deploy modern Web and mobile apps. However, serverless is still relatively new, and, like any new technology, it can be difficult to workt with. We wanted to make it easier, so we built Panda Sky.
Of course, there are other serverless frameworks out there. Sky is focused on one thing—serverless HTTP APIs on AWS—and it's opinionated—it packages our experience and expertise in those areas. Define your API and implement your endpoints and Sky takes care of the rest, from deployment to edge-caching to custom domains to your development lifecycle.
We've been fans of Web Components since they were first announced. We had the opportunity to experiment with them, and with Polymer, in particular. But we were frankly disappointed in the results. Our team, like many developers, found React, and React-inspired frameworks easier to use. What was missing was the simplicity of React, but for Web Components. So I built it.
Assume (for the sake of argument; no need to tell us why) that one day you find yourself working with Python in Google App Engine, using PyCrypto to encrypt secrets. Unless your plaintexts are always a multiple of 16 bytes in length, you are likely to run into this error:
ValueError: Input strings must be a multiple of 16 in length
The answer is to pad out your plaintext to an appropriate length, but the version of PyCrypto available in App Engine can't do this for you.
PyCrypto is one of the libraries that Google helpfully provides for you in App Engine (though you do need to specify in your app.yaml file that you want it loaded). They do this not merely out of the kindness of their hearts, but because PyCrypto relies on a C extension, and Google does not want you compiling arbitrary C extensions on their servers. This is quite wise of them. It does mean that you are locked in to the version of PyCrypto that Google has chosen to include in App Engine, though, and that version (2.6) happens to be outdated.
A newer version of PyCrypto was released in 2013, and it includes some significant improvements, such as additional block cipher modes and helper functions for handling block padding. If you are using, say, AES with CBC, you must add correct padding to the final block of plaintext in some situations. Sadly, the newer version (2.7a1) is marked as "experimental", and the project is apparently dead. PyCrypto has been forked as PyCryptoDome, which is currently maintained, but which isn't usable in standard App Engine environments.
While it is unfortunate that Google App Engine remains locked to the older version of PyCrypto that lacks the new features, the padding helpers are written cleanly enough that they can easily be included in your project.
Earlier this year, I received a marketing email from LifeLock, which linked to a post warning of the ills of weak passwords, and inferring if 'Zuck isn't too cool to have his accounts compromised, neither are we.
Unfortunately, the folks at LifeLock don't appear to be experts in effective password strength policies. I want to address the following statement specifically:
When you develop your new passwords, think long and strong – using upper- and lower-case letters, special characters and numbers. And make sure the resulting passwords aren’t words found in the dictionary.
In the words of Dwight Schrute: WRONG. Adding complexity – by swapping character-case, and injecting numbers and symbols – does not improve the entropy (strength) of a passphrase much. Increasing the length of a passphrase is the best way to improve its entropy, and the easiest way to increase passphrase length is to add random dictionary words.
That's right, the oft-repeated "don't use dictionary words" is woefully inaccurate. In fact, the best method we have for generating high-entropy (very strong) passphrases is based entirely on using a sequence of randomly-selected dictionary words, called Diceware.
Google Fiber's big announcement last week, that they're going to “pause” the rollout of Google Fiber in new cities, in combination with the resignation of CEO Craig Barratt, led to a lot of speculation that this particular letter in the Alphabet is in trouble. Everyone from Ars Technica to The Washington Post had some fun with this story. So why not us?
We don't want to bore you, so we offer you a different take. Google Fiber isn't in trouble: in fact, it's poised to completely disrupt the ISP market. In short, Google Fiber is the Death Star from Return of the Jedi.
The following is an edited transcript of an internal Panda Strike Slack discussion, in which we assess implications of the recent IoT-based DDoS attack and conclude that we need to drink delicious beer.
Dan So the Internets are freaking out today about how people's toasters have become an attack vector. Take this Tweet as a fairly representative example:
Humor aside, isn't this a bit alarmist? After all, the problem was an attack on a specific DNS provider, not the Internet itself, and only those companies using that DNS provider were affected directly.