Architecte et expert technique freelance

Il aura fallu un peu plus de 3 ans pour que la solution de la « serrure connectée » soit autonome, et je la laisse entre de bonnes mains.

Il est temps pour moi de proposer mes services à de nouvelles structures. Avec 10 d’expériences de conception et de développement et 10 ans d’architecture applicative et système ; mes connaissances couvrent un spectre assez large : analyse et conception (IAF), développement backend (Java, PHP), développement mobile (Android et IOS), définition et mise en œuvre d’infrastructure cloud (AWS, python), sécurisation (TLS, X509…), expertise système linux (debian, ubuntu), cryptographie (AES, RSA), conception de protocole et contrat d’interface (M2M), customisation d’Android (AOSP), amélioration des performances des systèmes existants (Mysql, MariaDB, nginx, analyse de complexité…).

 

Je suis joignable par email : chrystophe.vergnaud [at] gmail.com pour discuter de votre futur projet ou d’une problématique en production.

Mémo sur la gestion/signature de clés RSA depuis un keystore java

créer la clé privée du ca et le certificat autosigné du ca
 openssl req -x509 -newkey rsa:1024 -keyout ca.key -out ca.crt
créer la paire de clé du user
 $JAVA_HOME/bin/keytool -genkey -alias "Chrystophe Vergnaud" -keyalg RSA -dname "CN=Chrystophe Vergnaud, OU=ICI, O=MY_HOME, L=HOME,S=31, C=FR" -storepass "change_moi" -keypass "un_truc_secret" -keystore cve.jks -storetype jks
faire la demande de certif du user
 ${JAVA_HOME}/bin/keytool -certreq -file cve.csr -storepass "change_moi" -alias "Chrystophe Vergnaud" -keystore cve.jks -storetype jks
signer la demande
 openssl x509 -req -days 1200 -in cve.csr -CA ../ca/ca.crt -CAkey ../ca/ca.key -CAcreateserial -out cve.crt
importer le certificat du CA dans le kstore
 ${JAVA_HOME}/bin/keytool -importcert -trustcacerts -alias "mon_ca" -file ../ca/ca.crt -keystore cve.jks -storepass "change_moi" -storetype jks
 repondre oui a la question
importer le certificat signé dans le kstore
 ${JAVA_HOME}/bin/keytool -importcert -alias "Chrystophe Vergnaud" -file cve.crt -keystore cve.jks -storepass "change_moi" -storetype jks
afficher le contenu du keystore
 ${JAVA_HOME}/bin/keytool -list -v -keystore cve.jks -storepass "change_moi" -storetype jks
exporter en pkcs12
 keytool -importkeystore -srckeystore cve.jks -destkeystore cve.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass "change_moi" -deststorepass "change_moi_mieux"

ps : l’option storepass est à éviter en production mais en phase de test elle évite de choper une crampe.

L’encodage des chaînes de caractère en Java et comment gérer l’internationalisation

Quelques notes pour mieux comprendre les notions de conversion de charset et d’internationalisation en java.

Comprendre la base : le char

Il faut identifier ce que contient le type primaire char et son grand frère le Character :

The char data type (and therefore the value that a Character object encapsulates) are based on the original Unicode specification, which defined characters as fixed-width 16-bit entities. The Unicode standard has since been changed to allow for characters whose representation requires more than 16 bits. The range of legal code points is now U+0000 to U+10FFFF, known as Unicode scalar value. (Refer to the definition of the U+n notation in the Unicode standard.)

The set of characters from U+0000 to U+FFFF is sometimes referred to as the Basic Multilingual Plane (BMP). Characters whose code points are greater than U+FFFF are called supplementary characters. The Java 2 platform uses the UTF-16 representation in char arrays and in the String and StringBuffer classes. In this representation, supplementary characters are represented as a pair of char values, the first from the high-surrogates range, (\uD800-\uDBFF), the second from the low-surrogates range (\uDC00-\uDFFF).

A char value, therefore, represents Basic Multilingual Plane (BMP) code points, including the surrogate code points, or code units of the UTF-16 encoding. An int value represents all Unicode code points, including supplementary code points. The lower (least significant) 21 bits of int are used to represent Unicode code points and the upper (most significant) 11 bits must be zero. Unless otherwise specified, the behavior with respect to supplementary characters and surrogate char values is as follows:

* The methods that only accept a char value cannot support supplementary characters. They treat char values from the surrogate ranges as undefined characters. For example, Character.isLetter(‘\uD840’) returns false, even though this specific value if followed by any low-surrogate value in a string would represent a letter.
* The methods that accept an int value support all Unicode characters, including supplementary characters. For example, Character.isLetter(0x2F81A) returns true because the code point value represents a letter (a CJK ideograph).

In the Java SE API documentation, Unicode code point is used for character values in the range between U+0000 and U+10FFFF, and Unicode code unit is used for 16-bit char values that are code units of the UTF-16 encoding. For more information on Unicode terminology, refer to the Unicode Glossary.

extrait de http://java.sun.com/javase/6/docs/api/java/lang/Character.html

Ensuite comprendre la String

Ensuite comprendre qu’une String est encodée en UTF-16, la problématique du charset est à  gérer en entrée et en sortie du code java pas en interne… :

A String represents a string in the UTF-16 format in which supplementary characters are represented by surrogate pairs (see the section Unicode Character Representations in the Character class for more information). Index values refer to char code units, so a supplementary character uses two positions in a String.

The String class provides methods for dealing with Unicode code points (i.e., characters), in addition to those for dealing with Unicode code units (i.e., char values).

extrait de http://java.sun.com/javase/6/docs/api/java/lang/String.html

Le lien entre le flux externe et la String

Ensuite comprendre comment extraire une String d’un flux (avec le bon encodage évidemment) :

http://java.sun.com/docs/books/tutorial/i18n/text/stream.html

Il faut penser à optimiser leur exemple avec :
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));

et enfin i18n

Le tuto java sur l’internationalisation (i18n) est clair et se suffit à lui même.

Développer un bundle sur la plateforme Dysoweb de Requea

Je viens de mettre à  jour le wiki de Dysoweb pour faciliter la prise en main du produit par les contributeurs.

En complément, voici quelques liens utiles :

Utiliser jml

Un petit script pour utiliser JML sur une machine à  base de JDK1.5

Créez un fichier prepareJML.sh et redéfinissez les *_HOME :

#!/bin/bash
echo "activation des chemins pour JML"
export JAVA_HOME=~/j2sdk1.4.2_12
export JML_HOME=~/JML
export JUNIT_HOME=~/junit4.1
export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib:$JML_HOME/bin/jmljunitruntime.jar:$JML_HOME/bin/jmlmodels.jar:$JML_HOME/bin/jmlmodelsnonrac.jar:$JML_HOME/bin/jml-release.jar:$JML_HOME/bin/jmlruntime.jar:$JUNIT_HOME/junit-4.1.jar
export PATH=$JAVA_HOME/bin:$JML_HOME/bin:$PATH

ensuite il suffit de lancer:

$ source prepareJML.sh

et voila les chemins sont valides.

ps : on definit en dur les chemins des .jar JML car il ne parcourt pas les jar du répertoire bin…