Re: changed behaviour for "cygcheck -p "

[Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>]

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.