Correction des guillemets français

chapters/cinema.tex

@@ -14,8 +14,8 @@ d'effectuer le rendu final de la scène sur la surface de rendu au lieu de mettr
 l'image rendue dans la file d'image à afficher puis attendre qu'elle soit
 sélectionnée.
 
-Ce module de rendu est un module de type «video\_output» s'occupant des détails
-liés à opengl, qu'on raccourcira ici pour «vout». Le code qui nous concerne sera
+Ce module de rendu est un module de type \og{}video\_output\fg{} s'occupant des détails
+liés à opengl, qu'on raccourcira ici pour \og{}vout\fg{}. Le code qui nous concerne sera
 principalement situé dans le fichier
 \texttt{modules/video\_output/opengl/vout\_helper.c}.
 

chapters/linux_file_descriptor.tex

@@ -52,7 +52,7 @@ les autres solutions apportent bien plus d'avantages.
 \subsection{Les sockets unix}
 
 Les sockets unix permettent d'envoyer des messages, soit de façon segmentée
-avec les mécanismes de «end of record», soit par l'envoi de datagrammes. Les
+avec les mécanismes de \og{}end of record\fg{}, soit par l'envoi de datagrammes. Les
 performances en tant qu'IPC sont les mêmes que les deux premières méthodes,
 mais les sockets Unix disposent d'une caractéristique unique qui correspond
 très exactement à notre problème. Ils disposent d'un moyen de transmettre des

chapters/other_android_mediacodec.tex

