Skip to content
Snippets Groups Projects
Commit d2d01055 authored by Sébastien Blin's avatar Sébastien Blin Committed by Adrien Béraud
Browse files

documentation: re-organize doc

Change-Id: I9c2bf00dd7734889646f73db55cb475bd2cc4417
parent 1ab9c5b7
Branches
No related tags found
No related merge requests found
File moved
#########
Processes
#########
This section describes the processes that are used to develop and release the
software.
.. toctree::
:maxdepth: 1
design-process
release-process
\ No newline at end of file
Protocol
========
Jami account creation
---------------------
A **Jami account** is defined by an **RSA key pair** with a key length
of at least 4096 bits.
The standard x509 160-bits fingerprint of the account public key is
called the **RingID**.
The account public key is used as the subject of an x509 certificate
that must be valid, have the Certificate Authority flag set, and can be
self-signed. This certificate is called the **Jami account
certificate**.
The subject UID field of the account certificate must be the hexadecimal
form of the public key fingerprint. The issuer UID field must be the
hexadecimal form of the issuer public key fingerprint.
### Persisting the account
Persisting a Jami account private key and certificate is implementation
defined.
Access to a saved Jami account private key must be authenticated and
authorized. Authentication and authorization method to access the
account private key is implementation defined.
### Adding a device to a Jami account
*See [RFC 5280](https://tools.ietf.org/html/rfc5280)*
A **device** is defined by an RSA key pair with a key length of at least
4096 bits.
A **device certificate** is defined as an x509 certificate whose subject
is a device public key, signed with an account private key. The
certificate MUST be valid. The issuer UID field MUST be the hexadecimal
form of the account public key fingerprint.
Persisting a device private key and certificate is implementation
defined. Access to a saved device private key should be authenticated.
Authentication method to access the device private key is implementation
defined.
### Removing a device from a Jami account
A device can be "removed" from a Jami account through revocation of the
device certificate. Revoked device certificates are added to one or more
standard x509 Certificate Revocation List (CRL). CRLs for revoked device
must be valid and signed with the corresponding CA key, which is the
Jami account private key.
### Account transmission format
The **account archive format** defines how to serialize an account
private key for transmission, for instance to sign a new device
certificate.
The account archive is an encrypted JSON object with the following
structure:
```
{
"ringAccountKey": (PEM-encoded account private key string),
"ringAccountCert": (PEM-encoded account certificate string),
"ringAccountCRL": (PEM-encoded account CRL string)
}
```
The JSON object can contain additional implementation-defined key-value
pairs. Implementation-defined key names shouldn't start with "ring".
The string JSON object is encrypted using a key defined as :
```
salt = PIN + timestamp
key = argon2(password, salt)
```
Where PIN is a random 32bits number in hexadecimal form, "+" is string
concatenation, timestamp is the current UNIX timestamp divided by 1200
(20 minutes) and password is a user-chosen password.
The PIN should be shown to the user to be copied manually on the new
physical device along with the password.
Contacting another account
--------------------------
### ICE descriptor exchange over OpenDHT
- **Listening for incoming calls**
A device listens for incoming call by performing a listen OpenDHT
operation on
`h("callto"+deviceID)`
where h is SHA1, "+" is the string concatenation and deviceID is the
hexadecimal form of the deviceID.
Received OpenDHT values that are not encrypted or not properly signed
must be dropped. The value must be encrypted with the called device
public key and signed with the calling device private key according to
OpenDHT specifications.
- **Sending the Initial Offer**
*See [RFC 5245](https://tools.ietf.org/html/rfc5245)*
RFC 5245 defines ICE (Interactive Connectivity Establishment), a
protocol for NAT traversal.
ICE is used in Jami to establish a peer-to-peer communication between
two devices.
The calling device gathers candidates and build an Initial Offer
according to the ICE specifications and starts the ICE negotiation
process.
The calling device puts the encrypted ICE offer (the Initial Offer) on
the DHT at h("callto"+deviceID) where deviceID is the hexadecimal form
of the called deviceID.
- **ICE serialization format**
ICE messages exchanged between peers during a call setup use following
format. An ICE message is a chunk of binary data, following
[msgpack](http://msgpack.org/) data format.
This protocol is a compound of msgpack values, successively packed in
this order:
+ an integer giving the version of ICE message format protocol used for the rest of the data. Current defined protocol version is **1**.
+ a 2-elements array of strings of the ICE local session ufrag and the ICE local session password
+ an integer giving the number of components in the ICE session
+ an array of string, of the previous number entries, where each string describe the ICE candidate, formated as an "a=" line (without the "a=" header) described in [rfc5245, section 4.3](https://tools.ietf.org/html/rfc5245#page-26)
- **Sending the Answer**
Upon reception of the encrypted and signed Initial ICE Offer (through
the listen operation), a called device should perform authorization
checks of the calling device, identified as the Initial Offer signer.
Authorization rules are implementation defined, but a typical
implementation would authorize known or trusted contacts.
If the calling device is not authorized or if for any implementation
defined reason the called device refuses the incoming connection
request, the called device must ignore the Initial Offer and may log the
event.
If the called device authorizes the caller and wish to accept the
connection it must build an ICE answer, start the ICE negotiation
process and send the encrypted and signed ICE answer at the same DHT
key.
### DTLS negotiation
Once a peer-to-peer communication channel has been established, the
called device listens on it for incoming DTLS connections (acting as a
DTLS server) while the caller initiates an outgoing DTLS connection
(acting as a DTLS client).
The DTLS communication must be RFC6347 compliant
([1](https://tools.ietf.org/html/rfc6347)).
Peers must only support PFS cypher suites. The set of supported cypher
suites is implementation defined but should include at least
ECDHE-AES-GCM (TODO: specify the exact suites recommended to support).
During the DTLS handshake, both peers must provide their respective
device certificate chain and must authenticate the other peer, checking
that its public key is the same used during the DHT ICE exchange.
### SIP call
*See [Important\_RFC](Important_RFC "wikilink")*
Once an encrypted and authenticated peer-to-peer communication channel
is available, the SIP protocol [2](https://tools.ietf.org/html/rfc3261)
must be used to place a call and send messages. The caller might send a
SIP INVITE as soon as the DTLS channel is established.
The SIP implementation must support ICE and SRTP.
Supported codecs are implementation defined, but Jami clients should
support the Opus audio coded and the H264 video codec.
SRTP must be used when negotiating media with SIP, using a new random
key for each media and each negotiation. ICE should be used when
negotiating media with SIP.
Cryptographic primitives
------------------------
### Password stretching
*See [Argon2
specifications](https://github.com/P-H-C/phc-winner-argon2/blob/master/argon2-specs.pdf)*
Passwords are stretched using argon2i using t\_cost = 16, m\_cost =
2\^16 (64 MiB), mono-threaded, to generate a 512 bits hash.
The result is then hashed again using SHA{1, 256, 512} depending on the
requested key size.
### Encryption
##### Using a provided key (128, 192 or 256 bits)
Encryption uses standard AES-GCM as implemented by Nettle using a random
IV for each encryption.
##### Using a text password
The password is stretched to generate a 256 bits key and a random salt
of 128 bits.
The input data is encrypted using AES-GCM (see above) and the salt is
appended at the beginning of the resulting cypher-text.
##### During a call
Audio/video data are exchanged using encrypted RTP channels between
peers.
The protocol is a classic SRTP, with following supported crypto suites:
- Jami account force AES\_CM\_128\_HMAC\_SHA1\_80
- SIP can use AES\_CM\_128\_HMAC\_SHA1\_80 or
AES\_CM\_128\_HMAC\_SHA1\_32
The master key and salt is a random number, different for each call. On
call's master key is constant during the full live of a call.
The keys are exchanged using SDES method: keys are written into the SIP
SDP messages during the SIP INVITE negotiation. When SDES is used, Ring
forces the underlaying transport to be secure (encrypted) to not
disclose these keys. Jami supports DTLS natively for SIP and Ring
accounts for such. The call cannot be done if this condition is not
fulfilled.
Technical overview
==================
Concepts
--------
## Jami Account
- A **Jami account** is defined by a cryptographic Jami Identity based
of **RSA asymmetric key-pair** and managed with **x.509
certificates** as defined by *[RFC
5280](https://tools.ietf.org/html/rfc5280)*.
- Jami uses the **gnutls** library to generate and manage RSA keys
and certificates.
### Jami certificate
- This represents the identify of a Jami user.
- Generated at account creation
- Contains the Jami account public key.
- The SHA-1 fingerprint (160-bits) of this public certificate is the
**JamiId**.
- Signed by a CA (from an organization or self-signed).
- The subject UID field must be the hexadecimal form of the JamiId.
- The issuer UID field must be the hexadecimal form of the issuer
public key fingerprint (CA).
- Random RSA key-pair of at least 4096-bits long.
### Device certificate
- This is the identity of one specific device used to run Jami.
- One per device.
- Random and 4096-bits long.
- The SHA-1 fingerprint of the public key becomes the **DeviceId**.
- Must be signed by the private key that created the Jami certificate.
- The subject UID field must be the hexadecimal form of the DeviceId.
- The issuer UID field must be the hexadecimal form of the issuer
public key fingerprint (JamiId).
### Usages
- The JamiId:
- It's the DHT key where the list of account devices are published
and where all devices listen to synchronize on account
changes (i.e. adding or revoke a device).
- The Jami certificate RSA keys are used as long-term keys to
sign/encrypt/decrypt messages sent over the DHT:
- private key to sign-off and decrypt incoming messages and
device certificates.
- public key to encrypt messages (this is done by the message
issuer using the receiver public key).
- A device can be "removed" from a Jami account through revocation of
the device certificate:
- Revoked device certificates are added to one or more standard
x509 Certificate Revocation List (CRL).
- CRLs for revoked device must be valid and signed with the
corresponding CA key, which is the Jami account private key.
### Long-term Storage
- Why storing data?
<!-- -->
- - Jami needs to load certificates and key-pairs each time the
application is started.
- When Jami creates a new device, these information are also
needed, shared from another trusted device in a secure way.
- All platforms doesn't provide secure way to store data, Jami
supports this fact by encrypting data stored outside the
memory (i.e. on a file-system) using a user defined password
during the account creation.
<!-- -->
- These files are stored on user device (see below for details):
- a compressed and encrypted archive with private account data.
- the public certificates chain as a CRT file
- the device private key.
#### Jami archive (export.gz)
- Contains private account data.
- Currently transmitted over the DHT network when device is created
or revoked.
- It's a JSON compressed and encrypted file.
<!-- -->
- The current format is (could change at any time):
```
{
ringCaKey: <base64 serialized PEM-encoded CA private key>,
ringAccountKey: <base64 serialized PEM-encoded Jami private key>
ringAccountCert: <base64 serialized PEM-encoded Jami certificate (public key)>,
ethKey: <base64 serialized of the optional 160-bits Etherium key used to register the JamiId on a public blockchain>,
ringAccountCRL: <base64 serialized of packet list of revoked device certificates PEM-encoded>,
ringAccountContacts: <JSON dictionary to export trusted user contacts>
}
```
- The JSON byte-stream is compressed using \*gzip\* algorithm.
<!-- -->
- Then the gzip-stream is encrypted using AES-GCM-256 symmetric cipher
with a 256-bits key.
- This key is derived from the user provided password, a PIN and a
timestamp, using
[Argon2](https://github.com/P-H-C/phc-winner-argon2) (a password
stretching and normalizer) as follow:
```
salt = PIN + timestamp
key = argon2(password, salt)
argon2 is the argon2i algorithm using t_cost = 16, m_cost = 2^16 (64 MiB), mono-threaded, to generate a 512-bits key and then hashed with SHA-256 to generate a 256-bits key.
PIN is a random 32bits number in hexadecimal form.
+ is string concatenation operator.
timestamp is the current UNIX timestamp divided by 1200 (20 minutes).
password is a user-chosen password (given at account creation).
```
- The PIN should be shown to the user to be copied manually on the new
physical device along with the password to finish the device
creation process.
- NOTE: when exporting a file on the DHT or anywhere else, the daemon update the archive first, to write latest contacts. This is the reason why the password is needed when exporting (it's not just a copy of the archive somewhere else)
#### Jami device certificate chain (ring\_device.crt)
- PEM format
- Includes the Device certificate and parent certificates (Jami device
certificate and parents)
#### Device private key (ring\_device.key)
- PEM format
- not encrypted, we let the device file-system protect this file
### The DHT network
Dedicated [ Jami distributed
network](Ring_distributed_network "wikilink") page.
### Contact Request
- Deprecated in favor of "Conversation requests"
### Conversation request
- Max 64k (a DHT value)
- Contains a conversation Id
- Contains the sender URI
- Can contains optional metadatas (avatar/profile)
### Instant Message
- Mostly used to initiate connections with ICE candidates
- Can transmit some SIP messages, however SIP channel is preferred
- SIP messages can be read status, location sharing, messages notifications.
### Outgoing and Incoming calls
- Contactable addresses (i.e. IP addresses) of the user are given to
peer only:
- When we call a peer (outgoing call).
- When a **trusted** peer is calling (incoming call).
- All combination forms of how a specific device can be contacted is
summarized by a ICE message:
- *[RFC 5245](https://tools.ietf.org/html/rfc5245)* defines ICE
(Interactive Connectivity Establishment), a protocol for
NAT traversal.
- ICE is used in Jami to establish a peer-to-peer communication
between two devices.
#### Making an outgoing call
1. The calling device gathers candidates and build an **Initial Offer**
according to the ICE specifications.
2. The calling device puts the encrypted ICE offer (the *Initial
Offer*) on the DHT at:
`h("`[`callto:"+DeviceID`](callto:%22+DeviceID)`)` where *h* is
SHA1, *+* is the string concatenation, *DeviceID* is in
hexadecimal form.
3. The calling device waits on the peer answer, with its own ICE
candidates lists.
4. At peer answer reception, the calling device starts the
ICE negotiation.
5. If the negotiation succeed, the process continues on a client-side
DTLS session establishment over the created ICE socket (see below).
#### Listening for incoming calls
1. A device listens for incoming calls by performing a listen OpenDHT
operation on `h("`[`callto:"+DeviceID`](callto:%22+DeviceID)`)`
where *h* is SHA1, *+* is the string concatenation and *DeviceID* is
in hexadecimal form.
2. At ICE *Initial Offer* reception, the called device **must** do a
security validation of the peer (see below).
3. If the security validation succeed, the called device starts the
ICE negotiation.
4. If the negotiation succeed, the process continues on a server-side
DTLS session establishment over the created ICE socket (see below).
- *Note: OpenDHT drops values that are not properly encrypted or
signed, as specified by OpenDHT protocol.*
#### ICE serialization format
- ICE messages exchanged between peers during a call set up use
following format.
- An ICE message is a chunk of binary data, following
[msgpack](http://msgpack.org/) data format.
```
<8-bits unsigned integer> giving the version of ICE message format protocol used for the rest of the data,
<C++ std::pair of string> of the ICE local session ufrag and the ICE local session password,
<8-bits unsigned integer> giving the number of components in the ICE session,
<array of string> of the previous number entries, where each string describe the ICE candidate, formated as an "a=" line (without the "a=" header) described in [rfc5245, section 4.3](https://tools.ietf.org/html/rfc5245#page-26)
```
- **Current defined protocol is 1**:
#### Security Validation of the Peer
- Upon reception of the encrypted and signed Initial ICE Offer
(through the listen operation), a called device should perform
authorization checks of the calling device, identified as the
Initial Offer signer.
- Authorization rules are implementation defined, but a typical
implementation would authorize known or trusted contacts.
- If the calling device is not authorized or if for any implementation
defined reason the called device refuses the incoming connection
request, the called device must ignore the Initial Offer and may log
the event.
- If the called device authorizes the caller and wish to accept the
connection it must build an ICE answer, start the ICE negotiation
process and send the encrypted and signed ICE answer at the same
DHT key.
#### DTLS negotiation
- Once a peer-to-peer communication channel has been established by
ICE protocol, the called device starts a server-side DTLS session on
the ICE socket, while the caller starts a client-side DTLS session
on the other side of the ICE socket.
- The DTLS communication is
[RFC6347](https://tools.ietf.org/html/rfc6347) compliant using
gnutls library.
- To prevent peer certificates to be displayed in plain-text for the
call anonymity, the session handshake is done twice:
1. A first handshake in **anonymous mode** to create a secure but
anonymous transport.
2. A second handshake in **certificate mode**, over the first one, to
prove the identity of peers.
- Only PFS cipher suites are supported:
- The set of supported cipher suites is implementation defined but
should include at least ECDHE-AES-GCM.
- The actual cipher suites (in gnutls form) is:
- anonymous step:
`SECURE192:-KX-ALL:+ANON-ECDH:+ANON-DH:+SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION`
- certificate step:
`SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION`
#### SIP signaling
- Used over the DTLS session to signaling the call (vcard, media
negotiation, hangup, instant messaging, ...)
- Once an encrypted and authenticated peer-to-peer communication
channel is available, the [SIP
protocol](https://tools.ietf.org/html/rfc3261) must be used to place
a call and send messages.
- The caller might send a SIP INVITE as soon as the DTLS channel
is established.
- The SIP implementation must support ICE and SRTP.
- Supported codecs are implementation defined, but Jami clients should
support the Opus audio coded and the H264 video codec.
- SRTP must be used when negotiating media with SIP, using a new
random key for each media and each negotiation. ICE should be used
when negotiating media with SIP.
### Presence
- Sent on the DHT
- DeviceAnnouncement (contains device hash + public key)
### Security / Privacy
Jami provides perfect forward secrecy for calls and in call text
messages with different Eliptic Curve Diffie-Hellman key negociation at
every call. For out of call messaging single RSA-4096 is used. The
cryptography library used is GNUTLS
More informations:
- [Technical overview](technical/Technical-overview) of concepts and
protocols inside Jami
......@@ -15,7 +15,7 @@ modify it under the terms of the `GNU General Public License
<https://www.gnu.org/licenses/gpl.html>`_ as published by the Free
Software Foundation, either version 3 of the License, or (at your
option) any later version. The Jami team :doc:`uses Gerrit for
development <developer/working-with-gerrit>` and code reviews, and
development <developer/new-developers/working-with-gerrit>` and code reviews, and
issues and feature requests are :doc:`tracked on the Jami GitLab
<user/bug-report-guide>`. The development of Jami is led by
`Savoir-faire Linux <https://savoirfairelinux.com/en>`_ --- a Canadian
......
Rapporter un bug (FR)
=====================
[Page](bug-report-guide) traduite par la communauté
**Note : Nous sommes actuellement quelques developpeurs actifs sur le projet. Nous ne pouvons pas répondre à chaque question ouverte, mais nous la lisons. Vos questions nous fournissent des retours d'informations importantes et nous vous en remercions, tout retour d'information est apprécié**.
Configurez votre environnement
----------------------
- Soyez prêt pour une perte de données. Sauvegardez votre compte et liez votre compte à autant d'appareils que possible.
- Installez la dernière version (ou même une version bêta) de Jami. Il est inutile de signaler des bugs sur les anciennes versions.
Comment signaler un bug (dysfonctionnement)
-------------------
0. Créez un compte sur
[notre dépôt git](https://git.jami.net/users/sign_in)
(si ce n'est pas déjà fait).
1. Choisissez le bon projet dans lequel poster votre problème :
- {gitlab-project}`Le client Android <jami--client-android>`
- {gitlab-project}`Le client Qt <jami-client-qt>`
- {gitlab-project}`Le client GNOME/GTK <jami-client-gnome>`
- {gitlab-project}`Le client iOS <jami-client-ios>`
- {gitlab-project}`Le client macOS <jami-client-macos>`
- {gitlab-project}`Le projet Jami en général (ou si vous n'êtes pas
sûr) <jami-project>`
- [Si vous savez ce que vous faites, vous pouvez choisir l'un des
autres projets](https://git.jami.net)
2. Si vous avez plusieurs problèmes, veuillez remplir des rapports de bogue séparés. Il sera beaucoup plus facile de suivre les bugs de cette façon.
3. Le titre est un résumé explicite du bogue (par exemple, la barre d'en-tête est trop grande en raison de la taille de l'icône).
4. Déterminez les étapes pour reproduire le bogue :
- Si vous avez des étapes précises pour le reproduire - génial ! -vous êtes sur la bonne voie pour créer un rapport de bogue utile.
- Si vous pouvez le reproduire occasionnellement, mais pas après avoir suivi des étapes spécifiques, vous devez fournir des informations supplémentaires pour que le rapport de bogue soit utile.
- Si vous ne pouvez pas reproduire le problème, il n'est probablement pas utile de le signaler, à moins que vous ne fournissiez des informations determinantes sur son apparition.
- Si le bogue conduit à d'autres bogues par la suite que vous ne pouvez pas reproduire d'une autre manière, il n'est probablement pas utile de le signaler.
5. Assurez-vous que votre logiciel est à jour. Idéalement, testez une version en cours de développement pour voir si votre bogue a déjà été corrigé.
6. Essayez d'isoler le problème de l'environnement et de le reproduire (pour ce-faire, testez-le sur différents
appareils)
7. Décrivez votre/vos environnement(s) en précisant les éléments suivants :
- la version du système d'exploitation
- modèle précis de l'appareil (important pour les appareils mobiles)
- si vous utilisez une version bêta
- quelle version vous utilisez (de ring.cx, F-droid, Play Store, App store, votre propre version...). Si vous avez construit votre propre version de Jami, veuillez spécifier la version exacte de jamid (LibRing ou LibJami ou Daemon) et la version du client (Vous pouvez l'obtenir avec `jamid -v` et `jami-gnome -v`. Mais notez que nos paquets sont mis à jour assez souvent) et le commit Git.
- les conditions du réseau : Les deux appareils sont-ils sur le même réseau local ? Des réseaux différents ? Est-ce qu'un ou les deux sont derrière NAT ? Utilisez-vous LTE ? Wifi ?
- D'autres éléments si nécessaire : Fournisseur SIP, matériel...
Rédiger un résumé clair
-----------------------
Comment décririez-vous le bug en 10 mots environ ? C'est la
première partie de votre rapport de bogue qu'un développeur verra.
Un bon résumé doit permettre d'identifier rapidement et de manière unique un rapport de bogue. Il doit expliquer le problème, et non la solution que vous proposez.
Exemples :
```
Bon :) "L'annulation d'un transfert de fichier fait planter Jami"
Pas bon :( "Le logiciel se plante"
```
```
Bon :) "Tous les appels raccrochent après 32 secondes"
Pas bon :( "Impossible d'appeler mes amis"
```
Rédiger des étapes précises à reproduire
----------------------------------
* Comment un développeur peut-il reproduire le bogue sur son propre appareil ?
Les étapes à reproduire sont la partie la plus importante de tout rapport de bogue. Si un développeur est capable de reproduire le bogue, il est très probable que le bogue soit corrigé.
Si les étapes ne sont pas claires, il n'est même pas possible de savoir si le bogue a été corrigé. Nous sommes tout à fait conscients que certains bogues peuvent vous sembler évidents, mais ils sont probablement liés à votre environnement.
Plus vous serez précis, plus vite le bogue sera corrigé.
* Que devez-vous inclure dans un rapport de bug ?
Indiquez si vous pouvez reproduire le bogue à volonté, occasionnellement ou pas du tout. Décrivez votre méthode d'interaction avec Jami en plus de l'intention de chaque étape. Après vos étapes, décrivez précisément le résultat observé (réel) et le résultat attendu.
Séparez clairement les faits (observations) des spéculations (suppositions).
### Bon :)
Je peux toujours reproduire en suivant ces étapes :
```
1. Démarrez Jami en cliquant sur l'icône du bureau
2. Commencez une nouvelle conversation avec n'importe qui
3. Cliquez sur l'icône de transfert de fichiers
Résultats attendus : Une fenêtre s'ouvre et me demande de choisir un fichier à envoyer.
Résultats réels : Lorsque je clique sur l'icône de transfert de fichiers, rien ne se passe.
```
### Pas bon :(
```
Essayer de transférer un fichier
Cela ne fonctionne pas.
```
Résultat obtenu
---------------
Veuillez inclure :
+ Les journaux de débogage du daemon (ou LibJami ou LibRing) et du
client.
+ Le core dump s'il a été produit.
Résultat attendu
---------------
Il s'agit d'une description du comportement attendu ou souhaité.
Fournir des informations supplémentaires
--------------------------------
Les informations suivantes sont demandées pour la plupart des rapports de bogue. Vous pouvez gagner du temps en fournissant ces informations sous la rubrique Résultats attendus.
### Journaux
#### Client-qt (Windows, GNU/Linux)
Allez dans les paramètres généraux. Dans la section "Dépannage"(Déverminage, Débogage), vous pouvez cliquer sur "Ouvrir les journaux", où vous pourrez obtenir des statistiques ("Show stats") ou commencer à enregistrer des informations via "Journaux reçus". Ensuite, vous pouvez simplement copier le résultat et expliquer votre scénario.
#### Sur GNU/Linux
Journaux classiques (par défaut, seuls les journaux >= warning sont journalisés) :
```
journalctl --since "24h ago" | grep jamid
```
Journal complet :
Puisque l'interface graphique et le démon Jami sont des processus séparés, la manière la plus simple d'obtenir les journaux des deux est de les démarrer un par un, manuellement.
1. Assurez-vous qu'aucune instance du client ou du daemon Jami ne fonctionne avec `ps aux | grep ring``.
+ Jami peut être en cours d'exécution même si aucune fenêtre n'est ouverte, selon vos préférences.
+ Si un client ou un daemon est en cours d'exécution, tuez-les avec `kill PID`.
2. Sur un terminal, démarrez le démon avec `jamid -d -c`.
+ Cet exécutable n'est normalement pas dans le PATH, et sur les paquets Ubuntu, il est situé dans `/usr/lib/x86_64-linux-gnu/jamid -d -c` ou `/usr/libexec/jamid -d -c`.
3. Dans un autre terminal, démarrez le client avec (voici un exemple pour Gnome) `jami-gnome -d`.
Pour obtenir un backtrace, vous pouvez exécuter le programme dans gdb :
̀ gdb -ex run jami-gnome` ou `gdb -ex run --args /usr/lib/ring/jamid -cd`.
Lorsqu'il se plante, vous pouvez taper `bt` puis appuyer sur **Enter**. Et copiez le backtrace sur le problème. (ou `thread apply all bt`, c'est encore mieux)
#### Sur Mac OS
Naviguez jusqu'à /Applications/Jami.app/Contents/MacOS/
+ Double-cliquez sur Jami. Cela lancera Jami et imprimera le journal dans le terminal.
+ Copiez le journal du terminal vers un fichier.
#### Sur Android
+ Vous devez avoir configuré adb sur votre ordinateur.
+ Lancez Jami sur votre smartphone et exécutez ensuite
+ ``adb logcat *:D | grep `adb shell ps | egrep 'cx.ring' | cut -c10-15` > logring.txt``
+ Vous avez maintenant un fichier contenant le log du client
#### Pour Windows
Ouvrez un terminal(cmd.exe) et lancez Jami.exe avec les options suivantes :
+ `-d` pour ouvrir une fenêtre console séparée pour recevoir les logs
+ `-f` pour écrire les journaux dans `%localappdata%\jami\i.log`
+ `-c` pour imprimer les journaux directement dans la fenêtre de sortie de débogage de Visual Studio.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please to comment