Usability of git-http-backend with self signed SSL certificates

Why makes it git so hard to use a self signed SSL certificate in conjunction with the https protocol?

At work we have a server for shared git repositories. For some reasons we can’t use the ssh protocoll to acces the repositories so we looked into the git-http-backend. So far so good but we want it encrypted, of course. So we used SSL with our self signed certificate:

git clone
Cloning into 'public'...
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing
fatal: HTTP request failed

Huh? Looking deeper into the problem it turns out that git uses curl for the http(s) transport and curl refuses to work with SSL certificates it cannot verify.

Ok, that’s not a bad thing. To circumvent that you can either set an environment variable (GIT_SSL_NO_VERIFY=1) to make curl ignore the verification or install the certificate on your machine. The first option is not very attractive on the long term as you’d have to do it on every operation with the remote server, the second one is not very attractive when dealing with multiple developers working on different operating systems. You’ll have to explain to them how to install the certificate on their machine, and that has to be done every time a new developer joins the team, yada, yada.

There is also an option in git (http.sslverify) you can set where you can tell git to ignore the verification of the SSL certificate for that repository. The thing is you still have to set the environment variable on the first clone and then you have to tell git to permanently ignore this issue for that repository with the configuration option — a lot of stuff to remember. Heck, looking on the interwebs I see may of the people with that problem suggesting to shut of SSL cert verification permanently by setting it globally.

I really wonder why git cannot simply tell the user that the SSL certificate cannot be verified and if you want to accept it permanently, temporarily or not. Every browser does that. Right now it just quits with an error and leaves the user with a cryptic error.

On the other side, when using git with a server providing the repositories via ssh. Git simply asks if you want to accept the key when you access the server for the first time and never bothers you again.


A few days ago I found this blog explaining how to improve the tab completion by tinkering with your .inputrc.

The magic lines are:

set show-all-if-ambiguous on
set completion-ignore-case on
set completion-map-case on

Last two lines make tab-completion ignore case, hyphens, underscores, the first one spares you one tab when more than one match was found. Very neat! I would have never found out, since there wasn’t even an .inputrc in my home directory.

Do you know any other cool .inputrc-tricks?

Can aptitude show older versions of packages if available in /var/cache/apt/archives?

Dear Lazyweb,

is it possible to tell aptitude to show older versions of a package next to the currently available one if it is still present in /var/cache/apt/archives? Like it does when you use unstable and experimental side by side? I know that aptitude does not really support downgrades of packages, but showing those packages directly in aptitude if available in the cache is a lot easier than searching them in the file system and installing them manually, especially if you don’t know where they hide.

How to get a list of manually installed packages (and remove the other ones)

The Good

Every other year or so I feel the need to clean up my Debian system and remove the installed packages I’m not interested in anymore. I remember there was a nice aptitude pattern to search for packages which I have manually installed (i.e. which were not installed to satisfy a dependency). Ideally I would then go through the (presumably short) list of packages and remove the ones I don’t need any more.

Since I always forget the aptitude pattern to search for those packages, I google for something like “list of manually installed packages” and find a solution like: aptitude search ‘~i !~M’. Although this solution is not wrong, it is not quite what I was looking for. Sure, it will find you all packages which are installed and not installed to satisfy a dependency, but it also contains packages of priorities: required, important and standard which you usually don’t want to deinstall. So the actual solution should also exclude those packages.

aptitude search '~i !~M !~pstandard !~pimportant !~prequired'

The above line will do the trick and present you a list of packages which are: installed and not dragged in to satisfy a dependency and not of priority standard, important or required.

If you where only interested in the solution of the quest of getting a list of all manually installed packages you can stop reading here.

The Bad

If you’re running your system for longer than, say, a few weeks you will probably notice that the list is very long and contains much more packages than you actually installed manually. You will probably notice a lot of libs and other packages in this list and wonder why they aren’t marked auto as they should since you didn’t install them on purpose. Unfortunately I don’t have an answer for that question. I’m using aptitude exclusively to install packages and rely on the fact that aptitude does install the dependencies automatically and more importantly: also removes them if not needed any more. But it seems like something is broken in aptitude (or somewhere else) and packages simply lose their auto status instead of being removed and thus stay on your system forever if you don’t manually clean your system.

The Ugly

To solve that issue I started aptitude and filtered the package tree with the above pattern (press l in aptitude and enter ~i !~M !~pstandard !~pimportant !~prequired). Now the package view shows only packages which are safe to remove since they are not of of priority standard or higher and manually installed by you. Now I navigate with the cursor to the list of installed packages an mark all of them as auto by pressing M. For each package in this list, aptitude will try to find an installed package which depends on that package and mark that package auto. The remaining packages which no other packages depend on, aptitude will mark for deletion. If you now press g one time, aptitude will show you which packages will be removed. I then go through that list and mark every single of the remaining packages I really want on my system with + as manually installed. After I’m done I proceed by pressing g again which will remove all remaining packages. In my case nearly 600 packages (1GB) where removed.


I assume there is a bug in aptitude or some related package which sometimes(!) removes a packages auto status instead of removing it. Unfortunately I did not find a way to reproduce that (except that it obviously does happen). If someone could find a way to reproduce that problem, one could fill a bugreport and help to get that bug fixed. Right now, a Debian system suffers (like many other operating systems) from a slow but steadily growing bloat of installed software. In my case 600 packages with 1GB accumulated over one or two years.

No sound with Gnome 3 and pulseaudio?

Dear Lazyweb,

I recently switched from KDE to Gnome 3 and I am so far very happy with the decision. One thing that bothers me since then is that the sound does not work when restarting the computer or waking it up from suspend. After a while I figured that a simple sudo killall pulseaudio fixes the problem — but only until the next reboot. Has anyone a hint what the problem could be/ I found quite a few similar problem descriptions on the internet but with no satisfying solutions so far.

Speech Recognition Software

Dear Lazyweb,

Having broke my elbow last week, I’m experiencing serious trouble typing with only one hand on the computer. I know that there is speech to text software, but I was never really interested in that — until now of course. Is there any good software available on Linux you can recommend?