Secure crt functions not in header files

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

Emanuel Falkenauer
Hi John,

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.

#include <windows.h>

should give you the declarations.

Best,

Emanuel

On 25-May-17 17:44, John Brown wrote:

> 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
> [hidden email]
>
> 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:[hidden email]?subject=unsubscribe
>


------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

Keith Marshall-3
In reply to this post by John Brown
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 16:44, John Brown wrote:
> 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.

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.

- --
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)

iQIcBAEBAgAGBQJZJxgnAAoJEMCtNsY0flo/DAAP/0Kng+xz2JJAaHkDaHZDhAKG
ohDWm/Mcr2Qw8KXVnCm7JOuFUPg82ck2TlD0QbJQkpgbdwbg9DTJVcyLxaap9eVs
Bfjx3vZMXUGdIBbJNNvX3UykjjVomw+4q4RkqNJoBtkbdrwM/L+9WMwcc5mGYFIm
PgKtwCKtyLewXrxgQJqR3DeBGu7AEgkrPkYrKOz4RSmfBmKsqwGr/FrpL0vLgHLm
LXkThkeWnmR43+FhLdS7GWa6QU6vbinnHRFfh1jwBBom+oQzfkoLEbMOt5jmtmMy
TOg8u+q187/B9Jg37cgg6v3rAoR7pg4QYDwBufItQXqjnr0WatmzyuHOMS4FJ6Q6
4AW+0puZKZZd8J4XDXkCjF1o6Qd1qwnN31auXCJd1+nkBgLw8S0pBkb1scsvn/hW
oayCaCmk6uRtF0ZWmvshFQRJyufi/Ood3SL3rhIN3HjiQw1v0VPOcy9r3c/U7Jje
5Q960v+IuccBcdFUxcNgru4O8hm71qpXItKYciJWhB/gX7BTxXoK5rHhrSO7jnHI
gMJ9W56eG+htd2SVO2tzvHCGvbzbY2gbvGQWkHvf7p7AXaaw5PtZ43zbvyepzdou
GLuFnO28o+9cOME1OvXmHHWeiDbsLjCw6yKM8qsojiG68kCY0tSAvG+quOvMnAyo
pUfrKQAysBhoN6y6h5pd
=wrSZ
-----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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

Keith Marshall-3
In reply to this post by Emanuel Falkenauer
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 17:29, Emanuel Falkenauer wrote:
> 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

John Brown
In reply to this post by Keith Marshall-3
On Thursday, May 25, 2017 1:45 PM, Keith Marshall wrote:

> On 25/05/17 16:44, John Brown wrote:
> 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.

> 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.

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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25/05/17 23:40, John Brown wrote:

> On Thursday, May 25, 2017 1:45 PM, Keith Marshall wrote:
>> On 25/05/17 16:44, John Brown wrote:
>> 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.

>> 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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

Earnie Boyd
On 5/26/2017 10:26 AM, Keith Marshall wrote:

>
> 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.  Some poor system might just be using these
regardless.  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.

--
Earnie

------------------------------------------------------------------------------
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
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Secure crt functions not in header files

Keith Marshall-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 26/05/17 15:58, Earnie wrote:

> On 5/26/2017 10:26 AM, Keith Marshall wrote:
>> 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
[hidden email]

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:[hidden email]?subject=unsubscribe