by Bozho | Apr 5, 2016 | Aggregated, Developer tips
As I’ve been researching the machine readable travel documents, I decided to do a little proof-of-concept on reading ePassports using an NFC-enabled smartphone (Android). The result is on GitHub, and is based on the jMRTD library, which provides all the necessary low-level details. As I pointed out in my previous article, the standards for the ePassports have evolved a lot throughout the years – from no protection, to BAC, to EACv1, EACv2 and SAC (which replaces BAC). Security is still doubtful, as most of the passports and inspection systems require backward compatibility to BAC. That’s slowly going away, but even when BAC goes away, it will be sufficient to enter the CAN (Card Authentication Number) for the PACE protocol, so the app will still work with minor modifications. What the app does is: Establishes NFC communication Authenticates to the passport using the pre-entered passport number, date of birth and expiry date (hardcoded in the app at the moment). Note that the low security of the protocol is due to the low entropy of this combination, and brute force is an option, as passports cannot be locked after successive failures. Reads mandatory data groups – all the personal information present in the passport, including the photo. In the example code only the first data group (DG1) is read, and the personal identifier is shown on the screen. The way to read data groups is as follows: InputStream is = ps.getInputStream(PassportService.EF_DG1); DG1File dg1 = (DG1File) LDSFileUtil.getLDSFile(PassportService.EF_DG1, is); Performs chip authentication – the first step of EAC, which makes sure that the chip is not cloned – it requires proof of ownership...
by Bozho | Mar 31, 2016 | Aggregated, Opinions
We’re building software in hope that some day we’ll leave it and it will live on its own. Or with minor supervision. But the other day when my father asked me to dig an old website, I did some thinking and realized auto-pilot software is almost never the case. Software is either being supported, or is abandonware, or is too simple. We constantly have to “fix” something, on each piece of software. Basically, picking up an old project and running it is rather hard – it would most probably require upgrading a ton of components. For example: Fixing edge cases, bugs, security issues. The software environment is dynamic, and no complex software is without uncovered edge cases. Security issues arise constantly and have to be patched. Unless we find a way to write bugless software with perfect security, we have to support all these. Breaking upgrades: browsers are being upgraded constantly, and old websites probably won’t work. Protocols remain backward compatible for a while, but then support is discontinued and one has to upgrade. Operating systems introduce breaking changes to software running on them – one clear example is Android, where with each major version something doesn’t work anymore (because it was deprecated 2 versions prior) or has to be done in a different way. We have to be there and tweak our code to accommodate these upgrades. Frameworks and languages get upgrades as well – and sometimes we can’t even build our legacy software anymore. Even if we can, the target environment may not support our old versions. The aforementioned site was written in PHP 4. Shared hosting...
by Bozho | Mar 31, 2016 | Aggregated, Opinions
We’re building software in hope that some day we’ll leave it and it will live on its own. Or with minor supervision. But the other day when my father asked me to dig an old website, I did some thinking and realized auto-pilot software is almost never the case. Software is either being supported, or is abandonware, or is too simple. We constantly have to “fix” something, on each piece of software. Basically, picking up an old project and running it is rather hard – it would most probably require upgrading a ton of components. For example: Fixing edge cases, bugs, security issues. The software environment is dynamic, and no complex software is without uncovered edge cases. Security issues arise constantly and have to be patched. Unless we find a way to write bugless software with perfect security, we have to support all these. Breaking upgrades: browsers are being upgraded constantly, and old websites probably won’t work. Protocols remain backward compatible for a while, but then support is discontinued and one has to upgrade. Operating systems introduce breaking changes to software running on them – one clear example is Android, where with each major version something doesn’t work anymore (because it was deprecated 2 versions prior) or has to be done in a different way. We have to be there and tweak our code to accommodate these upgrades. Frameworks and languages get upgrades as well – and sometimes we can’t even build our legacy software anymore. Even if we can, the target environment may not support our old versions. The aforementioned site was written in PHP 4. Shared hosting...
by Bozho | Mar 19, 2016 | Aggregated, Opinions
A software project can become “legacy” just after three months from its inception. I’ve recently seen many projects that look OK on the surface, but are in fact so “broken”, that they have to be rewritten. Well, they work, but continuing their support is a pain. And everyone has probably seen at least one such project, where you want to just throw it away and start from scratch. The problem is – starting from scratch won’t guarantee the good outcome either. Why things go that way? I think it’s because developers tend to solve problems one at a time, achieving a “local maximum”. They don’t need to be “quick dirty fixes” – any even reasonably sounding fix for the particular problem at hand may yield de-facto legacy code. And if we view software development as constant problem fixing (as even introducing new features consists of fixing problems along the way), we have a problem. My approach to that process is to take a step back and ask the question “is this really the problem I’m solving, or is there a bigger underlying problem”. And sometimes there is. There are some clear indications that there is such a problem. “Code smell” is a popular term for that, but I’d like to extend it – sometimes it’s not the thing that you do that makes things smell, but rather something done before makes you take stupid decisions later. Sometimes these decisions don’t even look wrong in the context that you’ve created with your previous decisions, but they are certainly wrong. And you can use them as indicators. Some examples: If you...
by Bozho | Feb 22, 2016 | Aggregated, Developer tips
You will find a lot of posts and stackoverflow answers telling you how to pretty-print JSON responses. But sometimes you may need to tune the “prettiness” per request. The use case for this is when you are using tools like curl or RESTClient to interact with the system and you want human-readable output. Of course, if you need human-readable output only for debug purposes, you should really consider whether you need JSON at all, or you should use some binary format. But let’s assume you need JSON. And that you’d rather get it pretty-printed, rather than use an external tool to prettify it afterwards. The basic idea is to enable pretty-printing with either a GET parameter, or preferably with an Accept header like application/json+pretty. With Spring MVC that is not supported out of the box. You’d need to create a class like that: /** * An subclass of the MappingJackson2HttpMessageConverter that accespts the application/json+pretty content type * in order to enable per-request prettified JSON responses * * @author bozho * */ public class PrettyMappingJackson2HttpMessageConverter extends MappingJackson2HttpMessageConverter { /** * Construct a new {@link MappingJackson2HttpMessageConverter} using default configuration * provided by {@link Jackson2ObjectMapperBuilder} */ public PrettyMappingJackson2HttpMessageConverter() { super(); objectMapper.enable(SerializationFeature.INDENT_OUTPUT); setSupportedMediaTypes(Lists.newArrayList(new MediaType("application", "json+pretty", DEFAULT_CHARSET))); } } Then in your spring-mvc xml configuraton (or java config counterpart) you should register this as a message converter: <mvc:message-converters> <bean class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter" /> <!-- Handling Accept: application/json+pretty --> <bean class="com.yourproject.util.PrettyMappingJackson2HttpMessageConverter" /> </mvc:message-converters> If you have a separately defined ObjectMapper and want to pass it to the pretty converter, you should override the other constructor (accepting an object mapper), and use the .copy() method before enabling the...
Recent Comments