Le 09/07/2013 à 10h 05

Encore que d’un côté, réunir des ports ensemble est pratique et fallait y penser.

Comme il a déja été dit par benjarobin:

La concurrence n’est pas vraiment gênée par ce brevet : On pourra toujours avoir un port USB et un lecteur de carte SD sur un PC. Il fallait avoir l’idée avant


De l’autre, breveter la disposition de 2 ports l’un sur l’autre, je trouve que c’est du même acabit que de breveter quelque chose de rectangulaire aux bord ronds.

Se réjouir de l’idée, oui, breveter un placement…. bof.

Le 05/07/2013 à 07h 48

@127.0.0.1
Accéder = assigner? (souci de terminologie pour moi). Dans ce cas, si je comprends bien, il suffit de faire par exemple:

private static int inutile=255;

Rien que cet assignation va donc provoquer l’initialisation de la classe. Même si la classe n’est pas référencé dans le code d’origine.

C’est ça?

Le 04/07/2013 à 15h 56

@Khalev

J’ai déja vu des

import com.truc.machin.chouette.*;

pour éviter de se taper la liste des classes à importer.

Le 04/07/2013 à 15h 50

Si je peux me permettre, un store sérieux?

Avec Google qui pratique une vérification à postériori (c’est toujours le cas?) des applications sur son playstore, tu le classes où?
" />

A mon grand regret, la pomme a le mérite de faire ça avant la publication mais bon on parle de modèles différents

Le 04/07/2013 à 15h 42

mot clé static?

Je ne suis pas expert en JAVA (ni en dev au sens large), mais il me semble que le mot clé static permet de forcer la mise en mémoire d’un objet dès le lancement.
En gros écris une classe qui fait quelque chose de méchant. Puis dans une autre classe instancie en un en étant static. Même si cette seconde classe n’est pas appelée, le mot static force l’instanciation de la première classe dans la mémoire pour qu’elle soit disponible dans le reste du code.

Jme trompe?

Le 04/07/2013 à 15h 09

millman42 a écrit :

Il faut savoir que ce qui est signé dans un apk c’est le fichier contenant le sha1 de tout les fichiers et pas l’apk au complet. Si un des fichiers est modifié android le détecte car le sha1 change. De même si on modifie le fichier qui contient la sha1 la signature de celui-ci change et android le détecte. Cependant il serait possible de rajouter des fichiers dans le apk sans les rajouter dans cert.cf (le fichier qui contient les hashs sha1). La faille c’est que android va installer ces fichiers tout de même sans les vérifier car il ne sont pas dans cert.cf.



De http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html#Verifying

Read each file in the JAR file that has an entry in the .SF file. While reading, compute the file’s digest, and then compare the result with the digest for this file in the manifest section. The digests should be the same, or verification fails.


A supputer que jarsigner (ou des parties de son code) est utilisé pour la vérification, donc en gros, la vérification n’est faite que sur les fichiers qui sont mentionnés dans le .SF…..

D’accord avec fred42, mais c’est quand même vachement gros pour que personne ne l’ai vu depuis tout ce temps (je ne suis pas dev android " /> ).

Le 04/07/2013 à 14h 35

Raknor a écrit :

Merci NeVeS et Khalev, moi j’étais déjà toute chèvre….

Pour préciser un peu plus ce que viens de dire millman42

D’après http://developer.android.com/tools/publishing/app-signing.html, jarsigner est utilisé pour la signature.

D’après http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html (recherche google oracle nsa….. bon bref), 2 fichiers sont incorporés dans le fichier .apk (qui n’est qu’un .jar). En particulier, un fichier .dsa (signature du .sf mentionné par millman42) qui contient la signature et le certificat.

Ainsi, @Glubglub : vous n’avez qu’à prendre 2 versions d’un .apk, les ouvrir, comparer le contenu de ces fichiers et nous dire si d’une part vous avez le même certificat, et d’autre part, si la signature est identique. (un peu compliqué si ce sont des fichiers binaires mais je ne pense pas sinon pour la portabilité on repassera)

Pour une personne qui, au début, parlait de “tag” qu’on pouvait remettre à l’identique, je (on, si je ne suis pas seul) pensais que vous aviez déjà vu la tête de cette signature. Maintenant que vous avez reconnu que signature = hash chiffré et vu la description du processus de signature et de vérification, je suis désolé mais pour ma part, c’est toute votre crédibilité que je remet en cause.

D’autant que le problème que vous venez enfin de soulever/admettre à la fin de ce débat est justement le sujet de la news. Vrai faille ou pas? Si oui, quelle est-elle?

Le 04/07/2013 à 14h 29

Merci NeVeS et Khalev, moi j’étais déjà toute chèvre….

Pour préciser un peu plus ce que viens de dire millman42

D’après http://developer.android.com/tools/publishing/app-signing.html, jarsigner est utilisé pour la signature.

D’après http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jarsigner.html (recherche google oracle nsa….. bon bref), 2 fichiers sont incorporés dans le fichier .apk (qui n’est qu’un .jar). En particulier, un fichier .dsa (signature du .sf mentionné par millman42) qui contient la signature et le certificat.

Ainsi, @Glubglub : vous n’avez qu’à prendre 2 versions d’un .apk, les ouvrir, comparer le contenu de ces fichiers et nous dire si d’une part vous avez le même certificat, et d’autre part, si la signature est identique. (un peu compliqué si ce sont des fichiers binaires mais je ne pense pas sinon pour la portabilité on repassera)

Pour une personne qui, au début, parlait de “tag” qu’on pouvait remettre à l’identique, je (on, si je ne suis pas seul) pensais que vous aviez déjà vu la tête de cette signature. Maintenant que vous avez reconnu que signature = hash chiffré et vu la description du processus de signature et de vérification, je suis désolé mais pour ma part, c’est toute votre crédibilité que je remet en cause.

D’autant que le problème que vous venez enfin de soulever/admettre à la fin de ce débat est justement le sujet de la news. Vrai faille ou pas? Si oui, qu’elle est-elle?