GLIBC Errors in 2.0.14-rc1 and 2.0.14

[jamesbptrsn]

Description of the problem or steps to reproduce

I attempted to update from linux64 release 2.0.13 by removing the binary and running the installation script, which installed linux64 release 2.0.14. Executing the new binary produces the following errors:

./micro: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.32' not found (required by ./micro)
./micro: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.34' not found (required by ./micro)

Manually-downloaded and extracted binaries for linux64 release 2.0.14 and linux64 release 2.0.14-rc1 produce the same errors.

Redownloading linux64 release 2.0.13 resolved the errors.

Specifications

Versions: 2.0.14 and 2.0.14-rc1
Commit hashes: 04c5770 and cc195b6
OS: Ubuntu 20.04.6 LTS

ldd --version ldd (Ubuntu GLIBC 2.31-0ubuntu9.16) 2.31

I'm still a bit of a novice with Linux and programming, so let me know if I've left anything out or did anything wrong above. As far as I've been able to discover, GLIBC is system-dependent, so I can't really upgrade to the newer required versions. The only way to do that would be to upgrade from Ubuntu 20.04 to a newer version, which I can do if the new requirement is intentional and necessary. I understand if Ubuntu 20.04 is too old of a version to support anymore, but there was nothing advising of a minimum GLIBC/OS version.

[dmaluka]

I think this is none of your fault. It is newer Go versions that require a newer minimum glibc version, and our fault that we released 2.0.14 built with Go 1.19, without realizing that it will not work on systems with older glibc (some of which are still not very old, e.g. Ubuntu 20.04 is still LTS supported, as I understand). I'm not sure which Go version was micro 2.0.13 built with, but probably it was older than 1.19, since it works for you.

Fortunately 2.0.14 also includes a fully static version of micro binary: micro-2.0.14-linux64-static.tar.gz. It doesn't have any external dependencies on glibc or any other libraries, so it should work for you without problems.

[jamesbptrsn]

Thanks so much for the response @dmaluka . I figured it might be something like that. I knew that the static version existed but had no idea what it was for. I've downloaded the static build and can confirm it works just fine. There are some nice new features implemented in 2.0.14 that was missing out on.

While I was looking through the installer script at https://getmic.ro (I'm not sure where that is maintained but it doesn't seem to be here) I noticed that it does a whole series of checks for the proper build to download, including the following lines.

if [ "${platform:-x}" = "linux64" ]; then
  # Detect musl libc (source: https://stackoverflow.com/a/60471114)
  libc=$(ldd /bin/ls | grep 'musl' | head -1 | cut -d ' ' -f1)
  if [ -n "$libc" ]; then
    # Musl libc; use the staticly-compiled versioon
    platform='linux64-static'
  fi
fi

I wonder if in addition to the check for the musl libc, it could also check for the installed version of glibc and direct to the static version if the installed glibc version is too low. This would help out people in a similar position to me not have to engage in manual installation when using an automated script.

Thanks so much for the work on the project, and the mention of the issue in the pull request.

[dmaluka]

I knew that the static version existed but had no idea what it was for.

I'd rather wonder what do we need the dynamic version for, if the static one works just fine. This is what micro's readme says about it: "By default, the micro binary will dynamically link with core system libraries (this is generally recommended for security and portability)."

Regarding the security argument, I think in your case there's nothing to worry about, since the static micro 2.0.14 binary was built with a newer glibc version than you have, so all glibc security fixes you have in your glibc should even more so be present in this static binary as well.

Regarding portability/compatibility concerns, as long as micro works fine for you, again, nothing to bother about.

While I was looking through the installer script at https://getmic.ro (I'm not sure where that is maintained but it doesn't seem to be here)

It is indeed maintained in a separate repo https://github.com/benweissmann/getmic.ro, by @benweissmann, not by micro maintainers.

I wonder if in addition to the check for the musl libc, it could also check for the installed version of glibc and direct to the static version if the installed glibc version is too low. This would help out people in a similar position to me not have to engage in manual installation when using an automated script.

It is not immediately obvious to me how to implement this check (i.e. how to find out which minimum version of glibc is required), but maybe it is not too difficult. @benweissmann what do you think?

[zyedidia]

I think it’s reasonable to just make all builds fully static by default, at least when built by the GitHub actions runner. Go has improved some of the issues with disabling cgo in recent years (the pure-go DNS resolver used to have some problems) and all non-linux builds are already all fully static anyway because they are cross-compiled.

[JoeKar]

I think this is none of your fault. It is newer Go versions that require a newer minimum glibc version, and our fault that we released 2.0.14 built with Go 1.19, without realizing that it will not work on systems with older glibc (some of which are still not very old, e.g. Ubuntu 20.04 is still LTS supported, as I understand).

