Re: Versioned releases

[Bruno Haible]

Hi Dmitry,

> Despite that gnulib homepage says "Gnulib does not make releases.
> It is intended to be used at the source level." gnulib is in fact
> packaged in quite a lot of distributions:
> 
> https://repology.org/project/gnulib/versions

Indeed e.g. Debian has a gnulib "package":
  https://packages.debian.org/sid/all/gnulib/filelist

But I think it's a red herring, since basically no one is using gnulib
this way.

> Note that since there are no official versions maintainers have to
> invent versioning schemes which include "0", multiple date based and
> commit number based formats.

There is nothing wrong with that. As long as the date be retrieved from
the checkout, there is no problem:

git_checkout_date=`if test -d .git; then
                     git log -n 1 --date=iso --format=fuller | sed -n -e 
's/^CommitDate: //p';
                   else
                     sed -n -e 
's/^\([0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]\).*/\1/p' -e 1q ChangeLog;
                   fi`
pretty_date=`LC_ALL=C date +"%e %B %Y" --date="$git_checkout_date"`

> There are known vulnerabilities for gnulib which also have to use
> something version-like to describe which gnulib versions are affected
> (these use dates in YYYY-MM-DD format):
> 
> https://nvd.nist.gov/vuln/detail/CVE-2017-7476
> https://nvd.nist.gov/vuln/detail/CVE-2018-17942

It says e.g. "in Gnulib before 2018-09-23 has a heap-based buffer overflow".
It is easy for every user of Gnulib to determine whether their version
is before or after 2018-09-23. Just peek at the ChangeLog or 'gitk'.

It is not harder than when a CVE is about "OpenSSL through 1.0.1i".

> Note that it's impossible to match these against package versions due
> to inconsistent versioning scheme.

You mean, a distributor wants to determine which of the coreutils,
findutils, gawk, gettext, etc. package use the Gnulib before 2018-09-23?
This is nontrivial, but not because Gnulib does not have a version
number, but because it's shipped as a source-code library - something that
we don't want to change.

Such a distributor would
  - for packages for which they used tarballs, look at the particular file
    in the tarball (e.g. lib/vasnprintf.c); I admit it is tedious;
  - for packages for which they use the git checkout, look at the git
    submodule version (e.g. [1][2]); this is tedious as well.

But I don't see how a versioning scheme would significantly help.

> So as you can see, even though there are no official versioned releases,
> people have to invent and use these to refer to specific gnulib commit
> ranges, and not having any consistency in these schemes results in e.g.
> inability to report vulnerable packages.

I don't see noticeable problems caused by this inconsistency.

> So I suggest to fix this by introducing any kind of upstream versioning.

Are you suggesting that every gnulib commit can be translated to a
version number? There's 'git describe' which does that.

Or are you suggesting that the Gnulib developers pick, say, every 100th
Gnulib commit and assign it a version number? And how would that be useful,
since the consumers upgrade when they like to?

Bruno

[1] https://git.savannah.gnu.org/cgit/poke.git/log/gnulib
[2] https://git.savannah.gnu.org/cgit/gettext.git/log/gnulib