git pull fails with OpenSSL version mismatch error

[Joel Roth]

Greetings

$ git pull
OpenSSL version mismatch. Built against 1000005f, you have 1000103f
fatal: The remote end hung up unexpectedly

I encounter this problem (with identical diagnostic text)
with two separate repositories, github and gitorious

Is this likely to be Debian?
I see a similar bug appeared in openssh-server
http://lists.debian.org/debian-ssh/2012/06/msg00027.html

Thanks for any suggestions,

Joel

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20121218045632.GA5785@sprite

[berenge...@neutralite.org]

I am using happily github and bitbucket without any problem since some
months now, with Debian testing. So if you are not using testing, maybe
you could try to upgrade only git, ssh and their stuff related to
network to testing version, one by one. (look for apt-pinning on your
favorite debian faq/wiki, it should answer all your questions better
like your friend google :P).

Archive: http://lists.debian.org/d5a742a617352223...@neutralite.org

[Joel Roth]

On Tue, Dec 18, 2012 at 10:21:45AM +0100, berenge...@neutralite.org wrote:
> I am using happily github and bitbucket without any problem since
> some months now, with Debian testing. So if you are not using
> testing, maybe you could try to upgrade only git, ssh and their
> stuff related to network to testing version, one by one. (look for
> apt-pinning on your favorite debian faq/wiki, it should answer all
> your questions better like your friend google :P).

Ah, well, actually I am using unstable....

Thanks,

Joel

> Le 18.12.2012 05:56, Joel Roth a écrit :
> >Greetings
> >
> >$ git pull
> >OpenSSL version mismatch. Built against 1000005f, you have 1000103f
> >fatal: The remote end hung up unexpectedly
> >
> >I encounter this problem (with identical diagnostic text)
> >with two separate repositories, github and gitorious
> >
> >Is this likely to be Debian?
> >I see a similar bug appeared in openssh-server
> >http://lists.debian.org/debian-ssh/2012/06/msg00027.html
> >
> >Thanks for any suggestions,
> >
> >Joel
> >
> >--
> >Joel Roth
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/d5a742a617352223...@neutralite.org
>

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121218100010.GA9777@sprite

[Joel Roth]

On Mon, Dec 17, 2012 at 06:56:32PM -1000, Joel Roth wrote:
> Greetings
>
> $ git pull
> OpenSSL version mismatch. Built against 1000005f, you have 1000103f
> fatal: The remote end hung up unexpectedly

This error also occurs when I use ssh directly, to any
host.

> I encounter this problem (with identical diagnostic text)
> with two separate repositories, github and gitorious
>
> Is this likely to be Debian?
> I see a similar bug appeared in openssh-server
> http://lists.debian.org/debian-ssh/2012/06/msg00027.html
>
> Thanks for any suggestions,
>
> Joel
>
> --
> Joel Roth
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: http://lists.debian.org/20121218045632.GA5785@sprite
>

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121218174012.GA11422@sprite

[berenge...@neutralite.org]

Le 18.12.2012 18:40, Joel Roth a écrit :
> On Mon, Dec 17, 2012 at 06:56:32PM -1000, Joel Roth wrote:
>> Greetings
>>
>> $ git pull
>> OpenSSL version mismatch. Built against 1000005f, you have 1000103f
>> fatal: The remote end hung up unexpectedly
>
> This error also occurs when I use ssh directly, to any
> host.

Did you modify something in your ssh configuration? If yes, maybe try
to remove the conf file and reconfigure everything.
I really have no idea about what is the problem, ssh is just a tool I
use, I am not an expert in it. But at least, if you are having such
trouble even when trying to use raw ssh, you know that's not git...

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/3df103201bb3bab2...@neutralite.org

[Bob Proulx]

Joel Roth wrote:

> Joel Roth wrote:
> > $ git pull
> > OpenSSL version mismatch. Built against 1000005f, you have 1000103f
> > fatal: The remote end hung up unexpectedly
>
> This error also occurs when I use ssh directly, to any
> host.

This reads to me that you have not updated your system, specifically
the openssl libraries.

# apt-get update
# apt-get ugprade

