Replicant

Hola Replicant Lamas!

Same same. A quick nmap tells us that git "is there" but it's in a "closed" state:

----
$ nmap git.replicant.us
...
Starting Nmap 6.40 ( http://nmap.org ) at 2016-01-11 11:37 EET
Nmap scan report for git.replicant.us (18.4.89.63)
Host is up (0.16s latency).
...
PORT STATE SERVICE
9418/tcp closed git
...
----

Thanks for helping us be free! ;-D

You can clone over https:
repo init -u https://git.replicant.us/replicant/manifest.git -b replicant-4.2
and then the usual repo sync
See the updated wiki: ReplicantSourceCode
It's safer anyway because the git protocol provides no authentication mechanism.

No better with https:
ran@ubuntu:~/a$ repo init u https://git.replicant.us/replicant/manifest.git -b replicant-4.2
Get https://git.replicant.us/replicant/manifest.git
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 -:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
fatal: unable to access 'https://git.replicant.us/replicant/manifest.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
fatal: unable to access 'https://git.replicant.us/replicant/manifest.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
fatal: cannot obtain manifest https://git.replicant.us/replicant/manifest.git

Hola Wolfgang and Alexandre && Thanks for your fast replies!

I ran into the same problem as Alexandre...

Host "replicant.us" seem to be using "http://www.CAcert.org" as it's
CA provider, that's free and good BUT their cert is not trusted "out
of the box" which leads to this problem from what I can tell.

(So all users must manually add the CACert root CA or somehow add that
k "skip verification" switch to their call-chain which just happens
to removes the whole point of SSL ;).

I had similar problems some time ago and after some different CA
endeavors I ended up using:

• https://letsencrypt.org/

Their free and pretty open solution has worked nicely!

Having successfully setup the letsencrypt magic on site-x it should be
"trusted" on most systems out-of-the-box (Meaning, their root CA is
included on most systems == hence you should get the "trusted
lock-sign" without doing anything and this problem should go away).

I recommend trying it out. Oh yeah, this naturally only works if you
are the admin/root of this box and not FSF... ;-)

The only "downside" that I have thus far found about letsencrypt is
the short:ish expire amount, BUT that's fixed by simply re-running
their script which does all the "renew cert" work on your behalf...

You can't have everything (TM).

Greetings from a snowy southern Finland,
Kristoffer.

Hola Again!

FYI, I think I got things working via simply manually installing CAcert's ROOT and CLASS3 certs to my SSL setup.

That is, my command:

    $ repo sync -j 6

seems to work (well, I get normal git + curl output at least). But now I get this curl error:

    ...
    curl: (35) error:0200100D:system library:fopen:Permission denied
    ...

after each "Retrying clone after deleting...". Hopefully almost harmless (I seem to need to do "repo sync --force-sync" on some repos, oh well).

Anyways, here's my mini workaround. YMMV!

MANUAL CACERT SSL INSTALLATION (Debian/Ubuntu)

• install cacert's (1) ROOT and (2) CLASS3 certs to SSL (to keep the
  repo chain happy etc...)

As root do:

(1) root-ca:

 # wget http://www.cacert.org/certs/root.crt
 # FILE=cacert-root.crt
 # cp root.crt $FILE 
 # chmod 0640 $FILE
 # cp $FILE /etc/ssl/certs/
 # cd /etc/ssl/certs/
 # openssl x509 -noout -fingerprint -in $FILE   # NOTE! compare SHA1 against http://www.cacert.org/index.php?id=3 SHA1 string....
 # openssl x509 -noout -hash -in $FILE          # upcoming file-hash...
 # ln -sf $FILE $(openssl x509 -hash -noout -in $FILE).0
 # ls -al|grep $FILE
 lrwxrwxrwx 1 root     root         15 Jan 12 12:31 99d0fa06.0 -> cacert-root.crt
 -rw-r----- 1 root     root       2569 Jan 12 12:29 cacert-root.crt
 # cat $FILE >> /etc/ssl/certs/ca-certificates.crt

