So I found this cool tool the other day when researching how to do Gradle multi-module (monorepo). The tool is called gdub and what it does, is it behaves more or less like git, instead of having to be in the directory with ./gradlew all you have to do is be in the directory, or a sub directory, and it will fall back to gradle on the path if ./gradlew isn’t present.

So this is a hard to accomplish exploit, and is really only accomplishable by first exploiting another exploit first, or by an employee with some level of trusted access, though this employee might not normally have actual database access. I do believe you should be aware of it, as it leaves open an avenue you may not be thinking of. A sample application So the first thing we need is an application that uses Flyway, let’s just use the Spring Boot Flyway Sample.

What’s next This is my last post that targets IronMan. So if you want to keep reading my blog, which will probably argely be a mix of security, and java with occasional dev ops, please subscribe directly. If you have suggestions for what categories I should collect things under fee free to comment. Currently the only for sure category is Security. Why not Perl? This post is 3 years in the making.

Well it’s the end of a decade of blogging with blogger for me. Though you’ve probably noticed I haven’t really been blogging for the last 2 years. I hope that’s a combination of these 2 things, but no promises. writing a tech blog with blogger is incredibly painful when I switched from Perl to Java I wasn’t an expert, and had little to contribute So I’m sure you’re wondering what I’ve switched to?

At my job we have a CIO installed policy of remediating issues found by a static analysis tool and what it finds are most targeted at finding security issues. Currently this tool is Veracode, and I don’t recommend it, it misses more problems than it finds, and what it finds, including this issue, are often false positives. Our most common issue, is CRLF (Carriage Return Line Feed) or other log injection, which we have mitigated in a custom log appender (which Veracode doesn’t recognize).

given Jeff Atwoods recent blog post and an inspiration today for me to write a “falsehoods” about versions. If you’d like to contribute yours please feel free to send me a pull request, it’d be greatly appreciated. versions always increase versions are numbers versions are strings versions are semantic versions are decimals a major number of 1 or above means stable api versions with the same major number will have the same api versions have numbers, periods, and maybe a preceding v semantic is always the best way to go versions are consistent within a project semantic versions will never see double digits or triple digits within dots at least if you’re using a semantic version people can compare it correctly versions will be consistent amongst projects in a given language or community semantic versioning cannot be represented as number or decimal as long as the versions increase the length of the version doesn’t matter if versions have the same number they are equivalent in a given archive all code will have the same version semantic versions can only have 3 positions dates are bad for versions versions always increase by exactly one

A Repository as defined in Domain Driven Design manages a single Aggregate. An aggregate may contain many entities, and value objects, but will have a single object as its root. Many of the Dao and even now some of the Repository implementations I see do not follow this, they are more likely to have a Repository per entity, than a Repository per aggregate, and of course in some cases this is required for various reasons.

I’m going to walk you through getting mvn test running in wercker, on the new docker based api. First let’s talk about what Wercker is and why you’d want to use it. Wercker a continuous integration and deployment web application. It will all you to run any language or stack. It currently is free for both private and public repositories; I am hopeful that once it comes out of beta it will maintain reasonable pricing for small personal private projects (Most CI’s are ridiculously priced for hobby projects).

As of today I have decided to remove myself as maintainer/co-maintainer of all my Perl modules. Feel free to adopt them

Or rather people should stop saying this because most of the people that say it don’t actually seem to actually know what is meant by “Premature Optimization” or how to determine when it is evil. I’ve heard people say premature optimization is evil to asking. “Is there a 3rd party library that does this more efficiently?” (knowing if there are better options is premature optimization?), “Thinking about architecting your app for horizontal scalability is premature optimization” (it is if the design is significantly more complex, but if it’s just between using REST and ensuring stateless (which is about the same complexity up front, but it’d be harder to convert later)), “wanting to do Dependency Injection is.