Song to Song

/ Neil Wilson

Terrence Malick used to make good movies. Badlands is terrific. Days of Heaven, The Thin Red Line, and The New World are all good. The Tree of Life is overindulgent and almost plotless, but at least it’s nice to look at. Then To the Wonder came out and it sucked because it was neither interesting nor pretty. Song to Song doubles down on that approach, so it’s nearly unbearable.

There’s not much in the way of a plot. Cook (played by Michael Fassbender) is a rich music producer and one of the biggest assholes you can imagine. He’s obsessed with showing off, having women, being miserable, and making others miserable. He’s the kind of guy who buys a Ferrari and parks it across multiple spots in a way that makes you want to key it, slash the tires, smash it with a sledgehammer, and set it on fire with him inside. He’s signed BV (Ryan Gosling) to a songwriting contract in which they’re supposedly equal partners, but Cook gets all the credit and is the only one named in the copyrights. Faye (Rooney Mara) used to be one of Cook’s receptionists before she became a musician, and he wants her because he knows that she and BV are into each other. He pressures Rhonda (Natalie Portman) to be his wife by buying her with a house for her soon-to-be-evicted mother (Holly Hunter). And he continues to hire prostitutes and sleep with women attracted to his lifestyle.

No one in this movie says anything above the volume of a whisper, and no one has even the slightest shred of enthusiasm. With the dull plot full of unbearable characters, you’d at least hope that it’d be pretty, but that’s not the case at all. It looks like it was shot almost entirely with fisheye lenses, often times with lenses that look like they fisheye vertically rather than horizontally so that everything looks shorter than it is. At least once, they switch back and forth from different levels of fisheyeness for an even greater level of absurdity. And I’d be willing to overlook some of that if the shots had at least been interesting, but that’s not the case. So many of the characters look so similar, and the shots are so distorted, that it’s often difficult to tell who you’re looking at. There’s so much swooping back and forth and twirling of the camera that you might feel a little dizzy or nauseated. The beautiful things you’re supposed to be looking at are mostly just repugnant, garish displays of excess whose primary purpose is to make it clear that they cost a lot of money. I will say that it used a good depth of focus in most scenes so you can at least scour the background for something interesting when you don’t care about what’s going on in the foreground, but that too is mostly a fruitless endeavor.

The film is shot in and around Austin, but it’s so focused on clichéd locations (the skyline, various downtown locations, SxSW, the Hill Country, Mount Bonnell, etc.) that it’s surprising there’s no “waiting in line at Franklin’s Barbecue” scene, but maybe not even Terrence Malick has that much patience. It took so long to complete the film that there are shots of things that aren’t there anymore (like the shopping center with the old Alamo Drafthouse South Lamar and Highball, which were demolished in 2012). And the film progresses at such an agonizingly slow pace, that’d have almost sworn that my watch kept stopping. It’s the kind of pretentious, meaningless garbage that you might expect of an overly ambitious film student, and I can’t imagine ever again willingly subjecting myself to another Malick film.

Wilson

/ Neil Wilson

Woody Harrelson’s career has been all over the map, but I found his recent performance in The Edge of Seventeen to be one of the highlights of a film that’s got a lot of things going for it. It seems like he’s trying to capture some of that same vibe in Wilson, but this time it doesn’t go so well.

Harrelson plays the eponymous Wilson, a man who hates technology and modern life, and who hates people who want to be left alone. He’s the kind of guy who’ll sit right next to you in an otherwise empty train car and strike up a conversation when you’re trying to work or sleep or listen to music. We know this because he does it repeatedly in the movie. As a result, people hate him, and his quest to interact with people leaves him without any friends.

One day, he decides to try to track down his ex-wife (Laura Dern), who left him when she was pregnant, and whom he hasn’t seen in many years. He thought she’d had an abortion, but is surprised to learn that she had the baby and gave it up for adoption. He gets what little information she has about their daughter and uses that to track her down and try to get to know her.

This is a well-made film. It looks and sounds good, and the acting is fine. It’s exactly the movie they wanted to make. But that doesn’t mean that it’s a movie that I want to watch. Wilson is such an aggressively unpleasant man that that’s what the movie becomes. It does try to become funny and genuine and sweet, but it’s too little too late, and it never abandons its abrasiveness. Whenever there’s a nice moment, it always seems to find some way to sabotage itself and remind you that there’s not much about it to like.

