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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 5136D1F55B for ; Thu, 4 Jun 2020 18:20:09 +0000 (UTC) Received: from localhost ([::1]:36086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jguTI-0005gN-62 for normalperson@yhbt.net; Thu, 04 Jun 2020 14:20:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jguSv-0005fy-4R for bug-gnulib@gnu.org; Thu, 04 Jun 2020 14:19:46 -0400 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.25]:36102) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jguSs-0005Ru-Oa for bug-gnulib@gnu.org; Thu, 04 Jun 2020 14:19:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1591294778; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=RQuQiVUhXBrcTIKAKTBfV224RVliLZt5JbAlil/rSpQ=; b=d6MftspvJVhwa/8GlO3DKI76zp52V6KJ4Vvnk83CFnfi5aM9ntSh9gA75jqlQ3T2aM r5cmnLJkx++V3glP1Oam+9To/Q1wRhG42BBQ+jIWu9SRAHCY/LuTtRov6+T1/IZMZR1f LdZGdiVv8RWJmfM+cECXshRPTbJocl94jtkGdIXcU9cU+t7tYA/YxzqM/WEVdbq4Rm3i V55sONlY5BdkgrIkhbZPmJ07QABZAk6/Kr/FbkIbjHmm7TbBGUlyaeWvN9tIJYJO7HiX 817SD6MdiSlv1wFLXEu0eNEOSO07SF/1yFyz3RyENvhucNxlJqQZBkpzf4I0CEemajWc 7BXg== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOH6fzxfs=" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 46.9.1 DYNA|AUTH) with ESMTPSA id V0a757w54IJbBnU (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Thu, 4 Jun 2020 20:19:37 +0200 (CEST) From: Bruno Haible To: bug-gnulib@gnu.org Subject: Re: Versioned releases Date: Thu, 04 Jun 2020 20:19:36 +0200 Message-ID: <1941801.zvzjLHy5AZ@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-177-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20200604154144.GB11553@hades.panopticon> References: <20200604154144.GB11553@hades.panopticon> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Received-SPF: none client-ip=85.215.255.25; envelope-from=bruno@clisp.org; helo=mo4-p00-ob.smtp.rzone.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/04 14:19:38 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-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: Dmitry Marakasov Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" 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