377
edits
User:Rominet: Difference between revisions
Jump to navigation
Jump to search
m
Missing word
(→Using download_and_compile.sh to build FlightGear: Add paragraph about creation of a SourceForge account) |
m (Missing word) |
||
| Line 14: | Line 14: | ||
Pros and cons of each of these protocols: | Pros and cons of each of these protocols: | ||
* 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” 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. | * 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. | ||
* With the <tt>https</tt> protocol, all transferred data is '''encrypted''' and, more importantly here, the server you connect to is '''authenticated.''' The main problem here is that this protocol is not well implemented at [https://sourceforge.net/ SourceForge]: cloning a large repository such as [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData] using <tt>https</tt> (almost?) always fails. As far as I know, this problem doesn't happen with smaller repositories, nor does it happen when simply updating a large one that has already been cloned (it is indeed possible to clone a repository with a given protocol and later update it using another protocol; all one has to do for that is to modify the <tt>.git/config</tt> file inside the repository—this is precisely the method we are going to describe next, step by step). | * With the <tt>https</tt> protocol, all transferred data is '''encrypted''' and, more importantly here, the server you connect to is '''authenticated.''' The main problem here is that this protocol is not well implemented at [https://sourceforge.net/ SourceForge]: cloning a large repository such as [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/ FGData] using <tt>https</tt> (almost?) always fails. As far as I know, this problem doesn't happen with smaller repositories, nor does it happen when simply updating a large one that has already been cloned (it is indeed possible to clone a repository with a given protocol and later update it using another protocol; all one has to do for that is to modify the <tt>.git/config</tt> file inside the repository—this is precisely the method we are going to describe next, step by step). | ||
* With the <tt>ssh</tt> protocol, all transferred data is '''encrypted''' and the server you connect to is '''authenticated''' (this is done differently, but offers similar guarantees as the <tt>https</tt> protocol). The main problem in this case, which is generally a minor one, is that in order to download via the <tt>ssh</tt> protocol, you have to authenticate ''yourself'' to the server (in contrast with <tt>https</tt>, which allows anonymous downloads). This requires you to either enter a password or to use a (public, private) pair of SSH keys—the latter method being called ''public key authentication.'' On the other hand, getting yourself authenticated to the server is an advantage for development, because this allows server administrators to possibly grant you write access to the repository, should you be able and willing to contribute to the project (i.e., administrators could then allow you to run commands such as <code>git push</code> that update the remote repository). | * With the <tt>ssh</tt> protocol, all transferred data is '''encrypted''' and the server you connect to is '''authenticated''' (this is done differently, but offers similar guarantees as the <tt>https</tt> protocol). The main problem in this case, which is generally a minor one, is that in order to download via the <tt>ssh</tt> protocol, you have to authenticate ''yourself'' to the server (in contrast with <tt>https</tt>, which allows anonymous downloads). This requires you to either enter a password or to use a (public, private) pair of SSH keys—the latter method being called ''public key authentication.'' On the other hand, getting yourself authenticated to the server is an advantage for development, because this allows server administrators to possibly grant you write access to the repository, should you be able and willing to contribute to the project (i.e., administrators could then allow you to run commands such as <code>git push</code> that update the remote repository). | ||