> Ah, well, actually I am using unstable...

Be careful out there! :-)

On Sid I have:

openssh-client 1:6.0p1-3
Depends: ... libssl1.0.0 (>= 1.0.1) ...

Make sure that at the least both of those are up to date.

$ apt-cache policy openssh-client libssl1.0.0

You might also need others too but I think you must be behind on
updates to those.

Bob

[Joel Roth]

Thanks for this suggestion. Your intuition was right!

I just needed to update openssh-client and openssh-server.

I'm just so used to the dependencies being taken
care of by APT, that I was surprised to have to
lift my little pinkie.

Regards

Joel


> Bob

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121219095451.GA24518@sprite

[Bob Proulx]

Joel Roth wrote:

> Bob Proulx wrote:
> > On Sid I have:
> > openssh-client 1:6.0p1-3
> > Depends: ... libssl1.0.0 (>= 1.0.1) ...
> > Make sure that at the least both of those are up to date.
>

> Thanks for this suggestion. Your intuition was right!
>
> I just needed to update openssh-client and openssh-server.
>
> I'm just so used to the dependencies being taken
> care of by APT, that I was surprised to have to
> lift my little pinkie.

Uhm... An 'apt-get upgrade' should have offered those for upgrade.
They do for me. They didn't for you? Perhaps you have pinning or
other preventatives in place? Please say more!

Bob

[Joel Roth]

Ah, I didn't even think to try an apt-get upgrade.
I usually just upgrade apps individually as I need to...
an attitude based on (possibly) outdated fears of
getting stuck in between upgrades of C libraries
or other large-scale brokenness.

'apt-get upgrade' is a good first prophylactic, and this is one
example.

Thanks for your comment. This list/community is a great support.

Happy holidays and best wishes.

Joel

> Bob



--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121224061519.GA22892@sprite

[Andrei POPESCU]

On Du, 23 dec 12, 20:15:19, Joel Roth wrote:
>
> Ah, I didn't even think to try an apt-get upgrade.
> I usually just upgrade apps individually as I need to...
> an attitude based on (possibly) outdated fears of
> getting stuck in between upgrades of C libraries
> or other large-scale brokenness.

IMVHO your method is less safer than 'apt-get upgrade' or
'aptitude safe-upgrade'.

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

[Osamu Aoki]

On Mon, Dec 24, 2012 at 10:48:00AM +0200, Andrei POPESCU wrote:
> On Du, 23 dec 12, 20:15:19, Joel Roth wrote:
> >
> > Ah, I didn't even think to try an apt-get upgrade.
> > I usually just upgrade apps individually as I need to...
> > an attitude based on (possibly) outdated fears of
> > getting stuck in between upgrades of C libraries
> > or other large-scale brokenness.
>
> IMVHO your method is less safer than 'apt-get upgrade' or
> 'aptitude safe-upgrade'.

I can not agree with you more. But there seem to exist some myth on
this feeling of safe upgrade using partial upgrade.

With symbols file in the package, we as Debian seem to care library
compatibility issues when transitioning package from unstable to
testing. But this manual method does not check such thing.

If anyone have suggestion to improve debian-reference to prevent people
to take such strategy, let me know. Also, concrete case example of why
such method is less safer than 'apt-get upgrade' or 'aptitude
safe-upgrade', let us know.

Osamu

--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/2012122414...@goofy.localdomain

[Bob Proulx]

Joel Roth wrote:
> Bob Proulx wrote:

> > Joel Roth wrote:
> > > I'm just so used to the dependencies being taken
> > > care of by APT, that I was surprised to have to
> > > lift my little pinkie.
> >
> > Uhm... An 'apt-get upgrade' should have offered those for upgrade.
> > They do for me. They didn't for you? Perhaps you have pinning or
> > other preventatives in place? Please say more!
>
> Ah, I didn't even think to try an apt-get upgrade.

!!?? Shock! Surprise! It is the *first* thing I think of to try to
fix something.

> I usually just upgrade apps individually as I need to...

As in 'apt-get install openssh-client' ? But that won't upgrade any
of the dependencies.

