Fixes#4740
The MSYS2 run-time convert arguments that look like paths when
executing a program unless that application is linked with the MSYS
run-time. The exact conversion rules are listed here:
http://www.mingw.org/wiki/Posix_path_conversion
With the built-in configurations (all having names starting with
"mingw"), the openssl application is not linked with the MSYS2
run-time, and therefore, it will receive possibly converted arguments
from the process that executes it. This conversion is fine for normal
path arguments, but it happens that some arguments to the openssl
application get converted when they shouldn't. In one case, it's
arguments like '-passin file:something', and in another, it's a file:
URI (what typically happens is that URIs without an authority
component get converted, 'cause the conversion mechanism doesn't
recognise them as URIs).
To avoid conversion where we don't want it, we simply assign
MSYS2_ARG_CONV_EXCL a pattern to avoid specific conversions. As a
precaution, we only do this where we obviously need it.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/4765)
Get some trivial test coverage that this flag does what it claims to.
[extended tests]
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1700)
AGL has a history of pointing out the idiosynchronies/laxness of the
openssl PEM parser in amusing ways. If we want this functionality to
stay present, we should test that it works.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2756)
Generate a fresh certificate and DSA private key in their respective PEM
files. Modify the resulting ASCII in various ways so as to produce input
files that might be generated by non-openssl programs (openssl always
generates "standard" PEM files, with base64 data in 64-character lines
except for a possible shorter last line).
Exercise various combinations of line lengths, leading/trailing
whitespace, non-base64 characters, comments, and padding, for both
unencrypted and encrypted files. (We do not have any other test coverage
that uses encrypted files, as far as I can see, and the parser enforces
different rules for the body of encrypted files.)
Add a recipe to parse these test files and verify that they contain the
expected string or are rejected, according to the expected status.
Some of the current behavior is perhaps suboptimal and could be revisited.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2756)
