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
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
On 07 Feb 2022 12:24, Vincent Lefevre wrote:
> On 2022-02-07 05:43:11 -0500, Mike Frysinger wrote:
> > On 07 Feb 2022 09:32, Vincent Lefevre wrote:
> > > what is done on Debian (where the libtool uses the version from the
> > > gnulib package, so that it is interesting to know the behavior with
> >
On 2022-02-07 05:43:11 -0500, Mike Frysinger wrote:
> On 07 Feb 2022 09:32, Vincent Lefevre wrote:
> > what is done on Debian (where the libtool uses the version from the
> > gnulib package, so that it is interesting to know the behavior with
> > the current gnulib).
>
> eh ? packages that levera
On 07 Feb 2022 09:32, Vincent Lefevre wrote:
> what is done on Debian (where the libtool uses the version from the
> gnulib package, so that it is interesting to know the behavior with
> the current gnulib).
eh ? packages that leverage gnulib don't get libtool from gnulib. they
get it from libto
On 2022-02-06 19:49:36 -0500, Mike Frysinger wrote:
> the repository is pinned to a specific commit as you can see online:
> https://git.savannah.gnu.org/cgit/libtool.git/log/gnulib
>
> so the normal git clone + submodule sync requires a sha1 collision.
>
> if someone were to manually update the
On 07 Feb 2022 00:19, Vincent Lefevre wrote:
> On 2022-02-06 16:43:47 -0500, Mike Frysinger wrote:
> > it requires more than a MITM to be successful. you'd also have to
> > come up with a sha1 collision which is non-trivial for most people.
> > not out of the reach of nation states, but we prob are
On 2022-02-06 16:43:47 -0500, Mike Frysinger wrote:
> it requires more than a MITM to be successful. you'd also have to
> come up with a sha1 collision which is non-trivial for most people.
> not out of the reach of nation states, but we prob aren't the target
> market :p.
I don't understand why y
On 06 Feb 2022 14:59, Alex Ameen wrote:
> Hey, I can't claim to be an expert about this category of vulnerability;
> but I appreciate you raising this concern.
it requires more than a MITM to be successful. you'd also have to come up with
a sha1 collision which is non-trivial for most people. n
On 2022-02-06 14:59:00 -0600, Alex Ameen wrote:
> Hey, I can't claim to be an expert about this category of vulnerability; but
> I appreciate you raising this concern.
>
> So is your recommendation to use https://git.savannah.gnu.org/git/gnulib.git
> instead of git://git.sv.gnu.org/gnulib.git?
Ye
Hey, I can't claim to be an expert about this category of vulnerability;
but I appreciate you raising this concern.
So is your recommendation to use
https://git.savannah.gnu.org/git/gnulib.git instead of
git://git.sv.gnu.org/gnulib.git?
On 2/6/22 2:26 PM, Vincent Lefevre wrote:
On 2022-02-0
On 2022-02-06 21:22:11 +0100, Vincent Lefevre wrote:
> The .gitmodules file contains:
>
> [submodule "gnulib"]
> path = gnulib
> url = git://git.sv.gnu.org/gnulib.git
> [submodule "bootstrap"]
> path = gl-mod/bootstrap
> url = https://github.com/gnulib-modules/boots
The .gitmodules file contains:
[submodule "gnulib"]
path = gnulib
url = git://git.sv.gnu.org/gnulib.git
[submodule "bootstrap"]
path = gl-mod/bootstrap
url = https://github.com/gnulib-modules/bootstrap.git
but AFAIK, there is no host authentication done with the "g
13 matches
Mail list logo
