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