Re: [Flightgear-devel] D&C script error

[Florent R. <f.r...@fr...>]

Based on all the positive feedback, I've pushed an improved version of
these changes to 'next', plus a few more (addressing previous requests
seen here: FGData is now fetched before FlightGear and the latter built
with -DFG_DATA_DIR=..., missing dependencies added...). For details on
the main change, see:

  https://sourceforge.net/p/flightgear/fgmeta/ci/8a7fd33b2b4bf48f267c260bccf8ea638b2b8961/

Basically, download_and_compile.sh offers two new options,
--git-clone-default-proto and --git-clone-site-params, to let you choose
how to clone Git repositories. --git-clone-default-proto is for changing
the default protocol (which is still https) whereas
--git-clone-site-params is more specific, in that it allows one to give
a specific protocol, and optionally username, for all repositories
located at a given hosting site (currently, we only have GitHub and
SourceForge among the hosting sites used by download_and_compile.sh with
'git clone'). Of course, --git-clone-site-params overrides
--git-clone-default-proto for hosting sites that match, and both
override the default 'https' protocol.

Example: assuming people only have problems downloading FGData with
https, they can do, in a brand new empty directory:

  # Secure, but you need to have created a 'johndoe' account at
  # SourceForge before (see below for details)
  download_and_compile.sh --git-clone-site-params=SourceForge=ssh:johndoe DATA

or

  # Unencrypted, unauthenticated, therefore insecure unless you check
  # the obtained last-commit id (even then, as cryptographic knowledge
  # evolves, I wouldn't guarantee anything about that for years to
  # come).
  download_and_compile.sh --git-clone-default-proto=git DATA
  # This would also do the same, since DATA (FGData) is obtained from
  # SourceForge:
  download_and_compile.sh --git-clone-site-params=SourceForge=git DATA

Then, you can clone the rest using the default https protocol, or
specify it explicitly:

  download_and_compile.sh --git-clone-default-proto=https

These options only affect the 'git clone' operation. That is why the
last command here won't change the protocol used when updating your
FGData clone, that was specified above when it was cloned.

This means you don't have to reclone your repositories from scratch to
change the protocol they use: just edit .git/config under the repository
root and change stuff like:

[remote "origin"]
   # Or url = https://git.code.sf.net/p/flightgear/fgdata
   url = ssh://johndoe@git.code.sf.net/p/flightgear/fgdata

Subsequent operations such as 'git pull', 'git fetch', etc., will use
the new protocol.

In order to use SSH, you need an account at the hosting site. But at
least for SourceForge (not sure about GitHub), you don't need write
permissions in order to just pull from the repositories. Therefore, this
does solve, in my experience, the problem several people have had to
clone FGData in a secure way. Creating an account at SourceForge is
free.

That said, for each SSH-using repository, you'll be asked for the
password, unless you use ssh-agent or an equivalent. Setting up
ssh-agent is not difficult. You first need to create a keypair as
explained at:

  https://wiki.debian.org/SSH#Using_shared_keys

(and probably many, many other sites). Basically, just type:

  ssh-keygen

under your normal user account and answer the questions. You'll obtain a
(public + private) key pair:

  ~/.ssh/id_rsa.pub  (public part of the key)
  ~/.ssh/id_rsa      (private part of the key)

(there may be something else than 'rsa' depending on the default for
ssh-keygen's -t option, which you can use to force the key type, as in
'ssh-keygen -t rsa'. This is the main cryptographic algorithm used by
the key pair).

The private key is normally protected by a passphrase (password), so
that people getting access to your files without your consent (robbers,
attackers, etc.) can't use it to connect to various sites for which you
declared “this is my key and it can be used authentication”. That said,
never upload the private key to SourceForge, etc. This must stay on
*your* computer.

Using the dedicated user account interfaces at SourceForge (also GitHub
and others), you can upload your *public* key. For SourceForge, see “SSH
Key Posting” at:

  https://sourceforge.net/p/forge/documentation/SSH%20Keys/

(you may want to read the rest for background info)

Once this is done, you can connect to SourceForge with SSH in order to
clone, push or pull from/to a repo, using your key pair instead of your
SourceForge-user password. The key pair normally takes precedence,
therefore if you've correctly uploaded your public key, you should get a
prompt *for the key passphrase* (as opposed to your SourceForge account
password) when an SSH operation with SourceForge requires you to prove
that you are indeed the owner of the private key corresponding to the
pulic key you uploaded using their dedicated interface.

Now, typing the key passphrase every time it is needed may be annoying,
depending on the workflow. That is where ssh-agent comes into play. If
you simply start a process supervised by the agent, as in:

  ssh-agent bash

or

  ssh-agent zsh

then for the whole duration of the supervised process, your passphrase
will only have to be entered once for each key (yes, one may have
several SSH keys), unless expiration measures decide otherwise.

This is one of the manual ways to start the agent, but people often get
it to start automatically when they log in on their system. In my case,
I've done it long ago, that's maybe the uncommented line:

  use-ssh-agent

in /etc/X11/Xsession.options that does the job. Otherwise, I see there
is a checkbox reading “SSH Key Agent (GNOME Keyring: SSH Agent)” in
XFCE's Session and Startup -> Application Autostart tab. It's unchecked
for me, so clearly not required. And from the name, I can't tell whether
it is GNOME-specific or not. I suppose the job is done for me by the
aforementioned 'use-ssh-agent' line in /etc/X11/Xsession.options.

With this[1], you don't have to start ssh-agent manually, and
automatically get prompted when connecting to a site where one of your
SSH keys could be used for authentication. Moreover, the agent remembers
the key passphrase(s) as long as it is alive—or earlier if it is
configured to do expiration[2]—that's his job.

For completeness, GnuPG also has an agent that can theoretically act as
the SSH agent (never tried it this way, though). See also the Debian
wiki about ssh-add and ssh-agent:

  https://wiki.debian.org/SSH#ssh-agent_and_ssh-add

Regards

[1] Maybe you'll want to install ssh-askpass too or similar, for a nicer
    user experience.

[2] gpg-agent can do expiration, and also ssh-add which can be used
    inside a process supervised by ssh-agent to enter the passphrase for
    a key in advance, in order to avoid a future prompt for this key.
    See [3] for the -t (timeout) option of ssh-add.

[3] https://unix.stackexchange.com/a/122656

-- 
Florent