Then there’s the problem of the whiplash-inducing changes in his character and how he’s perceived by others, without any kind of attempt at explaining why. And as it nears the end, it feels like it’s just kind of aimlessly wandering with no sense of direction, which makes this relatively short 96-minute film feel a lot longer than it actually is. Those faults probably lie at the feet of screenwriter Daniel Clowes (who also wrote the graphic novel on which it’s based, and had previously done Ghost World and Art School Confidential), but it’s entirely possible that those subtleties were in the script but got lost in the direction or editing. It’s probably a combination of all of those things, but it seems like it could’ve turned out much better than it did.

Life

/ Neil Wilson

Alien was a tremendous sci-fi horror film when it was released in 1979, and that’s still true today. It’s obvious that the people behind Life share this sentiment because the two movies share quite a bit more than a passing resemblance. And while the latter isn’t on the same level as the former, the result is still worth a look.

The International Space Station is full of scientists (including characters played by Jake Gyllenhaal, Rebecca Ferguson, Ryan Reynolds, Hiroyuki Sanada, Ariyon Bakare, and Olga Dihovichnaya) who are eagerly awaiting a delivery from Mars. An unmanned craft is bringing them some soil samples that they believe might have signs of past life. After a harrowing retrieval process, they find a single-celled organism in a dormant state. But when they give it an atmosphere and some nutrients, it comes out of dormancy. And then it starts growing into a complex, unique, curious, and intelligent creature. They’ve taken precautions to keep it contained, but they’re not good enough. Soon, it’s loose on the space station and killing off the scientists in its need to feed.

The film’s connections to Alien are readily apparent, but it’s also got a lot in common with Carpenter’s The Thing in its quest to survive and grow at all costs, and in its ability to adapt to its environment. It does feel like it suffers from a lack of creativity at times, sometimes to the point of feeling clichéd (especially in a highly unoriginal “moment of realization” scene that you can see coming from a mile away). And I really wish they had gone a different route with the end because it’s not nearly as clever as they think it is and there are a few other alternatives that I would have rather explored. But it’s got a good runtime (103 minutes) that doesn’t feel too compressed or too drawn out, some good effects, and the cast works well together. Even when you’ve got a pretty good idea about what’s going to happen, it manages to be a pretty fun movie.

Understanding and Defending Against LDAP Injection Attacks

/ Neil Wilson

Injection attacks are one of the most common sources of security holes because it’s so easy for an unsuspecting developer to leave the door open for them. But it’s also usually very easy to prevent them through some pretty simple means.

An injection attack happens when an application uses externally-obtained data in the course of its processing, but without making sure that data is acceptable and safe. It’s especially predominant in cases where an application plugs user input into some kind of a query or command that it sends to some kind of data repository, and doesn’t protect against the possibility that unexpected or malicious user input could cause the application to issue a different request than the one it expected. You’re probably most likely to hear about injection attacks when dealing with SQL (the structured query language, commonly used to interact with relational databases), but it can also affect interaction with other data repositories, like NoSQL databases and even LDAP directory servers.

LDAP directory servers actually have an inherent advantage over many other types of data stores when it comes to injection attacks because LDAP isn’t a text-based protocol and because LDAP APIs typically don’t make it possible to accidentally turn one type of operation into a different kind of operation. SQL injections are particularly dangerous because it’s possible for an SQL statement intended to just read some data from the database to be inadvertently converted into one that destroys, corrupts, or otherwise wreaks havoc on the data. This can’t happen in an LDAP injection, but there are still some very real threats that you need to protect against.

LDAP Filter Injections

By far, the most common type of LDAP injection attack is a filter injection. This can happen whenever you construct an LDAP search filter from its string representation and include user-provided data in the process.

For example, consider an application that offers an input field that makes it possible to look up a user by their username or their email address. Such an application might have the following code:

String filter = "(|(uid=" + userInput + ")(mail=" + userInput + "))";

