[Mingw-users] Secure crt functions not in header files

[John Brown]

Hello All,

I see that functions such as printf_s described at
https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
are present in /mingw/lib/libmsvcr80.a but I cannot find them in any
MinGW header file (at least not in /mingw/include/*.h). Is there a
particular reason for that?

Regards,
John Brown.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by John Brown
I see that functions such as printf_s described at
https://docs.microsoft.com/en-us/cpp/c-runtime-library/security-features-in-the-crt
are present in /mingw/lib/libmsvcr80.a but I cannot find them in any
MinGW header file (at least not in /mingw/include/*.h). Is there a
particular reason for that?
Perhaps because no one has been sufficiently taken in by
Microsoft's lies, (in what way do such functions provide added
security? What user authentication mechanisms do they provide?),
to be bothered to submit patches to add them.

The section entitled "Additional Security Features" at the link that I
provided explains what is more secure about these functions. It seems
to be mainly about avoiding buffer overruns as opposed to user
authentication.

And Google will turn up any number of references, which explain why
they are inappropriately described as security enhancing, and indeed
if anything may actually be prejudicial to security; Microsoft have
chosen to promote them thus, to engender and exploit FUD.

Post by John Brown
Realistically, the only security related aspect of the majority of
such functions is that they secure an increased level of Microsoft
lock-in; I am not enthusiastic about encouraging their use.

If you feel so strongly about it, then surely you should exclude these
functions from the import libraries? I only asked because they were
in the libraries but not in the header files.

That's not an unreasonable suggestion. However, right now the import
libraries reflect what our pexports tool says is provided by the union
of all currently support MSVCRT.DLL versions, as documented here:
https://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/msvcrt-xref/

Obviously, that union will necessarily be more comprehensive than the
list of exports from any one version of MSVCRT.DLL, particularly in the
case of the versions from older versions of Windows itself. To support
linking with any MSVCRT.DLL version, the import library must cover all
eventualities -- there is no way to make a single implib selective for
multiple similarly named DLLs; the only selectivity possible is that
which is achievable by selective exposure of prototypes in headers.

Notwithstanding the above, and given that we want to keep msvcrt-xref
fully comprehensive, while still generating libmsvcrt.a from the same
symbol reference source, there are some symbols explicitly filtered
out of the import libraries; we could extend the list of such symbols,
if the user population deems it desirable. I will be guided by the
wishes of any significant number of users here; if you think we should
exclude Microsoft's *_s() nonsense, please say so; if you think we
should support it, please submit patches via the feature request
tracker.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZKDr9AAoJEMCtNsY0flo/ENgQALk4qN8X6U1GTcygNDZYScbF
4P++2Qkis8uDuzeHSxKWV3gG5s1YhP9j3OS6GzHHGmy9iIEXX+UoStE94521e+aI
v7sVD3F1tKPP9/Q5rUK6Bk6LDhRuzX5Lzs5JJffMf7mh7pFxaBMgD9cNE8lptNYH
n8wW1fC2KxsgN8RRr/awlfzuKFgTBwVPTf1D/P/XrY0OcQsKGuPRf46DLXIeZQv2
m9SsXoThoiDjyze1D1W3ih9X9daJ6yywu5l69vJgOy1GWUvxTEUfuJGurWWlPoVz
KPRr9BUbACC6SAsSuEKDPtWjna4diGd314dsX8mBchbhgCCl0gpvr7iJY4CxvTnD
VE9MSoIgi34Crtdl+e8fZltJVA/+Yie23KmqQ7c1NbqC1FSJtWkXVP10AleWN00L
BEdVxtKFnvslRnXWq/87au62nBf7hrhw0lIu8FNroM62Ws87GMLsIrYhUbbpXUDL
3l/u5BZ10zf5DsIc4ZJkoseGfzNYNPfRjF0uOgZUSKObQzX9hXkTC4lTza6Sxj+X
dshiekHnbXcml0fwiz4Rg20mpWcZKew2HrX3bKiG+GjNfxjnnplFzMRZjiP5a1J1
5jCN5J25fdxreaRSpgySNs49PSY+F2oAadDWtganqaj0uJPIFdL4qVg9yVE5rQ4K
RaF/tGmxLON2kNBruvZH
=gUPd
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Keith Marshall
Notwithstanding the above, and given that we want to keep msvcrt-xref
fully comprehensive, while still generating libmsvcrt.a from the same
symbol reference source, there are some symbols explicitly filtered
out of the import libraries; we could extend the list of such symbols,
if the user population deems it desirable. I will be guided by the
wishes of any significant number of users here; if you think we should
exclude Microsoft's *_s() nonsense, please say so; if you think we
should support it, please submit patches via the feature request
tracker.

My vote is to keep them.

I don't have a problem with doing so; however...

Some poor system might just be using these regardless.

Any such system must (currently) do so, without any dependence on
prototypes in our headers, for such prototypes don't yet exist.

I also think if someone wants to provide proper clean room patches
with appropriate guards for these we shouldn't be glib about adding
them.

Sure, provided the guards are appropriate, and the poster can cite
direct MSDN references for content, or can demonstrate a clean room
technique to fill in any undocumented content. Hence my request to
have such patches submitted via our tracker, where we can review,
discuss, and appropriately vet them.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZKFYyAAoJEMCtNsY0flo/EC8P/A3vg6ghiubCtOU/II2EsgR5
LhMq/kyy2+CxjojaKCy+6k2EGX6KXw7iHujRhBgkAgnAndLfNppxwZVXJfkIj5Uz
sWjo81GA+4D4vgMY6xygI9F5FQHlwWHozQ6g1PcbEDeXPFdJmurAUZWrO5UuqW5S
UCEVAFGavs6TmdkOoJmIogzCy39gRzQe+LQRemo619z07Q9VidYIz+xsjGnkvhAm
fcVn5ohjYU6b9isXBNxawR0jaZsMVTAKIcIHH5+4oLTqFj4yhqtHr+Ivqd9nBK5w
5lEcbTrtrfVEMFgJrCW15tdK266q+rgehLCiQJXOgIR1bg9cS2LSV5kVmAtvZyJn
XDz88wbv7qmSFVl0XHEgggLv2EWHpAWjz6UlAuF2EZUwCgLILAottcjKXwaF+xVs
c9jl+vKelCec+1IyQ8f9fRkNxxUn4d65V+BuP1BSLCynMZ2vDjEvTqDBJ8fU2pPe
kBOfLxQFAIsfBy6dxYJHD448iAxYB2XgRxIBm9YW/XjHDivvgchmUd9PpTTeklte
LILshXkXRZSOw/N18SmyFC0zb3FbYd/Lhr7arH9csLzmWDCVMHiAyVwKjy15qnFl
GtTVXTxt5m5WIrGmXNoBQHi/UOLR1+dra4dih8tZYQR73GpEPzR5UIbuaFnZh3ly
PU5qasGbxK8RhIhXn7sV
=V9HQ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe

[Keith Marshall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since they are MS functions, I would guess they are declared in one
of the MS headers, which would make logical NOT to declare them again
in MinGW headers.

Why would you think that? MSDN is explicit about which headers should
define them, and they are all CRT functions, *not* WinAPI functions.

#include <windows.h>
should give you the declarations.

No, it should not! In any case, <windows.h> is just as much a MinGW
header, (from the w32api package), as any of the CRT headers from the
mingwrt package.

- --
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZJz+ZAAoJEMCtNsY0flo/UykP/1ROX1NUzTZNTciz0DvNctAa
HMOdxEhuCBc1TqXR9aP9pgfQc0h/ZD/YUfIYlpYpkSB/HJ3Shge4PEjq4Lhedjkl
wvT7bIkiPXU+Ehq8gQt3ISQpuTem17UsWQrhenwSoI6Kqk+Do+u4VLW4P0YqHngT
YFOBuhYjIBsHV4YQ9Lk9vfO9S71kZmrzd+43MnYDWitvsyxa3yM2EhTUa5tNPrCt
nL2gaXTvir/T+aVIO8oUdtioX8ZRufr9903HmZup0uG74BI+9No89FqXGFo3GtiU
s3uV5yNyjCJjFLtulMO5DETa5Cp5ilm70bVp20kWLQGHXMhwVsUWwxUmFQlu5efc
tkxAK8gZWdoEHPKnLcCdHWvJpZ3JtSgp2TUnRKOaJmY36OahYZCnjUZ4J0q1Z9E0
nr8/fXoH08aGWeGaNNapkWHVLcXTVA96Uq0LfxPP9fZROqBlpMEWkPG0hatSc/1f
qH1nb4WMuJ2pms9+SnLCuOnRmdgm4ubaQU4rGyDv2eQkU6r0Pa9NVLUO2W8kcc1Q
/aTH/qEThI2x9O0z+KNAsgEySy8nb7fGnOUs5IWmWckhegX8WVnPoXRpOpLw7hNQ
mBs+k4yJuDxHZ/Tf5HqkPdiVkVXinqWB9wRQwCV2XhTpD1Xb9rdUklRXdLl7/OPq
4b6Ar77cZvxQUw4mtGV7
=RyHa
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
MinGW-users mailing list
MinGW-***@lists.sourceforge.net

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-***@lists.sourceforge.net?subject=unsubscribe