@@ -57,8 +57,8 @@ probablement important de noter que l'API n'indique pas qu'elle est thread-safe.
 \section{Fonctionnement d'un encodeur dans VLC}
 
 Dans VLC, l'encodeur est principalement utilisé par un seul module: le module
-«transcode». À ce jour, il utilise un flux multimédia complet en entrée,
-c'est-à-dire plusieurs «elementary streams» que sont les les sous-titres, les
+\og{}transcode\fg{}. À ce jour, il utilise un flux multimédia complet en entrée,
+c'est-à-dire plusieurs \og{}elementary streams\fg{} que sont les les sous-titres, les
 flux vidéos et les flux audios. Il produit ensuite le même flux multimédia
 encodé par un muxer.
 

chapters/other_bug_features.tex

@@ -30,7 +30,7 @@ patienter avant midi, puis ne suffisant pas je fus redirigé vers ce bogue.
 
 % TODO: use after free ou double free ?
 Après utilisation de \inltype{asan}, un outil de vérification intrusif des accès
-mémoires, il s'avérait qu'un «use-after-free» avait lieu dans le code de la
+mémoires, il s'avérait qu'un \og{}use-after-free\fg{} avait lieu dans le code de la
 playlist VLC lors de la fermeture de l'application. N'ayant jamais utilisé Asan
 auparavant, ce fut une excellente introduction à l'outil, mais ne m'a pas suffit
 à déterminer la source du problème.

chapters/sandbox_architecture.tex

@@ -13,11 +13,11 @@ Les différents éléments de ce pipeline seront créés éventuellement dans la
 zone de privilège, éventuellement dans une zone de privilège déjà existante ou
 même donnera lieu à la création d'une nouvelle zone de privilège. Pour désigner
 ce concept du côté de l'API publique de la sandbox, on crée la notion d'étage,
-ou «stages», qui permet de ne pas forcément indiquer comment sera créée la
+ou \og{}stages\fg{}, qui permet de ne pas forcément indiquer comment sera créée la
 partie du pipeline demandée par le client.
 
-L'étage représente donc une abstraction utilisée par la partie «VLC» mais
-réellement manipulée par la partie «sandbox» du processus en question.
+L'étage représente donc une abstraction utilisée par la partie \og{}VLC\fg{} mais
+réellement manipulée par la partie \og{}sandbox\fg{} du processus en question.
 
 \section{Le modèle broker}
 
@@ -58,7 +58,7 @@ orchestrateur. Celui-ci n'est plus au centre des communications inter-processus
 mais permet d'initialiser les connexions entre deux workers qui vont ensuite
 discuter directement. On doit donc s'attendre à de meilleures performances étant
 donné qu'on diminue les changements de contexte et appels systèmes. On garde cet
-«orchestrateur» pour initialiser chaque nouvel étage mais les modules peuvent
+\og{}orchestrateur\fg{} pour initialiser chaque nouvel étage mais les modules peuvent
 fonctionner indépendamment après, du moment que tous les éléments qui
 sont liés à l'étage ont été créés.
 
@@ -96,7 +96,7 @@ seconde option peut notamment apparaître lorsqu'un processus Zygote est utilis
 \section{La notion de processus Zygote}
 
 Afin d'optimiser le démarrage de nouveaux processus, beaucoup de systèmes
-utilisent un processus spécial, appelé «Zygote». Ce processus est responsable de
+utilisent un processus spécial, appelé \og{}Zygote\fg{}. Ce processus est responsable de
 créer les nouveaux processus et permet un démarrage plus rapide en
 préchargeant toutes les bibliothèques et préparant toutes les initialisations
 au préalable.

chapters/sandbox_memory_blocks.tex

@@ -36,7 +36,7 @@ d'envoi de message.
 Deux solutions sont alors envisagées. La première est de créer des blocs de
 mémoire sous forme de jetons d'accès dès lors qu'il y a création d'un nouveau
 bloc. Ces blocs peuvent donc être passés de façon indépendante, idéalement avec
-un paradigme «fire\&forget» qui fera le transfert de l'appartenance du bloc d'un
+un paradigme \og{}fire\&forget\fg{} qui fera le transfert de l'appartenance du bloc d'un
 processus à l'autre. Avec cette méthode, il suffit de modifier les fonctions
 comme \inltype{block_Alloc}, presque aucune synchronisation supplémentaire n'est
 requise.

chapters/sandbox_pattern_libvlccore.tex

@@ -58,7 +58,7 @@ situation suivante.
 Les paragraphes précédents décrivent la création d'un décodeur depuis le
 processus de l'input, mais on voit au graphe précédent qu'il faut également
 pouvoir faire un proxy de l'input dans le processus du décodeur, c'est-à-dire
-pouvoir «transmettre» l'input d'un processus à l'autre. Nous allons donc
+pouvoir \og{}transmettre\fg{} l'input d'un processus à l'autre. Nous allons donc
 reprendre le concept de jeton d'accès et permettre l'envoi d'objet proxy à
 travers une IPC.\@ Il faut alors détailler ces objets proxies du point de vue de
 l'envoi de message.
@@ -87,7 +87,7 @@ typedef void (*vlc_rpc_proxy_cb)(vlc_rpc_proxy_t *p_proxy,
                                  vlc_process_msg_t *p_msg);
 \end{code}
 
-Comme ces objets seront «transmis», il faut alors seulement définir des méthodes
+Comme ces objets seront \og{}transmis\fg{}, il faut alors seulement définir des méthodes
 pour créer un \inltype{vlc_rpc_proxy_t} depuis un objet existant, et créer un
 objet proxy à partir d'un \inltype{vlc_rpc_proxy_t}.
 

chapters/sandbox_pattern_modules.tex

@@ -23,7 +23,7 @@ l'application mais moins efficace.
 
 \section{Implémentation}
 
-La partie «injection» consiste à complètement rediriger \inltype{module_need}
+La partie \og{}injection\fg{} consiste à complètement rediriger \inltype{module_need}
 vers le cœur de la sandbox pour transformer les requêtes de module vers des
 modules proxies. Le nom du module ou de la classe de module peut correspondre à
 une politique et permet ainsi de décider très finement et automatiquement quel

chapters/torrent.tex

@@ -51,14 +51,14 @@ partagé. L'implémentation utilise un pointeur avec comptage de référence sur
 le pointeur fournit une interface thread-safe.
 
 L'intégration dans le module se fait par la classe déjà existante
-\inltype{i11e_promise}, pour «promesse interruptible», qui permet de définir les
+\inltype{i11e_promise}, pour \og{}promesse interruptible\fg{}, qui permet de définir les
 attentes des promesses comme un point d'annulation possible pour le thread.
 
 \subsection{Correction des problèmes de compilation de libtorrent}
 
 La seconde partie du travail a consisté à faire compiler libtorrent sur les
 autres plateformes que Linux. J'ai pour cela ouvert des tickets et proposé des
-«pull request», principalement pour le système de build. J'ai aussi intégré des
+\og{}pull request\fg{}, principalement pour le système de build. J'ai aussi intégré des
 patch temporaires rajoutant une implémentation des threads pour winpthread. Cela
 semble rentrer en conflit avec le travail effectué précédemment, mais cette
 initiative est seulement cloisonnée à la dépendance et ne déborde pas sur VLC.
@@ -70,16 +70,16 @@ s'accorde plus facilement avec cet esprit.
 % TODO: ajouter références vers les pull requests
 Sur les cinq pull requests proposées, quatre ont été acceptées et intégrées:
 \begin{itemize}
-    \item «dynamically load getauxval so as to support older android devices»
+    \item \og{}dynamically load getauxval so as to support older android devices\fg{}
     \#2830: utilise \inltype{dlsym} pour charger dynamiquement
     \inltype{getauxval} et éviter la situation où la bibliothèque ne compile pas
     quand \inltype{sys/auxv.h} n'est pas disponible.
-    \item « Add missing define for old android sdk» \#2831 corrige des erreurs
+    \item \og{} Add missing define for old android sdk\fg{} \#2831 corrige des erreurs
     de compilation avec netlink lorsque certaines constantes ne sont pas
     définies.
-    \item «fix if defined TORRENT\_ANDROID» \#2836 définit la constante
+    \item \og{}fix if defined TORRENT\_ANDROID\fg{} \#2836 définit la constante
     \inltype{TORRENT_ANDROID} pour faire fonctionner la pull request précédente.
-    \item «add windows socket libraries in Makefile.am» \#2834 corrige la
+    \item \og{}add windows socket libraries in Makefile.am\fg{} \#2834 corrige la
     configuration autotools du projet qui n'était pas à jour avec les autres
     scripts de construction.
 \end{itemize}
@@ -128,7 +128,7 @@ pour utiliser webtorrent dans le module torrent.
 
 La stratégie fut sans surprise de procéder à l'intégration dans Libtorrent du
 support de Webtorrent. Malheureusement ce dernier n'est pas encore standardisé
-dans une BEP, ou «BitTorrent Enhancement Proposal» comme décrit dans la BEP 001.
+dans une BEP, ou \og{}BitTorrent Enhancement Proposal\fg{} comme décrit dans la BEP 001.
 L'extension au protocole n'est donc pas encore terminée ni acceptée et seule une
 implémentation de référence en nodeJS est disponible.
 

chapters/vlc_explanations.tex

@@ -37,7 +37,7 @@ manière indépendante et correctement synchroniser le temps. Le décodeur et la
 sortie vidéo fonctionnent ainsi de manière asynchrone. L'idée centrale est
 qu'avoir plusieurs entrées en lecture et plusieurs sorties simultanément ne doit
 pas être impossible. Une démonstration de cette fonction a d'ailleurs été mis en
-place en tant que «VLM», qui permet de contrôler plusieurs flux en entrées et de
+place en tant que \og{}VLM\fg{}, qui permet de contrôler plusieurs flux en entrées et de
 choisir comment les utiliser en sortie; que ce soit en les diffusant, en créant
 une mosaïque ou en affichant des flux dans de nouvelles sorties.
 

chapters/vlc_introduction.tex

@@ -19,7 +19,7 @@ des points d'intérets pour l'implémentation de la sandbox.
 En troisème partie, je mettrai en avant mes recherches et les mécanismes que
 j'ai mis en place pour intégrer incrémentalement une architecture
 multi-processus au sein de VLC. La finalité de l'intégration de cette
-architecture est d'apporter du «sandboxing» dans libvlc. Il s'agissait de la
+architecture est d'apporter du \og{}sandboxing\fg{} dans libvlc. Il s'agissait de la
 mission centrale de mon stage donc une grande attention sera portée à détailler
 le contexte, les problématiques à résoudre lors de son intégration, les
 difficultés rencontrées et les points à améliorer, de façon à offrir une trace

chapters/what_is_sandboxing.tex

@@ -75,21 +75,21 @@ Parmi ce qu'on a appelé permissions et accès, on va en particulier retrouver:
     \item La permission de créer des processus.
 \end{itemize}
 
-On va désigner par «accès» le fait de pouvoir effectuer des actions de lecture
+On va désigner par \og{}accès\fg{} le fait de pouvoir effectuer des actions de lecture
 et écriture sur la ressource.
 
-On va désigner par «permissions» le fait que l'accès à une ressource soit donné
+On va désigner par \og{}permissions\fg{} le fait que l'accès à une ressource soit donné
 selon une autorité ambiante, c'est-à-dire typiquement implicite dans
 le processus. Cela signifie généralement que l'ouverture de la ressource est
 soumise à un test des permissions.
 
-Enfin, on va désigner par «jeton d'accès» une ressource représentée sous la
+Enfin, on va désigner par \og{}jeton d'accès\fg{} une ressource représentée sous la
 forme d'un objet et dont l'accès peut être transmis par le biais de ce jeton,
 sans pour autant que ce jeton soit forgeable.
 
-Les jetons d'accès, ou plus couramment «capabilities», constituent l'une des
+Les jetons d'accès, ou plus couramment \og{}capabilities\fg{}, constituent l'une des
 meilleures méthodes de description des accès et évitent des problématiques comme
-le «confused deputy problem» \cite{ConfusedDeputy} dans la littérature. La
+le \og{}confused deputy problem\fg{} \cite{ConfusedDeputy} dans la littérature. La
 comparaison entre l'implémentation Linux et les tentatives d'implémentation sous
 Windows vont révéler ceci dans la suite, Linux permettant bien plus facilement
 de construire ces jetons. Nous tenterons tout particulièrement de concevoir

chapters/why_sandboxing.tex

@@ -35,16 +35,16 @@ mettre une attention particulière à la vérification des mesures mises en plac
 Si les objectifs et besoins décrits au dessus paraissemt trop théorique, il est
 possible de prendre des exemples de la vraie vie pour se convaincre d'avoir
 besoin de ces mesures. L'exemple le plus connu de sandbox intrusive est celle
-de Chromium, qui s'appelle lui-même «The Most Secure Browser.» Le développement
+de Chromium, qui s'appelle lui-même \og{}The Most Secure Browser.\fg{} Le développement
 de Chromium est basé depuis ses commencements sur un modèle de sandbox.
 L'application a donc dès le départ été écrite avec l'isolation des modules en
 tête. Plusieurs exemples d'attaques ont été montrées.
 
 Un exemple est celle de Jordan Rabet, présenté dans sa conférence à la BlueHat
 IL\cite{JRabetBrowserSecurity}.
-Il utilise notamment des techniques de fuzzing pour trouver «facilement» un
+Il utilise notamment des techniques de fuzzing pour trouver \og{}facilement\fg{} un
 déréférencement de pointeur invalide \footnote{dans l'optimisation Just-In-Time
-du moteur javascript} dans un des processus «renderer» de Chromium. Les
+du moteur javascript} dans un des processus \og{}renderer\fg{} de Chromium. Les
 renderers étant plus ou moins confinés à l'onglet, l'attaque est confinée au
 contenu même qui lui permet d'exister et n'apporte donc plus de valeur ajoutée.
 

