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
Re: find, fts: dramatical improvement of speed in find
Askar Safin wrote: > Hi. It seems my previous letter was missed. Also, Paul, mailer daemon of my > mail provider mail.ru said me that it cannot deliver letters to you. You don't > want random letters or it is problem on my side? Your mail appeared in the archive: https://lists.gnu.org/archive/html/bug-gnulib/2020-04/msg00090.html You can therefore assume that it reached the subscribers. Your expectation, however, that every mail you send will be replied to quickly, is not met by reality. Bernhard and Paul explained why. You need to give the people time. If the issue you are reporting is important, feel free to send a polite 'ping' in a month or so. Bruno
Re: find, fts: dramatical improvement of speed in find
Hi. It seems my previous letter was missed. Also, Paul, mailer daemon of my mail provider mail.ru said me that it cannot deliver letters to you. You don't want random letters or it is problem on my side? > Hi. Thanks a lot for applying patch. I use "find" very often (always in "-L" > mode), so its performance is important for me. So I want to continue > optimizing it. > > I found that gnulib commit 2649851d0409c3fafee7cf396d11c10892ac0e53 (2017) > introduced a speed regression. > > "find -L /home/user" on my computer with find > 79e8e03cda028c7d3134d8de63a40367eaa2f952 (2017) and gnulib > f7eb1b99e30517fc50c130cdecec24059a1b7c4f (previous before 2649851d0409c3fafe) > takes 7,32 s. > But same find version (79e8e03cda028c7d3134d8de63a40367eaa2f952) with gnulib > 2649851d0409c3fafee7cf396d11c10892ac0e53 takes 8,29 s. > I don't know reason, but I noticed that if I apply to regressed version > (gnulib 2649851d0409c3fafee7cf396d11c10892ac0e53) patch > http://paste.debian.net/hidden/1ff503a8/ , then regression disappears, i. e. I > will get normal ~7,32 s. > > Also I was able to port this patch to modern find and gnulib version. Let's > take current find master 7642d172e10a890975696d28278e5192d81afc5b and current > gnulib master bddb8c50edc730e4ea60181a541f4fe41ba933ff (i. e. with my > optimization from previous > letter). If I apply patch http://paste.debian.net/hidden/845d44cf/ (this is my > attempt to port that anti-regression patch) to this gnulib commit, then speed > increases from 3,33 s. to 2,46 s. > > Also I don't understand comment "If we're not in CWDFD mode, don't bother with > this optimization, since the caller is not serious about performance" from > modern gnulib sources (fts.c). What this means? When I run "find -L" (with > find > 7642d172e10a890975696d28278e5192d81afc5b and gnulib > bddb8c50edc730e4ea60181a541f4fe41ba933ff without patches from *this* letter), > I got to that code path (I verified this by inserting fprintf there). So "find > -L" actually gets us to that point. And I need > performance in that use case. > > == > Askar Safin > https://github.com/safinaskar == Askar Safin https://github.com/safinaskar
