Feature request: support for using proguard about ant-javacard HOT 7 CLOSED

I have been using ProGuard myself in JC context, but after giving it some thought, the size matters are not that critical with any recent and decent cards and I do not have high trust in the optimizations done by PG. Most JC projects should be small enough to be able to hand-tune, hand-verify and hand-optimize.

from ant-javacard.

To clarify: the point of ant-javacard is to provide a transparent and very thin yet usable layer on top of the Oracle tools, that would allow building applets in an offline environment without 50mb of dependencies and still providing some high level DWIM. I would like to keep it as minimal as possible.

Every kind of automagic testing or shrinking or wrapping etc could happen in a more flexible and featureful environment such as Gradle (https://github.com/bertrandmartel/javacard-gradle-plugin).

from ant-javacard.

My main reason for not wanting to go the hand-optimized route is that it destroys reusability and mergeability of code in current practice. People will want to strip the overhead from any large featureful dependency (such as a big crypto library) and without proguard the best option is to fork the library - which is bad. The usage pattern I mean here is to use "-flattenpackages" to combine your libraries into a single Java(Card) package, which I call a "consolidated" build in some of my non-public projects.

Gradle and Maven do not work for me outside of a well-organized corporate environment because they force you to work with online dependency retrieval unless you maintain your own repository and build infrastructure. And even then they suffer serious dependency creep. For smartcard work, which I often do on airgaps, ant is much simpler and works very well for me.

Your argument about the size and dependencies of proguard is equally valid though. My proposal is to implement this in a way such that proguard is optional. This can be done easily because the proguard ant plugin does not actually do anything but pass command arguments. All ant-javacard would have to do is to that same thing and provide some sane defaults.

Given the length of my own argument I suppose that I should prove it with code instead of arguing. ;)

from ant-javacard.

My main argument is that JavaCard is not Java. If you approach it as "standard Java" you probably do something wrong.

The idea of ant-javacard is to provide sensible and meaningful or at least universally safe defaults and it is hard if not impossible to provide them for an optimizer such as proguard.

Like you would not want your compiler to optimize out your double checks (which you do implement, don't you?), you probably do not want unknown modifications of your code by default. Most JavaCard projects I have seen are countable-on-fingers-thousand lines of useful code, which is small enough to fully optimize by hand. Readability of security related code trumps performance (which is anyway slow).

I would be reluctant to include such feature, but feel free to convince me or prove me wrong :)

from ant-javacard.

All in all I completely agree, and proguard isn't exactly the most elegant method possible for what I use it for. Maybe there is a different solution that I did not consider yet.

For further thought and discussion, possibly by other users of ant-javacard:

Scenario 1:

• Image an open-source crypto library with lots of ciphers in one common Java and JavaCard package
• Image an application that uses just a few of those primitives
• Problem: the whole package must be reviewed and installed

Scenario 2:

• Imagine an open-source crypto library with lots of ciphers in separate Java and JavaCard packages
• Imagine an application using just a few of those packages
• Problem: lots of packages to manage during review and issuance
• Problem: packages have considerable overhead (very expensive if they have just one class)
• Advantage: review and acceptance could happen at package granularity, making the packages truly reusable in cases where functionality is well-factored ("one cipher in a package")

While I agree with Martins point that security applications need stringent detailed review anyway and manual work is an acceptable means it would still be great if platform features could be used in a way that promotes library reuse better than the available solutions.

So I am still not sure what the best way is. Leaving this open for other users to discuss.

from ant-javacard.

Scenario 3 (current real-world open-source situation):

• Open-Source libraries with considerable functionality exist
• No good reuse solution is available
• Result: many forks - code and fixes get lost because of high merging effort

from ant-javacard.

Closing this as a stale, will-not-do-unless-rethinking-thing

from ant-javacard.