Re: Versioned releases

[Dmitry Marakasov]

* Bruno Haible (bruno@clisp.org) wrote:

> > 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.

My claim only covers standalone distribution of gnulib. I don't want
to dig into the reasons for why upstream forces bundling and why
downstream don't follow it anyway, but the sole fact that it's packaged
standalone in so many distribution speaks for itself of that this way of
distribution is a necessity.

With standalone distribuition there's no way to peek into git history
or some source files, but there's a clear identifier of which specific
version is packaged. And it can be used to estimate of how up to date
the packaged version is, and to reliably check whether it has known
vulnerabilities and (when semver is used) whether it's compatible with
particular consumers.

> > 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?

I would suggest using proper semver. But dumb tagging every nth
commit, or weekly or so would definitely be better than nothing,
as long as the tags use consistent scheme. There's no need for
exact commit:version mapping, to say that "versions below x.y.z"
contain a bug or vulnerability. Just enough precision to not have
to wait months for a fixed version to be released.

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

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru  ..:              https://github.com/AMDmi3