> an attitude based on (possibly) outdated fears of
> getting stuck in between upgrades of C libraries
> or other large-scale brokenness.

As others commented (but I wanted to directly address this) you
shouldn't have this worry like this. And actually not getting
upgrades in a timely manor is a worse problem.

On Sid/Unstable I upgrade daily with:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

The first sync's the Packages files, the index of what is current.
Then the 'upgrade' is a very restricted upgrade that only upgrades
packages in place. It cannot pull in any new packages such as when a
package is split or when a package gains new dependencies. But most
important it cannot remove packages.

Then 'dist-upgrade' and I look at the screen for dist-upgrade very
carefully. I cannot stress this enough. Look at that very carefully.
Most important is to check to see if any packages are going to be
removed. If a bind9 update wants to install new liblwres80 that is
okay. But if a netcf upgrade wants to remove kvm (Bug#694362 for
example) then do not do it!

Examine the problem and apply "hold" to dpkg as needed to whatever
packages are appropriate 'apt-mark hold pkg' is a convenient frontend
to 'echo pkg hold | dpkg --set-selections'. After holding try the
dist-upgrade again. Repeat as needed until the result is
satisfactory. If this is needed then file a bug report.

I do this every day. Because the changes from one day to the next day
are small enough that I can work through them and recognize them as
they occur. If I were to wait six months then the amount of thrash in
Sid/Unstable would make recognizing and reducing these problems much
more difficult.

Also a Sid/Unstable upgrade that was from a year ago to today may need
special handling that was already taken care of in other ways. In a
day to day transition everything will be current and rolling. But
after a long time people forget and the upgrade may be broken in ways
that don't matter to anyone else and therefore will never get fixed.
Remember that only major release points such as Squeeze and Wheezy are
extensively tested across long times and large changes. Major
releases will work, within the documented procedures from the upgrade
notes. But what amounts to a similar major upgrade between Sid-2011
and Sid-2012 won't be tested at all. You are on your own.

> an attitude based on (possibly) outdated fears of
> getting stuck in between upgrades of C libraries
> or other large-scale brokenness.

In summary if running Sid/Unstable or Testing too then I think it is
best to keep current and not let the parts get too old and stale. It
is just easier that way. "In for a penny, in for a pound."

> Thanks for your comment. This list/community is a great support.

It seriously is one of the best things!

Bob

[Bob Proulx]

Osamu Aoki wrote:
> If anyone have suggestion to improve debian-reference to prevent
> people to take such strategy, let me know. Also, concrete case
> example of why such method is less safer than 'apt-get upgrade' or
> 'aptitude safe-upgrade', let us know.

I think this case is one example. By selectively upgrading only the
ssh program binary and not the dependent libraries the openssl libssl
library was allowed to become stale. It was almost certainly behind
on security upgrades as I remember there have been DSAs filed against
it relatively recently. It was almost certainly vulnerable to
DSA-2392-1, DSA-2454-2, or DSA-2475-1 for example.

Bob

[Joel Roth]

Bob Proulx wrote:
> Joel Roth wrote:
> > Bob Proulx wrote:
> > > Joel Roth wrote:
> > > > I'm just so used to the dependencies being taken
> > > > care of by APT, that I was surprised to have to
> > > > lift my little pinkie.
> > >
> > > Uhm... An 'apt-get upgrade' should have offered those for upgrade.
> > > They do for me. They didn't for you? Perhaps you have pinning or
> > > other preventatives in place? Please say more!
> >
> > Ah, I didn't even think to try an apt-get upgrade.
>
> !!?? Shock! Surprise! It is the *first* thing I think of to try to
> fix something.

Well, it's a credit to Debian and software in general that I've
coasted along.

> > I usually just upgrade apps individually as I need to...
>
> As in 'apt-get install openssh-client' ? But that won't upgrade any
> of the dependencies.

I didn't know that. My first try was apt-get install ssh.

Hmmm, and we don't have apt-get --update-dependencies install ssh,

I see that I'm 1,680 packages behind...

The resolution of more complicated dependency issues, has
improved a lot, in my subjective opinion. Let's see how my
current upgrade goes....

