Re: Wget bootstrapping problem
Darshit Shah wrote: > What Bruno suggests is that Wget sets SKIP_PO=1 in the bootstrap script > and then updates the translations during build time. Yes, that is my second suggestion. > This is a bad idea. ... > Not to mention, network access during the build process is often frowned > upon. Indeed, it's best to have all git checkouts and all network accesses done, before the build starts. I withdraw the second suggestion. > For the same release, we would end up with users that have different > translations depending on when they compiled Wget. That would be only for people who build from git, not from a tarball (if it's implemented that way). I agree that building from a tarball should produce reproducible results. Bruno
Re: Wget bootstrapping problem
The problem happens when you try to run ./bootstrap on a fresh git checkout. The bootstrap script tries to sync the updated translations before running configure. What Bruno suggests is that Wget sets SKIP_PO=1 in the bootstrap script and then updates the translations during build time. This is a bad idea. For the same release, we would end up with users that have different translations depending on when they compiled Wget. Not to mention, network access during the build process is often frowned upon. One way is to build a non-localized Wget and then build a localized Wget using that. The other option I see is that bootstrap provides a `--force-rsync` option. Disabled by default. But it can be used explicitly in order to use rsync for downloading the PO files. On 5/7/20 9:56 AM, Tim Rühsen wrote: On 06.05.20 18:37, Bruno Haible wrote: We could also check for an existing wget in bootstrap.conf and set SKIP_PO=1 if not found. While it 'just works' it also disguises the real problem and the user might get something unexpected (non-internationalized wget). Alternatively, you could change the build system so that - 'make' recurses into the 'po/' directory only after 'src/', - Fetching the PO files is done through po/Makefile, not bootstrap, - po/Makefile uses src/wget, if not cross-compiling, instead of wget from $PATH. I possibly don't understand - 'po' already appears after 'src' in SUBDIRS. Since 'po/Makefile' is auto-generated, everything should work out (if I understood you correctly). So why has Darshit a problem at all ? Regards, Tim
Re: Wget bootstrapping problem
On 06.05.20 18:37, Bruno Haible wrote: >> We could also check for an existing wget in bootstrap.conf and set >> SKIP_PO=1 if not found. While it 'just works' it also disguises the real >> problem and the user might get something unexpected >> (non-internationalized wget). > > Alternatively, you could change the build system so that > - 'make' recurses into the 'po/' directory only after 'src/', > - Fetching the PO files is done through po/Makefile, not bootstrap, > - po/Makefile uses src/wget, if not cross-compiling, instead of wget from > $PATH. I possibly don't understand - 'po' already appears after 'src' in SUBDIRS. Since 'po/Makefile' is auto-generated, everything should work out (if I understood you correctly). So why has Darshit a problem at all ? Regards, Tim signature.asc Description: OpenPGP digital signature
Re: Wget bootstrapping problem
On Wed, May 6, 2020 at 4:22 AM Tim Rühsen wrote: > > On 05.05.20 03:14, Bruno Haible wrote: > > Paul Eggert wrote: > >>> We could switch the order such that Wget is the default and rsync is used > >>> as a > >>> fallback > >> > >> That sounds better than reverting, no? Perhaps you could propose a patch. > > > > No. From the point of security, "wget as default and rsync as fallback" is > > just as bad as "rsync always". Why? [1] Look at the SSLv3 / TLSv1.0 history. > > People believed that "SSLv3 is insecure, but since it's only used as a > > fallback, it doesn't matter". Until someone discovered a way to trick the > > fallback to be activated always [2]... > > > > rsync is not secure. We should not enable it again. > > > > Regarding the bootstrapping problem, why not build wget in two steps: > > 1. Bootstrap with no PO files. This produces a non-internationalized wget > > binary. > > 2. Bootstrap again, using the wget binary from step 1 to fetch the PO > > files. > > > > The 'bootstrap' script has an option '--skip-po'. The gnulib-tool script > > should behave the same way if you don't pass the --po-base=... option to it. > > > > If necessary, we can add another option to gnulib-tool to avoid fetching PO > > files and/or to avoid the use of wget. > > I fully agree with Bruno. > > We could also check for an existing wget in bootstrap.conf and set > SKIP_PO=1 if not found. While it 'just works' it also disguises the real > problem and the user might get something unexpected > (non-internationalized wget). How about a --disable-translation configure option similar to --disable-docs. That should get you over the bootsrap hurdle. But it assumes you have a adequate Unistring and OpenSSL. (From experience with some older systems and ransomware systems, I've found the minimum components needed to build Wget are Unistring and OpenSSL: https://github.com/noloader/Build-Scripts/tree/master/bootstrap). Jeff
Re: Wget bootstrapping problem
> We could also check for an existing wget in bootstrap.conf and set > SKIP_PO=1 if not found. While it 'just works' it also disguises the real > problem and the user might get something unexpected > (non-internationalized wget). Alternatively, you could change the build system so that - 'make' recurses into the 'po/' directory only after 'src/', - Fetching the PO files is done through po/Makefile, not bootstrap, - po/Makefile uses src/wget, if not cross-compiling, instead of wget from $PATH. Bruno
Re: Wget bootstrapping problem
On 05.05.20 03:14, Bruno Haible wrote: > Paul Eggert wrote: >>> We could switch the order such that Wget is the default and rsync is used >>> as a >>> fallback >> >> That sounds better than reverting, no? Perhaps you could propose a patch. > > No. From the point of security, "wget as default and rsync as fallback" is > just as bad as "rsync always". Why? [1] Look at the SSLv3 / TLSv1.0 history. > People believed that "SSLv3 is insecure, but since it's only used as a > fallback, it doesn't matter". Until someone discovered a way to trick the > fallback to be activated always [2]... > > rsync is not secure. We should not enable it again. > > Regarding the bootstrapping problem, why not build wget in two steps: > 1. Bootstrap with no PO files. This produces a non-internationalized wget > binary. > 2. Bootstrap again, using the wget binary from step 1 to fetch the PO files. > > The 'bootstrap' script has an option '--skip-po'. The gnulib-tool script > should behave the same way if you don't pass the --po-base=... option to it. > > If necessary, we can add another option to gnulib-tool to avoid fetching PO > files and/or to avoid the use of wget. I fully agree with Bruno. We could also check for an existing wget in bootstrap.conf and set SKIP_PO=1 if not found. While it 'just works' it also disguises the real problem and the user might get something unexpected (non-internationalized wget). Regards, Tim > > Bruno > > [1] https://en.wikipedia.org/wiki/Downgrade_attack > [2] https://en.wikipedia.org/wiki/POODLE > > signature.asc Description: OpenPGP digital signature
Re: Wget bootstrapping problem
Paul Eggert wrote: > > We could switch the order such that Wget is the default and rsync is used > > as a > > fallback > > That sounds better than reverting, no? Perhaps you could propose a patch. No. From the point of security, "wget as default and rsync as fallback" is just as bad as "rsync always". Why? [1] Look at the SSLv3 / TLSv1.0 history. People believed that "SSLv3 is insecure, but since it's only used as a fallback, it doesn't matter". Until someone discovered a way to trick the fallback to be activated always [2]... rsync is not secure. We should not enable it again. Regarding the bootstrapping problem, why not build wget in two steps: 1. Bootstrap with no PO files. This produces a non-internationalized wget binary. 2. Bootstrap again, using the wget binary from step 1 to fetch the PO files. The 'bootstrap' script has an option '--skip-po'. The gnulib-tool script should behave the same way if you don't pass the --po-base=... option to it. If necessary, we can add another option to gnulib-tool to avoid fetching PO files and/or to avoid the use of wget. Bruno [1] https://en.wikipedia.org/wiki/Downgrade_attack [2] https://en.wikipedia.org/wiki/POODLE
Re: Wget bootstrapping problem
Sure, I'll propose a patch tomorrow. On May 5, 2020 2:03:12 AM GMT+02:00, Paul Eggert wrote: >On 5/4/20 4:31 PM, Darshit Shah wrote: >> We could switch the order such that Wget is the default and rsync is >used as a >> fallback > >That sounds better than reverting, no? Perhaps you could propose a >patch. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Wget bootstrapping problem
On 5/4/20 4:31 PM, Darshit Shah wrote: > We could switch the order such that Wget is the default and rsync is used as a > fallback That sounds better than reverting, no? Perhaps you could propose a patch.
Wget bootstrapping problem
Hi, In 2018 gnulib applied the patch discussed here: https://lists.gnu.org/archive/html/bug-gnulib/2018-10/msg00020.html However, since Wget uses gnulib as part of its build process, this patch causes a bootstrapping problem for Wget due to a cyclic dependency: Wget -> gnulib -> Wget Hence, I request that the patch be reverted. We could switch the order such that Wget is the default and rsync is used as a fallback, but that allows us to build Wget without already needing a Wget binary from somewhere else. Thanking You, Darshit Shah
