From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 2334A1F55B for ; Thu, 4 Jun 2020 19:32:17 +0000 (UTC) Received: from localhost ([::1]:50374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgvb5-0003Ff-SD for normalperson@yhbt.net; Thu, 04 Jun 2020 15:32:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44526) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgvb2-0003FP-Kp for bug-gnulib@gnu.org; Thu, 04 Jun 2020 15:32:12 -0400 Received: from sprint-2.amdmi3.ru ([185.185.68.145]:27538) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgvax-000360-5h for bug-gnulib@gnu.org; Thu, 04 Jun 2020 15:32:09 -0400 Received: from amdmi3.ru (localhost [127.0.0.1]) by sprint-2.amdmi3.ru (Postfix) with SMTP id E22503D410E; Thu, 4 Jun 2020 22:32:02 +0300 (MSK) Received: by amdmi3.ru (nbSMTP-1.00) for uid 1000 amdmi3@amdmi3.ru; Thu, 4 Jun 2020 22:32:02 +0300 (MSK) Date: Thu, 4 Jun 2020 22:29:14 +0300 From: Dmitry Marakasov To: Bruno Haible Subject: Re: Versioned releases Message-ID: <20200604192914.GE11553@hades.panopticon> References: <20200604154144.GB11553@hades.panopticon> <1941801.zvzjLHy5AZ@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1941801.zvzjLHy5AZ@omega> Received-SPF: none client-ip=185.185.68.145; envelope-from=amdmi3@amdmi3.ru; helo=sprint-2.amdmi3.ru X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 15:32:03 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" * 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