Some 1300 were packaged installed by 'upgrade' another 340
packages installed by 'dist-upgrade'. There were minor
hiccups. In both cases errors were reported, and in both
cases an extra apt-get install completed the process.

I don't know when the last upgrade took place, next one will
be sooner, I'm sure.

> In summary if running Sid/Unstable or Testing too then I think it is
> best to keep current and not let the parts get too old and stale. It
> is just easier that way. "In for a penny, in for a pound."

Your descriptions of the upgrade procedure and how to
review it and hold packages could be a useful reference
for users of testing or unstable.

Joel

> > Thanks for your comment. This list/community is a great support.
>
> It seriously is one of the best things!
>
> Bob

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121227005313.GA24616@sprite

[Bob Proulx]

Joel Roth wrote:
> Bob Proulx wrote:
> > Joel Roth wrote:
> > > I usually just upgrade apps individually as I need to...
> >
> > As in 'apt-get install openssh-client' ? But that won't upgrade any
> > of the dependencies.
>
> I didn't know that. My first try was apt-get install ssh.

If the packages were not previously installed then of course the
entire dependency tree is pulled in and installed in order to satisfy
the dependencies. And if a new version dependency appears such as
bind9 for example which always depends upon specific versions of
libraries then those new versions will be upgraded too. But if there
isn't a specific need by stated dependency to pull in a newer version
then it won't be triggered for an install.

For example 'ssh' has:

$ apt-cache show ssh | grep ^Depends:
Depends: openssh-client, openssh-server

$ apt-cache show openssh-client | grep ^Depends:
Depends: libc6 (>= 2.11), libedit2 (>= 2.11-20080614-1), libgssapi-krb5-2 (>= 1.10+dfsg~), libselinux1 (>= 1.32), libssl1.0.0 (>= 1.0.1), zlib1g (>= 1:1.1.4), debconf (>= 1.2.0) | debconf-2.0, adduser (>= 3.10), dpkg (>= 1.7.0), passwd

I will focus on this part of that collection:

... libssl1.0.0 (>= 1.0.1) ...

At the time openssh-client was created and pushed out those were the
minimum versions it required. But then other libs such as libssl1.0.0
will upgrade independently. They will either need to move forward due
to general needs such as compatibility. Or it might have a security
vulnerability. It will be upgraded to a newer version number.

Meanwhile the ssh packaging will not have changed. That program is
only using the library. It won't change in order to specify a new
requirement until the next time it is rolled out for whatever reason.
In the meantime it will be perfectly fine. The dependency chain will
be satified with the installed version. Therefore running "install
openssh-client" will also be satisified.

> Hmmm, and we don't have apt-get --update-dependencies install ssh,

Of course it would be possible to create such a thing for Debian's APT
but the thinking is rather different. Because if one thing needs to
be upgraded then probably another thing needs to be upgraded too. One
could chase down a particular tree of dependencies only. But why do
that instead of more simply ensuring that everything is up to date.
If one thing is up to date manually but another thing is not then that
other thing is suffering and may be vulnerable to security problems or
other breakage. Better to make sure everything is up to date.

> I see that I'm 1,680 packages behind...

Things do change rapidly in Unstable! :-)

> > On Sid/Unstable I upgrade daily with:
> >
> > # apt-get update
> > # apt-get upgrade
> > # apt-get dist-upgrade

I should have added at the end that I run "clean" to empty out the
cache directory. Otherwise the buildup of cached packages can consume
all available disk space.

> The resolution of more complicated dependency issues, has
> improved a lot, in my subjective opinion. Let's see how my
> current upgrade goes....

There are some current problems. Bug#676485 for example. But I am
confident it will all be worked out before release.

> Some 1300 were packaged installed by 'upgrade' another 340
> packages installed by 'dist-upgrade'.

That is a good example of why 'upgrade' followed by 'dist-upgrade'
reduces the problem space for the resolver to deal with. Going from
1300 to 340 is a huge reduction in problem space size. And for the
human looking over the "remove" list. :-)

> There were minor hiccups. In both cases errors were reported, and
> in both cases an extra apt-get install completed the process.

