User:Rominet: Difference between revisions

Most end-users will probably be interested in the procedure described below, that can be used to clone a Git repository such as [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData] using the SSH protocol and modify a single file so that future updates of the repository are done with the HTTPS protocol. To this date, this is the easiest way, as far as I know, to retrieve FGData in a secure and reliable way (probably because of (1) its sheer size as compared to the other repositories of the FlightGear project, and (2) some technical problems in the SourceForge Git infrastructure; other repositories can be cloned with HTTPS without any problem).  This procedure is explained [[#en-using-download-and-compile-sh-to-build-flightgear|in full detail in English]] and [[#alternate-method-clone-with-ssh-and-update-with-https|more summarily in French]].

* With the old <tt>git</tt> protocol, data is '''not encrypted''' and there is '''no authentication''' to guarantee that the remote computer is really the one you intended to contact. This implies in particular that malicious actors who can intercept and inject packets between your computer and the legitimate server can make you download what ''they'' want, instead of what the legitimate server would normally have sent (this is called a ''man-in-the-middle attack).'' This risk is partially mitigated in the particular case of Git, at the condition that after every update performed using the unsafe <tt>git</tt> protocol, you double-check from a known-good source that the last commit identifier you got for each branch of the downloaded repository is the same as on the legitimate server. Needless to say, nobody does that. Besides, the SHA-1 algorithm that Git uses to compute commit identifiers has been somewhat weakened during the last years<ref name="en-Google-work-on-SHA-1">See for instance this [https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html Google report].</ref>; therefore, even if it's not the case at the time of this writing, one can't dismiss the possibility that at some point in the future, “bad guys” might be able to prepare malicious commits having the same identifier as one of the commits of the legitimate repository. For these reasons (especially the possibility of a man-in-the-middle attack), it is a good idea to avoid using the obsolete <tt>git</tt> protocol. In other words, don't use <tt>git://</tt> when you clone a Git repository.

=== <span id="en-getting-started-with-download-and-compile-sh"></span> Getting started with <tt>download_and_compile.sh</tt> ===

{{Note|<tt>download_and_compile.sh</tt> is a [https://www.gnu.org/software/bash/ Bash] script written for [https://www.debian.org/ Debian]-derived distributions ([https://www.ubuntu.com/ Ubuntu], [https://devuan.org/ Devuan], [https://www.linuxmint.com/ Linux Mint], etc.). By default, in uses <tt>sudo</tt> and installs packages with <tt>apt-get</tt>. If you are not using a Debian-derived distribution, <tt>download_and_compile.sh</tt> is not for you (though inspecting [https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/download_and_compile.sh the script] at the point where it installs packages<ref name="en-note-inspecting-download-and-compile-sh-to-gather-build-dependency-information">Look for strings such as <tt>zlib1g-dev</tt>, <tt>libglew-dev</tt> or <tt>qt5-default</tt>.</ref> can be useful on other systems to find up-to-date build-dependencies of FlightGear and related software).}}

We'll first explain how to get <tt>download_and_compile.sh</tt> in a way that makes updates easy and causes the command <code>download_and_compile.sh --version</code> to work as intended (the “version” is a Git blob id such as <tt>6a5e4f05e2ccf27115eec58313be027b11266097</tt><ref name="not-on-download-and-compile-sh-version-being-a-Git-blob-id">This looks like, but is ''not'' a Git commit identifier. This kind of “version number” is admittedly not very pretty, but it doesn't pollute Git commits  (the diffs) and is automatically updated by Git every time you update <tt>download_and_compile.sh</tt> the way we are going to present; thus, the advantages compensate for the ugliness.</ref>). Then we'll show how to clone the large [https://sourceforge.net/p/flightgear/fgdata/ref/next/ FGData] repository, and finally give the last instructions to get FlightGear up and running.

==== <span id="en-getting-started-with-download-and-compile-sh-notations"></span> Notations ====

==== <span id="en-getting-download-and-compile-sh-the-right-way"></span> Getting <tt>download_and_compile.sh</tt> the “right way” ====

==== <span id="en-using-download-and-compile-sh-to-build-flightgear"></span> Using <tt>download_and_compile.sh</tt> to build FlightGear ====

==== <span id="en-using-download-and-compile-sh-to-update-flightgear"></span> Using <tt>download_and_compile.sh</tt> to update FlightGear ====

In case you don't have all required dependencies for the selected components, one of them is likely to fail, of course, since by passing <code>-pn</code> to <tt>download_and_compile.sh</tt>, you forbade it to install these dependencies for you. So, you can also very well update without passing the <code>-pn</code> option, it will simply take a little longer (the time to check if all dependencies of the selected components are available with <tt>APT</tt>). In fact, this is '''what you should do if the previous <tt>download_and_compile.sh</tt> run failed:''' first update <tt>download_and_compile.sh</tt> (see [[#en-getting-download-and-compile-sh-the-right-way|above]]) then run it ''without'' <code>-pn</code><ref name="en-passing-no-pn-option-equals-passing-py">Which is the same as passing <code>-py</code>.</ref> in case new dependencies have been recently added and you don't have them on your system yet—this would be a very likely cause for the failure.

In case this fails, first update <tt>download_and_compile.sh</tt> (see [[#en-getting-download-and-compile-sh-the-right-way|above]]), then run

* Avec le vieux protocole <tt>git</tt>, les données transférées ne sont pas chiffrées et le serveur n'est pas authentifié. Cela signifie que quelqu'un qui est « bien situé » sur le réseau peut non seulement voir ce que vous téléchargez, mais aussi qu'il peut se faire passer pour le site depuis lequel vous croyez télécharger. Le deuxième point est assez embêtant, car il signifie qu'on peut vous refiler un dépôt contenant un malware (virus, cheval de Troie, etc.). Ce risque est potentiellement limité dans le cas particulier d'un dépôt Git, à condition de vérifier le hash du dernier commit après chaque mise à jour de chaque dépôt et de le comparer à une source sûre (qui fait cela ?). Et encore, l'algorithme utilisé pour les hash des commits Git, SHA-1, a déjà été beaucoup étudié<ref name="Google-work-on-SHA-1">Voir par exemple ces [https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html travaux de Google].</ref> ; il n'est pas exclu qu'un de ces jours, on puisse fabriquer un commit foireux qui a le « bon hash », c'est-à-dire celui du dernier commit dans le dépôt officiel. Pour cette raison, il vaut mieux éviter ce protocole.