Skip to content

Building

Martin Paljak edited this page Oct 8, 2024 · 14 revisions

Building GlobalPlatformPro from source

Building GlobalPlatformPro from the source is simple and straightforward. JDK 11 LTS (or newer) is required.

git clone https://github.com/martinpaljak/GlobalPlatformPro
cd GlobalPlatformPro
./mvnw verify
# use ./tool/target/gp.jar

Installing necessary dependencies

Debian/Ubuntu

apt-get install --no-install-recommends libccid openjdk-11-jdk git

Fedora/CentOS

yum install pcsc-lite-ccid java-11-openjdk-devel git
service pcscd start # start PC/SC service

FreeBSD

pkg install devel/libccid java/openjdk11 devel/git

Included/used open source projects

  • BouncyCastle for various cryptographic and utility purposes (MIT)
  • JOpt Simple for parsing the command line (MIT)
  • apdu4j for APDU access/logging/replaying (MIT)
  • ber-tlv by @evsinev for TLV parsing and generation (Apache)
  • Launch4j for generating the .exe (BSD/MIT)

Maven dependency and API

Note

Maven Central publishing is discontinued.

Releases are published to https://mvn.javacard.pro/maven/. To use it, add the repository to your pom.xml:

<repositories>
    <repository>
        <id>javacard-pro</id>
        <url>https://mvn.javacard.pro/maven/</url>
    </repository>
</repositories>

Then add the dependency (check the version from release area):

<dependency>
    <groupId>com.github.martinpaljak</groupId>
    <artifactId>globalplatformpro</artifactId>
    <version>20.01.23</version>
</dependency>

Warning

There are NO guarantees on the stability of the API.

The focus of GlobalPlatformPro the command line utility. Efforts are made so that any refactorings needed should only get easier to understand and implement by time, as the library evolves.

  • General rules:
    • Expect RuntimeException-s when things go unexpectedly wrong
    • CardException-s when link layer fails
    • GPException-s when protocol layer fails

Design principles

  • focus on real life and practical daily use cases
  • KISS, YAGNI, DWIM, no-NIH
  • APDU-chat over anything (BIBO - Bytes In, Bytes Out) to (most probably real) devices
  • thin and self-contained, re-usable, easy to integrate
  • easily readable, auditable and secure codebase (less is more)