(2) class3-ca:

 # wget http://www.cacert.org/certs/class3.crt
 # FILE=cacert-class3.crt
 # cp class3.crt $FILE
 # chmod 0640 $FILE
 # cp $FILE /etc/ssl/certs/
 # cd /etc/ssl/certs/
 # openssl x509 -noout -fingerprint -in $FILE  # NOTE! same as above, compare SHA1 str's!
 # openssl x509 -noout -hash -in $FILE
 # ln -sf $FILE $(openssl x509 -hash -noout -in $FILE).0
 # ls -al|grep $FILE
 lrwxrwxrwx 1 root     root         17 Jan 12 12:43 590d426f.0 -> cacert-class3.crt
 -rw-r----- 1 root     root       2610 Jan 12 12:42 cacert-class3.crt
 # cat $FILE >> /etc/ssl/certs/ca-certificates.crt

Mini Verification:

 # openssl s_client -connect replicant.us:443 -CApath /etc/ssl/certs/ 
 ...
     Verify return code: 0 (ok)
                         ^^^^^^

Lastly, run your repo command and cross your fingers...

If you're on Debian Jessie and have the backports repository enabled, it is nothing more than installing one package: https://packages.debian.org/jessie-backports/ca-cacert

Hola Wolfgang!

Gotcha. Some of this info might be good to place under the ReplicantSourceCode page.

Anyways, unless I'm missing something the main problem still stands, people need to do
extra work to get things working... (meaning, the https:// solution does not work out-
of-the-box).

Keep up your good work,
Kristoffer.

Gotcha. Some of this info might be good to place under the ReplicantSourceCode page.

Anyways, unless I'm missing something the main problem still stands, people need to do
extra work to get things working... (meaning, the https:// solution does not work out-
of-the-box).

Absolutely! And thanks for providing the general instructions! This will definitely help others.

I cannot say anything about letsencrypt because I did not yet have the time to try it out on my servers. The comparably short expiration time might be an issue. Let's see how Paul decides on this.

Hola Wolfgang!

Regarding Letsencrypt's short expiration time I don't see that as much
of a problem anymore.

Yes it's something "a bit extra" that you need to remember (compared
to commercial/other free CA's) BUT that's easily fixed by putting some
Action-Point to your calendar which says something like

• Renew our Letsencrypt cert via running their script (see Your-ssl-renew-mini-HOWTO).

The work just takes a couple of minutes and your done.

I just re-verified that running their "get-me-a-SSL-cert" script
again will do the needful and push the expiration date forward in
time (+ 1 month?)

And remember, you don't need to wait 5 minutes before things go BOOM
to do this, you can do this anytime ;-)

My old/previous run of their script gave me this SSL expiration date:

    Expires date: 1.3.2016

and after just re-running their python-script like so:

    # ./letsencrypt-auto --apache --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview

and answering some ncurse-like (CLI) questions, the script pushed the
expires date forward to:

    Expires date: 14.4.2016

I can live with that (meaning, it's ok for my devel host usage).

It would be even nicer if their script would just shut up and work in
batch-mode (non-interactive). Then one could simple create a monthly
cronjob and be done with it.

Who knows, perhaps even that is possible in the future (or already
now? ;-) I'm to lazy to check ;-D

Kind regards,
Kristoffer.

A workaround, if you're ok with trusting the URL, is setting GIT_SSL_NO_VERIFY=1 in the environment, like:
GIT_SSL_NO_VERIFY=1 git clone https://git.replicant.us/replicant/sdk.git

Note that using http would not work as the server redirects to https anyway.

I tkink some update on the pages linked into http://redmine.replicant.us/projects/replicant/wiki#Replicant-build should help users.

1. NOTE! compare SHA1 against http://www.cacert.org/index.php?id=3 SHA1 string....

If I understand what you mean, it does not seem to match:

sudo sha1sum -t  $FILE
506fb5538523119fdeddb269bdaa355b1c12a58f  cacert-root.crt

Could you detail the procedure for checking please?

Waiting for the a secured way to use git, here is a page to get CAcert certificate manually on debian: https://www.brightbox.com/blog/2014/03/04/add-cacert-ubuntu-debian/