changed behaviour for "cygcheck -p "
Brian Inglis
Brian.Inglis@SystematicSw.ab.ca
Sat May 2 14:53:23 GMT 2020
On 2020-05-02 04:11, Marco Atzeri via Cygwin wrote:
> It seems there is a new escape system that is fooling
> the search engine
>
> $ cygcheck -p 'bin/mutt'
> Found 0 matches for binx2fmutt
>
> same on the Web
e.g. Cygwin Packag Search
https://cygwin.com/packages/
enter:
"...
[ bin/cpuid.exe ] [Go]
( ) x86 (o) x86_64
..."
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin%2Fcpuid.exe&arch=x86_64
result:
"...
Cygwin Package Search
Search package contents for a grep basic regular expression pattern
[ binx2Fcpuid.exe ] [Go]
( ) x86 (o) x86_64
Search Results
Found 0 matches for x2Fusrx2Fbinx2Fcpuid.exe
"
but tweak the browser URL directly:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=bin/cpuid.exe&arch=x86_64
"...
Cygwin Package Search
Search package contents for a grep basic regular expression pattern
[ bin/cpuid.exe ] [Go]
( ) x86 (o) x86_64
Search Results
Found 2 matches for bin/cpuid.exe
cpuid-20200211-1 - cpuid: dumps CPUID information about the CPU(s)
cpuid-20200427-1 - cpuid: dumps CPUID information about the CPU(s)
"
and curl and wget also work with the above non-urlencoded URL, so it looks like
the new server CGI borks handling urlencoded parameter values e.g. / -> %2F,
from either cygcheck -p or the web form, possibly from trying to pass thru some
urldecode filter converting %2F -> \x2F -> /, but with inadequate escaping
\\x2F, quoting '\x2F', or format (perhaps needs 0x2F?) to pass thru enough
layers to get converted, resulting in just converting "\x" to "x".
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
More information about the Cygwin
mailing list