Re: .gitmodules security

[Alex Ameen]

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