Sounds about normal. If you had upgraded daily you would probably
have seen those and a handful more but one at a time as they
happened. The difference is spending time dealing with it lumped
versus amortized over the year.

> Your descriptions of the upgrade procedure and how to
> review it and hold packages could be a useful reference
> for users of testing or unstable.

Where would we put it?

Also there is:

http://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2BAC8-sid_users.3F

Bob

[Joel Roth]

Not knowing that option, I had manually deleted them.

> > The resolution of more complicated dependency issues, has
> > improved a lot, in my subjective opinion. Let's see how my
> > current upgrade goes....
>
> There are some current problems. Bug#676485 for example. But I am
> confident it will all be worked out before release.
>
> > Some 1300 were packaged installed by 'upgrade' another 340
> > packages installed by 'dist-upgrade'.

> That is a good example of why 'upgrade' followed by 'dist-upgrade'
> reduces the problem space for the resolver to deal with. Going from
> 1300 to 340 is a huge reduction in problem space size. And for the
> human looking over the "remove" list. :-)

> > There were minor hiccups. In both cases errors were reported, and
> > in both cases an extra apt-get install completed the process.
>
> Sounds about normal. If you had upgraded daily you would probably
> have seen those and a handful more but one at a time as they
> happened. The difference is spending time dealing with it lumped
> versus amortized over the year.

What *is* biting me is that the new multiarch organization
won't allow me to (re)install skype, which is expecting ia32-libs and
ia32-libs-gtk.

> > Your descriptions of the upgrade procedure and how to
> > review it and hold packages could be a useful reference
> > for users of testing or unstable.
>
> Where would we put it?
>
> Also there is:
>
> http://wiki.debian.org/DebianUnstable#What_are_some_best_practices_for_testing.2BAC8-sid_users.3F

It would go with that subject matter, but your is text longer and more
explanatory, the next level of detail. Many non-experts
use unstable. They need to know.

How do I keep my Sid-based system current?

The best practice is to upgrade your system regularly, and
deal with the occasional breakage that occurs.

As (Bob Proulx | one expert ) describes it:

On Sid/Unstable I upgrade daily with:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade

....

In summary if running Sid/Unstable or Testing too then I think it is
best to keep current and not let the parts get too old and stale. It
is just easier that way. "In for a penny, in for a pound."

Regards,

Joel

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121228024258.GA23311@sprite

[Andrei POPESCU]

On Jo, 27 dec 12, 16:42:58, Joel Roth wrote:
>
> What *is* biting me is that the new multiarch organization
> won't allow me to (re)install skype, which is expecting ia32-libs and
> ia32-libs-gtk.

Work for me (on wheezy):

$ apt-cache show skype
Package: skype
Status: install ok installed
Priority: extra
Section: non-free/net
Installed-Size: 35952
Maintainer: Skype Technologies <in...@skype.net>
Architecture: i386
Version: 4.1.0.20-1
Replaces: skype-mid, skype-common, skype-bin
Depends: libasound2 (>= 1.0.16), libc6 (>= 2.3.6-6~), libc6 (>= 2.7), libgcc1 (>= 1:4.1.1), libqt4-dbus (>= 4:4.5.3), libqt4-network (>= 4:4.8.0), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.8.0), libqtwebkit4 (>= 2.1.0~2011week13), libstdc++6 (>= 4.6), libx11-6, libxext6, libxss1, libxv1, libssl1.0.0

[Joel Roth]

On Fri, Dec 28, 2012 at 12:54:55PM +0200, Andrei POPESCU wrote:
> On Jo, 27 dec 12, 16:42:58, Joel Roth wrote:
> >
> > What *is* biting me is that the new multiarch organization
> > won't allow me to (re)install skype, which is expecting ia32-libs and
> > ia32-libs-gtk.
>
> Work for me (on wheezy):

My drama was on sid amd64 :-)

It took me:

dpkg --add-architecture i386
apt-get update

And a couple trips through the APT resolver for
all the needed i386 libraries to get installed.

Greetings,

Joel

> Kind regards,
> Andrei

--
Joel Roth


--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Archive: http://lists.debian.org/20121228110941.GB32326@sprite