Most probably not (only) caused by Go 1.19 itself, but the...
https://github.com/zyedidia/micro/blob/8c52d2426d453ed9a727ef5692ee8e882792511c/.github/workflows/release.yaml#L12
...we use in all the workflows. ubuntu-latest points actually to 22.04 (according to available-images), but then it should have glibc resp. libc6 as 2.35 (installed-apt-packages resp. jammy/libc6). 🤔
This will cause...at least at some point...problems with dynamically linked libraries not fitting to the distribution. Anyway, I'm more a friend of the packages provided via the distributions repositories build from sources, which will fit (if available).

So as already mentioned by @dmaluka & @zyedidia the only solution for the prepared binaries is to build/link them static.

Smells like a hotfix release or some new uploaded binaries.

[dmaluka]

I tend to agree with @zyedidia that we should just switch to building fully static binaries (i.e. build with CGO_ENABLED=0 by default), and be done. Keep it simple.

Smells like a hotfix release or some new uploaded binaries.

Why? 2.0.14 already includes micro-2.0.14-linux64-static.tar.gz.

[JoeKar]

Why? 2.0.14 already includes micro-2.0.14-linux64-static.tar.gz.

I attempted to update from linux64 release 2.0.13 by removing the binary and running the installation script, which installed linux64 release 2.0.14.

So everyone using quick-install-script under e.g. Ubuntu 20.04 will suffer from this incompatibility. Fixing tools/cross-compile.sh will help for newer builds/releases, but not for the actual 2.0.14 in this case.

[dmaluka]

So everyone using quick-install-script under e.g. Ubuntu 20.04 will suffer from this incompatibility.

Yep, but I'm not sure replacing already released 2.0.14 binaries is a better idea than just living with this suffering.

We might hope that most users either use a newer glibc or are wise enough not to use the quick install script...

We might add a note to the release notes in https://github.com/zyedidia/micro/releases/tag/v2.0.14 to use the static binary in case of GLIBC troubles...

[JonathanBerkeley]

We might hope that most users either use a newer glibc or are wise enough not to use the quick install script...

Why is using the quick install script unwise? I use it to put micro on short-lived containers, it has been quite useful but I have also now experienced this issue.

[dmaluka]

It may be debatable, but executing code remotely without a real need is not the best security practice. Why not do the same the script does (i.e. download the needed tarball with the latest release and unpack it, it's nothing sophisticated) but locally, so that you can be sure what is actually being executed?

BTW we now also upload SHA256 checksums for the tarballs, so you can additionally verify if the downloaded tarball itself has not been tampered with (and I've just realized that https://getmic.ro still doesn't use that).

Anyway, that is orthogonal to the discussed issue. The discussed issue is not about the installation script, it is about the micro binary in the micro-2.0.14-linux64.tar.gz tarball uploaded in the latest v2.0.14 release, namely about incompatibility of this binary with older glibc versions, which is just a manifestation of the fact that the "run the same binary everywhere" approach is not quite compatible with dynamic linking. (So it's quite possible that some other people already faced this glibc incompatibility issue in the past with older micro releases as well, when installing them on even older systems.)

As we will probably switch to building fully static binaries by default, future releases will be free of this issue. In the meantime, as v2.0.14 is already released, if you want to continue using the https://getmic.ro script, you may use something like this as a workaround:

--- a/index.sh
+++ b/index.sh
@@ -201,6 +201,10 @@ if [ "${platform:-x}" = "linux64" ]; then
     # Musl libc; use the staticly-compiled versioon
     platform='linux64-static'
   fi
+
+  if [ "$TAG" = "2.0.14" ]; then
+    platform='linux64-static'
+  fi
 fi
 
 echo "Latest Version: $TAG"

[JoeKar]

Why is using the quick install script unwise?

Because it is not under the control of the micro-editor organization, it is not under the control of micro, it is not under the control of zyedidia nor is it under the control of the current maintainers.
So if you feel comfortable with that situation or you downloaded the script and performed it locally (not as pipe-install), then it might be good enough.
At least we can't give any guarantee what will happen if you use https://getmic.ro/ for pipe-install.

[JonathanBerkeley]

Because it is not under the control of the micro-editor organization, it is not under the control of micro, it is not under the control of zyedidia nor is it under the control of the current maintainers.

Why is it promoted in the README and on https://micro-editor.github.io/ if it is untrusted?

It may be debatable, but executing code remotely without a real need is not the best security practice. Why not do the same the script does

I was under the impression that this script was provided by the same developers that develop micro. If that was the case, using micro itself is as much of a security risk. Trusting the developers not to include malicious code in the software would extend to trusting them with the install script as well.

Being controlled by a third party does change it, you are now trusting an additional source for little gain. If the maintainers of the project don't trust the script, it shouldn't be in the README.

[dmaluka]

#3254 (comment)