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