chapters/windows_eventloop.tex

@@ -89,7 +89,7 @@ faut donc parcourir à nouveau le tableau pour trouver les autres
 \subsection{Overlapped IO}
 
 Windows fournit ensuite un mécanisme bas niveau pour mettre les opérations d'IO
-en «tâche de fond»
+en \og{}tâche de fond\fg{}
 \footnote{\url{https://docs.microsoft.com/en-us/windows/desktop/sync/synchronization-and-overlapped-input-and-output}}.
 Ci-dessous, on voit l'argument \inltype{lpOverlapped} dans les prototypes des
 fonctions de lecture
@@ -131,7 +131,7 @@ fournit ainsi un moyen de passer d'un modèle par disponibilité à un modèle p
 complétion.
 
 Il est possible d'étendre encore le modèle asynchrone en utilisant des
-«completion routines». Il faut alors utiliser la version \inltype{ReadFileEx}
+\og{}completion routines\fg{}. Il faut alors utiliser la version \inltype{ReadFileEx}
 \footnote{\url{https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-readfileex}}
 pour la lecture.
 

chapters/windows_ipc.tex

@@ -13,7 +13,7 @@ place une architecture similaire.
 
 Windows dispose de beaucoup de moyens de communication inter-processus. Parmi
 ceux là, aucun ne va avoir les mêmes propriétés que les sockets Unix. Nous
-allons même de base éliminer tous les moyens «haut niveau» comme les ports COM
+allons même de base éliminer tous les moyens \og{}haut niveau\fg{} comme les ports COM
 résolvant plutôt des problèmes d'interopérabilité et se concentrer sur les
 moyens plus bas niveau.
 
@@ -22,7 +22,7 @@ moyens plus bas niveau.
 Les sockets Windows réimplémentent la même interface que les sockets Berkeley
 mais ne fournissent pas de sockets locaux ou anonymes.  Ceux-ci passent par la
 pile réseau pour l'envoi de message. On notera cependant l'implémentation de
-«TCP Loopback Fast Path» depuis Windows Server 2012. Cette fonctionnalité
+\og{}TCP Loopback Fast Path\fg{} depuis Windows Server 2012. Cette fonctionnalité
 conserve la sémantique du protocole TCP tout en désactivant des fonctionnalités
 comme l'algorithme de Nagle. \cite{WindowsFastTCPLoopback}
 C'est donc ce qui ressemble le plus aux sockets Unix, excepté l'accès au réseau