If the user input is “jdoe”, then this will end up creating the filter “(|(uid=jdoe)(mail=jdoe))”. That seems safe enough, right? But instead, let’s consider what would happen if the user were to enter an asterisk instead of jdoe. That would cause the resulting filter to be “(|(uid=*)(mail=*))”, and that would match any entry within the scope of the search that has either at least one of the uid and mail attributes. And what if the user were to enter jdoe)(objectClass=*”? In that case, the code would create a filter of “(|(uid=jdoe)(objectClass=*)(mail=jdoe)(objectClass=*))”, and that filter would match any entry within the scope of the search, including those that don’t have either the uid attribute or the mail attribute.

The Risks of Filter Injection Attacks

As illustrated above, one of the key risks of a filter injection attack is that it could cause the application to expose more entries, or different kinds of entries, than the application intended to make available. But there are other dangers as well.

Leaking Sensitive Attribute Values

One risk that people don’t often think about is the possibility of using a filter injection attack to leak the values of attributes that contain sensitive information. For example, let’s say that we know that the directory server stores a user’s social security number in the ssn attribute in the user’s entry and that we want to find out what the social security number is for user jdoe. Let’s also assume that there aren’t any users in the directory that have a uid or mail value of noMatches. If the application constructs a search filter using the code listed above, then we might try entering the following into the input field:

noMatches)(&(uid=jdoe)(ssn=1*)

This would result in the application generating the following filter:

(|(uid=noMatches)(&(uid=jdoe)(ssn=1*))(mail=noMatches)(&(uid=jdoe)(ssn=1*)))

This filter would match the entry for user jdoe only if that entry has an ssn value whose first digit is one. If that filter doesn’t match, then we could replace the one with a two, then a three, and so on until we get a match, and then we know what the first digit of the social security number is. Then we can use the same technique to find the second digit, then the third, etc. until we know all nine digits.

Denial of Service Attacks

Filter injection attacks also open the door for very simple and very effective denial of service (DoS) attacks, whether against the application that interacts with the directory server, or against the directory server itself. An injection attack could turn what is expected to be a very efficient filter into one that is very time-consuming to process and takes up a lot of server resources. If you’re able to get enough of those going at the same time, it may eat up all of the available processing cycles in either the application or the directory server so that other requests can’t get through.

Further, if the application is designed to hold all of the entries returned from a search in memory at the same time, a search that returns a lot more entries than expected could cause the application to consume all available memory on the system, which could potentially make the application crash or spend all of its time in garbage collection, or could make the system start paging memory out to disk.

Invoking Operations Against Unintended Entries

We’ve already established that a filter injection attack has the potential to cause a search to match entries that the application didn’t expect to match. If the application makes those entries available to the end user in some way, then the application could be tricked into leaking information to the end user. But what if the application doesn’t simply make those entries available to the end user, but instead does something else with them? What if the application applies some update to each entry that matches the search filter? If you can trick the application into searching for the wrong entries, then that could lead to the application updating the wrong entries, which could cause data loss or corruption.

Defending Against Filter Injection Attacks

There are several ways that you can protect your LDAP-enabled application against filter injection attacks. Some of them are probably very easy to implement. Others may take additional effort. And you might want to implement more than one of these safeguards to take a kind of “belt and suspenders” approach.

Don’t Construct Filters by Concatenating Strings

You should never, never, never, never construct an LDAP search filter by concatenating strings, especially when that string contains any user input. Instead, you should leverage the features that your LDAP library offers to create filters programmatically.

For example, if you’re using the UnboundID LDAP SDK for Java, rather than:

String filter = "(|(uid=" + userInput + ")(mail=" + userInput + "))";

You should instead use:

Filter filter = Filter.createORFilter(
     Filter.createEqualityFilter("uid", userInput),
     Filter.createEqualityFilter("mail", userInput));

Much like using an SQL prepared statement, constructing an LDAP filter programmatically ensures that it isn’t possible for crafty input to result in a different kind of filter than the one that was intended.

If you’re using an LDAP library that doesn’t provide a way to programmatically generate search filters, then you should strongly consider selecting a new library to use for LDAP communication. If that’s not feasible, and you have to create filters from their string representations, then you absolutely must sanitize any user input included in the generated filter.

Sanitize User Input Included in Search Filters

There are two basic ways to sanitize user input.

The first is to reject any input that doesn’t appear to be valid. For example, if you have an input field in which you expect the user to provide a username or an email address, then you might only want to allow the input to contain letters, digits, periods, dashes, underscores, plus signs, and the at sign.

And if it’s a client-server application, then you should make sure to do the validation in server-side code rather than (or perhaps in addition to) client-side code. For example, if you have a web application, and it uses JavaScript to ensure that the input only contains valid characters, then an attacker might be able to get around that by disabling JavaScript support in their browser, or by not using a browser at all but some other kind of HTTP client that allows them to send exactly the request they want to send. If you have server-side validation, the attacker won’t be able to get around that with any amount of fancy client-side trickery. You can still use client-side validation if you want, since that can make for a better experience for legitimate end users, but just make sure to do the same validation in the server for actual security.

The second way to sanitize user input is by escaping any special characters that it may contain. RFC 4515 states that the following escaping must be applied to the assertion value in the string representation of an LDAP search filter:

  • The null character (U+0000) must be escaped as \00
  • The left parenthesis must be escaped as \28
  • The right parenthesis must be escaped as \29
  • The asterisk must be escaped as \2a
  • The backslash must be escaped as \5c

You can escape any other character by placing a backslash in front of the hexadecimal representation for each byte in the UTF-8 encoding for that character, but the above characters are the ones that absolutely have to be escaped.

The LDAP library you’re using may provide a mechanism to do this for you (for example, if you’re using the UnboundID LDAP SDK for Java, then you can use one of the the Filter.encodeValue(String) or Filter.encodeValue(byte[]) methods), but if it has that, then it’s probably got methods to help you programmatically construct the filter, and using that approach is definitely better than trying to perform your own escaping.

Use an AND Filter To Impose Restrictions on Matching Entries

To prevent a search from matching entries of a different type than you expect, you can wrap the filter inside of an AND that will only match the desired type of entry. For example, if you know that you only want to search for user entries, and you know that all user entries have the person object class, then rather than using a filter like:

(|(uid={input})(mail={input}))

You could instead use a filter like:

(&(objectClass=person)(|(uid={input})(mail={input})))

This will ensure that only user entries will be returned. If you have more specific criteria, then you can include that in the filter as well. Just note that this type of protection on its own isn’t enough to prevent all kinds of injection attacks since it doesn’t protect against wildcards or new components injected inside the OR. So you’ll still need to make use of one of the other types of protection listed above.

Restrict the Search Request in Other Ways

The search filter is just one of the elements of an LDAP search request. There are other elements that you may be able to adjust to reduce the effect of processing a search that isn’t exactly what you expected. Some of those are:

  • Set the base DN and scope to be as specific as possible to the type of search that you’re performing. For example, if you know that you’re searching for a user, and you know that all users are in a particular branch in the directory (for example, beneath “ou=People,dc=example,dc=com”), then base your search at that branch rather than at the root of the tree, so that the search won’t match any entries outside of that branch.
  • Use the size limit to prevent the server from returning more entries than expected. If you’re searching for a single user entry, then use a size limit of one, and the server will return an error result if it finds more than one matching entry.
  • Use the time limit to prevent the server from spending too much time processing the search. If you expect your search to be efficient, then setting the time limit to a second or two should be more than enough time to allow the server to process it under normal circumstances, but small enough to ensure that an unexpectedly inefficient search gets cut off before too long.

Leverage the Server’s Access Control Mechanism

Another great type of protection against attacks of all kinds is to ensure that requests are issued under an account that only has permission to do what it’s supposed to do. For example, if you only want the application to be able to search for entries by targeting the uid and mail attributes, then only give the application’s account permission to issues searches targeting those attributes. Similarly, give the application read access only to the attributes that it legitimately needs to get back in search result entries, and give it write access only to the attributes that it legitimately needs to be able to update.

If an application needs to process operations on behalf of another user, then you may want to use the proxied authorization request control (described in RFC 4370) to ensure that those operations are processed in accordance with that user’s access control rights.

LDAP DN Injections

Although filter injection attacks are by far the most prevalent, it is conceivably possible for an LDAP injection attack to target entry DNs. In particular, if an application constructs an LDAP DN from user input, then it may be possible for a malicious user to provide unexpected input that could end up targeting a different entry than was expected.

For example, let’s say that an application has the following code:

String userDN = "uid=" + userInput + ",ou=People,dc=example,dc=com";

If the user enters “jdoe”, then this would construct the following DN:

uid=jdoe,ou=People,dc=example,dc=com

But if the user enters “jdoe,ou=Secret Users”, then this would construct a DN that is one level below what the application intended:

uid=jdoe,ou=Secret Users,ou=People,dc=example,dc=com

While theoretically possible, DN injections aren’t all that common or practical. There are two key reasons for this.

First, it’s rare for applications to construct DNs based on user input. Or, at least, it’s rare for well-designed applications to construct DNs based on user input. It’s a very bad thing for an application to assume that DNs have a particular structure or pattern because not all of them do. And even if DNs have a known format when the application is being developed, it’s entirely possible that the format could change later (for example, to eliminate all personally-identifiable information from DNs), and the application would be broken. It’s far better for an application to search for an entry and learn its DN that way than to try to construct it.

Second, the only kind of injection that you can realistically achieve when constructing a DN is to target an entry deeper in the tree than you had initially expected. You can’t use an injection attack to target any arbitrary entry in the DIT. Fortunately, LDAP DNs don’t have any equivalent to the “..” in a filesystem path that allows you traverse up to its parent.

Nevertheless, if you do encounter a scenario in which you need to construct a DN from user input (for example, if you’re adding a new entry), then you should see if the LDAP library you’re using provides a way to safely construct the DN for you. For example, if you’re using the UnboundID LDAP SDK for Java, instead of using the code:

String userDN = "uid=" + userInput + ",ou=People,dc=example,dc=com";

You should use:

DN userDN = new DN(new RDN("uid", userInput), new RDN("ou", "People"),
     new RDN("dc", "example"), new RDN("dc", "com"));

This will ensure that all appropriate escaping is done, and will thwart any injection attempt.

If your LDAP library doesn’t have any kind of method like the above for constructing DNs safely, then you should either get a new LDAP library that does provide this support, or you should perform the escaping yourself. The rules for escaping special characters in DNs are a little different from the rules for escaping special characters in a search filter. All the necessary details for constructing the string representation of a DN is provided in RFC 4514, but the basics are:

  • You should escape the double quote character as \" or \22
  • You should escape the plus sign character as \+ or \2b
  • You should escape the comma character as \, or \2c
  • You should escape the semicolon character as \; or \3b
  • You should escape the less-than character as either \< or \3c
  • You should escape the greater-than character as either \> or \3e
  • You should escape the backslash character as either \\ or \5c
  • If a value has any leading or trailing spaces, then you should escape those spaces by prefixing them with a backslash or as \20. Spaces in the middle of a value don’t need to be escaped.
  • If the value starts with an octothorpe character (#), then you should escape it as either \# or \23. You only need to escape the octothorpe character at the beginning of a value, and not in the middle or at the end of the value.

Raw

/ Neil Wilson

Expectations and buzz are usually a bad thing. If a movie is hyped too much, I’m often disappointed when I finally get the chance to watch it. Raw has been hyped a lot, including stories of people fainting and vomiting during early festival screenings, which usually is little more than a marketing gimmick. Fortunately, this is one that mostly lives up to the hype.

Justine (played by Garance Marillier) is a strict vegetarian who’s about to enter veterinary school. Her parents are vegetarian veterinarians, and her sister Alexia (Ella Rumpf) is a vegetarian veterinary student, so she’s just following in her family’s footsteps. She’s got a reputation for being a brilliant student, and all of the faculty have very high expectations for her.

But when she arrives, she’s definitely not going to get any special treatment from her peers. This is, apparently, a school in which all new students are subjected to intense hazing. Their rooms are invaded in the middle of the night, their possessions are thrown out the window, they’re herded together in their night clothes, and that’s just the first few minutes. And then, as is inevitable for just about any kind of hazing, comes the eating of the disgusting things. Her insistence in her vegetarianism and her objections on completely normal grounds carry no weight, and she’s forced to eat raw rabbit kidneys. The next day, she starts to break out into a rash, and then she starts getting weird cravings.

Raw is a movie that really wants to gross you out. It’s got a lot of scenes whose primary purpose is shock value, and they’re effective even when you have some suspicions about what might be coming. But unlike most of these kinds of movies, it doesn’t sacrifice the story or the characters to do it. There’s at least a somewhat-plausible explanation for everything, and there’s a lot of discomfort that comes from things outside of the film’s main plot line. It may be that its female director, Julia Ducournau, is able to approach the matter from a different perspective than her male counterparts, and some of the most powerful scenes deal with Justine being forced to deal with her femininity in a way that she hasn’t before.

I do think that the movie gets a little too artsy and vague at times, particularly toward the end. Its 99-minute runtime doesn’t feel too padded out, but it could perhaps be a little tighter. It’s definitely not for everyone, and since it caters more toward serious movie fans than general audiences, it probably would’ve been even more fun to experience with the energy of a festival crowd. But if you can stomach this kind of film, it’s just about as much fun as a movie this icky can be.

The Belko Experiment

/ Neil Wilson

I often enjoy movies in the style of Battle Royale (like The Running Man, Death Race 2000, Turkey Shoot, Hard Target, and Series 7: The Contenders). I often enjoy movies written by James Gunn (including Dawn of the Dead, Slither, Super, and Guardians of the Galaxy). I enjoyed Wolf Creek, the only Greg McLean-directed film I’d seen. The Belko Experiment combines all three of these things but leaves out the enjoyability.

Belko is a company of some sort with an office building in Bogotá, Colombia. It’s a rough neighborhood, so the building is fortified, the grounds are patrolled by armed guards, and all the employees have had GPS trackers surgically implanted so they can be located if they get kidnapped. But these things purportedly there for worker safety are used against them when the building is sealed off by unknown villains and order its occupants to start killing each other. Failure to comply will result in even greater numbers of casualties via the small bombs they’re carrying around under the guise of GPS trackers.

This movie is just awful. There isn’t nearly as much action as you’d expect, and a lot of that action is surprisingly dull. Most of the deaths are from people getting shot or having their heads blown up by the GPS bombs. Even the few exceptions to this (including one of the key kills, which is spoiled by the movie’s poster) aren’t as brutal or as exciting as they should have been. There’s a lot of arguing, but even the arguments aren’t convincing or entertaining. The characters (played by actors I usually like watching, including John C. McGinley, Michael Rooker, Gregg Henry, Melonie Diaz, and Abraham Benrubi) are mostly pretty terrible people, and it’s impossible to believe they would all be as stupid as they are portrayed. I mean, why in the world would they all agree to have tracking devices surgically implanted into their heads?

The poster bills the movie as “Office Space meets Battle Royale”, but that’s only partially accurate because it has virtually nothing in common with Office Space, and it’s missing just about all of the things that make Battle Royale a great film. Clearly, the filmmakers also have a fondness for The Cabin in the Woods, since major elements are obviously lifted from it, but again, taking content doesn’t equal taking what made that content great. In this case, you’re much better off watching the films that inspired it, and the earlier, better works of the people involved.

Beauty and the Beast (2017)

/ Neil Wilson

I don’t like South by Southwest, for a variety of reasons that I don’t want to get into. But one of them is that when it comes to town, options for watching movies that aren’t part of the fest are severely limited. It’s rare that I go a day without watching at least one a movie in a theater, but it had been six long days since I’d seen anything on the big screen. I was probably primed to like just about anything they put in front of me, which means that Beauty and the Beast must be especially bad for me to have disliked it that much.

The basic story is probably very familiar. When a prince (played by Dan Stevens) scorns a witch (Hattie Morahan), she casts a spell that turns him into a beast and some of his attendance into furniture and other assorted housewares. She also gives him a magical rose, and that spell will only be broken if he can get someone to fall in love with him before all its petals drop off. And if his appearance isn’t enough of a deterrent, his castle is enshrouded in a permanent winter and hidden in a forest patrolled by wolves, so people aren’t exactly dropping by all the time.

But then someone does. Maurice (Kevin Kline) is on some unspecified annual journey when a storm forces him off his usual path and onto the beast’s estate. When he dares to pick a flower to give to his daughter Belle (Emma Watson), the beast takes him hostage and intends to hold him forever. But when Belle comes looking for Maurice, she finds him in the beast’s castle, and she takes her father’s place as his prisoner. And then the town hunk Gaston (Luke Evans), who’s smitten with her, sets off to rescue her.

Beauty and the Beast has a lot of potential. Emma Watson is a great Belle, both in appearance and in voice. Gaston’s sidekick LeFou (the gay character, played by Josh Gad, that seems to have some people in a huff) adds a lot of comic relief. Many of the set pieces are elaborate and ornate. But a film that should be gorgeous to look at is irreparably marred by horrendous cinematography. The movie is full of shallow focus that was so annoying in 2D that it must be utterly unbearable if you choose to subject yourself to the 3D version, and its abuse of pull focus could almost be classified as a crime against humanity. Most of the time, you can really only see one thing on the screen while everything else is blurry, but there are a number of occasions (especially scenes that were obviously made to have some kind of 3D effect) in which everything is out of focus. But even with all the cinematography problems, there are far too many occasions in which you can see the beast’s face clearly, and that’s unfortunate because the CGI employed for that purpose is nothing short of embarrassing.

The film’s biggest other problems are encapsulated in the real villain, Gaston. It’s such a one-dimensional, cartoonish character (far more so than anything in the animated version of the movie) that just about every second of him you have to endure is excruciating. And just in case you were hoping for some kind of relief when he participates in a musical number, the atrocious auto-tune employed for that purpose gives it that extra boost beyond any hope of salvageability.

If you want to see a good Beauty and the Beast film, you could certainly fall back to the animated film from 1991. It’s the same basic story and set of songs, but you can see everything clearly and everything sounds good, and it’s a full 45 minutes shorter than the new version. But as good as the animated version is, you might just get depressed when you realize that you’re getting old because that movie came out over 25 years ago. So instead I’ll recommend the definitive live-action version, the 1946 French film La belle et la bête, written and directed by Jean Cocteau.

LDAP Result Code and OID Reference Guides

/ Neil Wilson

I’ve added a couple of LDAP reference documents.

The LDAP Result Code Reference provides a fairly complete overview of many LDAP result codes, including the core LDAPv3 result codes defined in RFC 4511, server-side result codes from other specifications, and client-side result codes. It describes each of the result codes and some of the cases in which they may be used.

The LDAP OID Reference lists a number of object identifiers used throughout LDAP for things like schema elements, controls, and extended operations. It lists the OIDs, provides a brief explanation of its purpose, and, when applicable, provides a link to the relevant specification.

Both of these will also be included in the documentation for the next release of the UnboundID LDAP SDK for Java (and they’re already checked into the GitHub repository), but for now, you can find them on my website.

Kong: Skull Island

/ Neil Wilson

Co-writer Max Borenstein also co-wrote the 2014 Godzilla remake, and (according to IMDb) is slated to be involved with the 2019 movie Godzilla: King of Monsters and the 2020 film Godzilla vs Kong. That makes sense because Kong: Skull Island feels much more like a Godzilla movie than one written for King Kong.

Bill Randa (played by John Goodman) is an explorer with a crackpot theory that the earth is hollow and inhabited by gigantic creatures. But so far, every attempt to find them has been futile, so he’s on the thinnest of ice with Senator Willis (Richard Jenkins). Nevertheless, Randa convinces Willis to give him a military escort to check out a newly-discovered Pacific island (out of fear that the Russians might get there first). The United States is pulling out of Vietnam, but Preston Packard (Samuel L. Jackson) volunteers his squad for one last mission, and Randa hires British soldier James Conrad (Tom Hiddleston) to serve as a tracker. And when talented anti-war photographer Mason Weaver (Brie Larson) learns of the mission, she’s intent to come as well.

Everyone except Randa thinks that the mission is just to map the new island (which is constantly enshrouded with storms) and study its geography. But when their squadron of military helicopters arrive and start dropping seismic charges (purportedly to help study the island’s geological makeup), a gigantic ape appears and starts swatting them out of the sky. Soon, they’re all down and scattered across the island. While Packard and his soldiers are intent on killing the monster, Conrad and Weaver run into Hank Marlow (John C. Reilly), a man who’s been stranded on the island since his plane went down in World War II, and he tells them that the ape, named Kong, is really a good guy who keeps the really bad creatures at bay.

All the film’s monster-on-monster and monster-as-defender themes really make it feel like the movie was written for Godzilla rather than King Kong. It also evokes thoughts of Jurassic Park (at one point, Samuel L. Jackson even proclaims, “Hold onto your butts!”, albeit without a cigarette dangling from his lips) and occasionally Congo. And I recently watched Josef von Sternberg’s Anatahan (a rather disappointing, slowly-paced film that deals with sailors stranded on an island, who encounter a couple that’s been living there for years), so that came to mind, too. But you know what it doesn’t remind me of at all? A King Kong movie.

Kong: Skull Island is a very, very dumb movie. I mean, I can go along with the premise that there are giant monsters lurking beneath the earth’s surface, and that the only thing keeping them from taking over the earth is a giant ape who lives on the secret island that serves as the passage between the two worlds. But it’s tougher to accept that combat helicopter pilots would let themselves get within arm’s reach of a giant ape who’s trying to swat them down. And that’s just the start. I’m not saying that it’s not entertaining at times, but boy is it dumb.

A Couple of Updates to the LDAP SDK Open Source Repository

/ Neil Wilson

Within the last weeks, there have been a couple of noteworthy changes to the open source repositories for the UnboundID LDAP SDK for Java.

Migrated the GitHub Repository to Ping Identity

The primary open source repository for the LDAP SDK is on GitHub. It used to be part of the UnboundID organization, but over the weekend, I migrated it to the Ping Identity organization (since Ping Identity acquired UnboundID last year). The new URL for the LDAP SDK project on GitHub is https://github.com/pingidentity/ldapsdk.

This should be a completely transparent migration. All of the content (revision history, releases, issues, forks, etc.) should have been preserved. The URLs used to access the repository have changed, but GitHub should redirect all of the old URLs to the new ones, so if you have any links or bookmarks that use the old URLs, you should still end up in the right place. This is also true for any clones of the repository, but if you have checked out the LDAP SDK, then you might want to update your local workspace to the new path. You can do that with the command:

git remote set-url origin git@github.com:pingidentity/ldapsdk.git

If you notice any problems with the repository as a result of the migration (or for any other reason), please open an issue, and we’ll look into it.

And for the record, we also migrated the other public UnboundID repositories to Ping Identity. That includes account-manager, auth-explorer, auth-ui, broker-groovy-sign-in-sample, broker-react-sign-in-sample, my-account, scim, scim2, server-sdk-maven, and status-servlet.

Published the LDAP SDK Unit Tests

When we originally made the LDAP SDK open source, we published everything that you need to build the LDAP SDK, but there was some content from our internal repository that wasn’t made public. The biggest omission from the open source repository was the set of unit tests.

The main reason for omitting the unit tests was that, at the time, most of them required the UnboundID Directory Server (now Ping Identity Directory Server), and that wasn’t publicly available. It was possible to run the tests without a Directory Server instance, but there would be large portions of the code that wouldn’t get covered. But then we updated the LDAP SDK to include the in-memory directory server, and we started using it for most unit tests created after that, so now you can get really good test coverage without an external Directory Server instance.

There are still some tests that will only get run if you have an external Directory Server instance, and if you want to run them, you can download the 6.0.1 release of the Ping Identity Directory Server from https://www.pingidentity.com/en/products/downloads/pingdirectory.html. You’ll need to create an account if you don’t already have one, but that’ll get you access to a free, fully-functional evaluation copy of the Directory Server. The license doesn’t allow you to use the Directory Server for any commercial purpose, but it’s certainly suitable for use in running the unit tests if you so choose.

And with this update, the GitHub repository for the LDAP SDK is now a complete mirror of the internal subversion repository, and we expect to always keep them in sync. At some point, we may make the GitHub the master repository for the LDAP SDK, but at present, there are some internal build processes that rely on our private repository (and rely on subversion rather than git).