[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .gitmodules security

From: Alex Ameen
Subject: Re: .gitmodules security
Date: Sun, 13 Feb 2022 19:16:08 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0

Thanks for bringing this up. This point is actually relevant for a change I was considering this week.

As you pointed out, `libtool' "really" doesn't need to be synced with the most up to date `gnulib', since really these are all "developer dependencies". The only parts of this which are a bit of gray area are things like `option-parser' and `extract-trace', but I don't see any compelling reason that these need to be synced with the most recent updates to those modules.

Using the most up to date modules wouldn't normally be harmful; except that they do add a significant amount of complexity to the `bootstrap' phase for `libtool', and really throw a wrench in the Hydra CI system ( this isn't the fault of `gnulib' really, Hydra just doesn't support `git' submodules in a robust manner ).

I was considering consuming both the `bootstrap' and our other `gnulib' modules into the `libtool' repository, and adding a script which would explicitly perform updates ( perhaps annually ). Aside simplifying the `bootstrap' phase and alleviating Hydra headaches, it would also eliminate the security concern you've raised.

If anyone has compelling counter-examples against such a change please let me know. I'd definitely enjoy running Hydra builds again without the headache of manually performing the `gnulib' submodule sync behaviors - since that is what causes existing failures.

On 2/11/22 4:35 AM, Vincent Lefevre wrote:
On 2022-02-11 05:05:45 -0500, Mike Frysinger wrote:
i'm not sure that's accurate.  if you look at the history of the gnulib
submodule, it's updated maybe once a year.  gnulib doesn't need to be
synced to its latest commit all the time to work.  i think any automated
distro testing should be focusing on what the git repo is using.

It seems that in 2016, the Debian libtool maintainer chose to use the
gnulib code from the Debian package instead of the one distributed
with libtool. In the Debian changelog:

   * Build-Depend on gnulib and tell bootstrap where to found it.

In general, when 3rd-party code is used by a project, Debian prefers
to use the version it provides via its own packages rather than the
version used by upstream (even though this may yield API and ABI
compatibility issues), apparently because it is easier to apply
security fixes (what upstream doesn't always do, in particular
because active Debian releases may still have versions that upstream
no longer supports). But I don't know whether this is the reason for

reply via email to

[Prev in Thread] Current Thread [Next in Thread]