Topic: Crypto-hash obfuscated namespaces
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 Aug 2014 15:18:19 +0800
Raw View
--Apple-Mail=_C1E79371-C9D0-408A-B6B7-E2E7FCAD019C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
std::typeinfo::name strings tend to carry a lot of potentially secret infor=
mation about a program's implementation, and they can bloat an executable a=
s well. I don't know of any way to strip them, but they're easily accessibl=
e by the Unix strings command or just by grepping a binary file for alphanu=
meric sequences. It would be nice to opt to replace them with SHA hashes or=
the like, on a per-class or namespace basis.
namespace [[obfuscate]] {
class [[obfuscate]] secret_sauce {
...
};
}
The attribute itself might not need standardization, it would just be nice =
to see in an implementation. It could be a killer feature.
However, there is currently no attribute-specifier-seq in the namespace gra=
mmar. I think it should go into original-namespace-definition. Has this alr=
eady been considered, or is a DR appropriate?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_C1E79371-C9D0-408A-B6B7-E2E7FCAD019C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div><font face=3D"Cou=
rier">std::typeinfo::name</font> strings tend to carry a lot of potentially=
secret information about a program’s implementation, and they can bl=
oat an executable as well. I don’t know of any way to strip them, but=
they’re easily accessible by the Unix strings command or just by gre=
pping a binary file for alphanumeric sequences. It would be nice to opt to =
replace them with SHA hashes or the like, on a per-class or namespace basis=
..<br><div><div><br></div><div><font face=3D"Courier">namespace </font>=
<span style=3D"font-family: Courier;">[[obfuscate]]</span><span style=3D"fo=
nt-family: Courier;"> </span><span style=3D"font-family: Courier;">{</=
span></div></div></div><div><font face=3D"Courier"> class [[ob=
fuscate]] secret_sauce {</font></div><div><font face=3D"Courier"> &nb=
sp; …</font></div><div><font face=3D"Courier"> &n=
bsp; };</font></div><div><font face=3D"Courier">}</font></div><div><br></di=
v><div>The attribute itself might not need standardization, it would just b=
e nice to see in an implementation. It could be a killer feature.</div><div=
><br></div><div>However, there is currently no <i>attribute-specifier-seq</=
i> in the namespace grammar. I think it should go into <i>original-namespac=
e-definition</i>. Has this already been considered, or is a DR appropriate?=
</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_C1E79371-C9D0-408A-B6B7-E2E7FCAD019C--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Aug 2014 02:27:15 -0500
Raw View
On Wednesday 20 August 2014 15:18:19 David Krauss wrote:
> std::typeinfo::name strings tend to carry a lot of potentially secret
> information about a program's implementation, and they can bloat an
> executable as well. I don't know of any way to strip them, but they're
> easily accessible by the Unix strings command or just by grepping a binary
> file for alphanumeric sequences. It would be nice to opt to replace them
> with SHA hashes or the like, on a per-class or namespace basis.
>
> namespace [[obfuscate]] {
> class [[obfuscate]] secret_sauce {
> ...
> };
> }
>
> The attribute itself might not need standardization, it would just be nice
> to see in an implementation. It could be a killer feature.
>
> However, there is currently no attribute-specifier-seq in the namespace
> grammar. I think it should go into original-namespace-definition. Has this
> already been considered, or is a DR appropriate?
This doesn't look like it needs to be standardised at all. The standard
doesn't require that typeinfo carry a readable name. It's only required to be
unique per type (the portable C++ ABI carries the mangled name).
I believe you should file this request with your toolchain provider.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Aug 2014 10:57:23 +0200
Raw View
--20cf303e9e90e650c905010bca63
Content-Type: text/plain; charset=UTF-8
On Wed, Aug 20, 2014 at 9:27 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> On Wednesday 20 August 2014 15:18:19 David Krauss wrote:
> > std::typeinfo::name strings tend to carry a lot of potentially secret
> > information about a program's implementation, and they can bloat an
> > executable as well. I don't know of any way to strip them, but they're
> > easily accessible by the Unix strings command or just by grepping a
> binary
> > file for alphanumeric sequences. It would be nice to opt to replace them
> > with SHA hashes or the like, on a per-class or namespace basis.
> >
> > namespace [[obfuscate]] {
> > class [[obfuscate]] secret_sauce {
> > ...
> > };
> > }
> >
> > The attribute itself might not need standardization, it would just be
> nice
> > to see in an implementation. It could be a killer feature.
> >
> > However, there is currently no attribute-specifier-seq in the namespace
> > grammar. I think it should go into original-namespace-definition. Has
> this
> > already been considered, or is a DR appropriate?
>
> This doesn't look like it needs to be standardised at all. The standard
> doesn't require that typeinfo carry a readable name. It's only required to
> be
> unique per type (the portable C++ ABI carries the mangled name).
>
The name isn't required to be unique per type. An implementation may
return the empty string for all types for example, provided this behavior
was documented. (See 18.7.1 [type.info])
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--20cf303e9e90e650c905010bca63
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Aug 20, 2014 at 9:27 AM, Thiago Macieira <span dir=3D"ltr">=
<<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieir=
a.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Wednesday 20 August 2014 =
15:18:19 David Krauss wrote:<br>
> std::typeinfo::name strings tend to carry a lot of potentially secret<=
br>
> information about a program's implementation, and they can bloat a=
n<br>
> executable as well. I don't know of any way to strip them, but the=
y're<br>
> easily accessible by the Unix strings command or just by grepping a bi=
nary<br>
> file for alphanumeric sequences. It would be nice to opt to replace th=
em<br>
> with SHA hashes or the like, on a per-class or namespace basis.<br>
><br>
> namespace [[obfuscate]] {<br>
>=C2=A0 =C2=A0 =C2=A0class [[obfuscate]] secret_sauce {<br>
</div>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br>
<div class=3D"">>=C2=A0 =C2=A0 =C2=A0};<br>
> }<br>
><br>
> The attribute itself might not need standardization, it would just be =
nice<br>
> to see in an implementation. It could be a killer feature.<br>
><br>
> However, there is currently no attribute-specifier-seq in the namespac=
e<br>
> grammar. I think it should go into original-namespace-definition. Has =
this<br>
> already been considered, or is a DR appropriate?<br>
<br>
</div>This doesn't look like it needs to be standardised at all. The st=
andard<br>
doesn't require that typeinfo carry a readable name. It's only requ=
ired to be<br>
unique per type (the portable C++ ABI carries the mangled name).<br></block=
quote><div><br></div><div>The name isn't required to be unique per type=
.. =C2=A0An implementation may return the empty string for all types for exa=
mple, provided this behavior was documented. =C2=A0(See 18.7.1 [<a href=3D"=
http://type.info">type.info</a>])</div>
<div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf303e9e90e650c905010bca63--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 20 Aug 2014 18:01:14 +0800
Raw View
--Apple-Mail=_F210B3A5-38C8-4E7C-9B7F-671AD68BED9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-20, at 3:27 PM, Thiago Macieira <thiago@macieira.org> wrote:
> This doesn't look like it needs to be standardised at all. The standard=
=20
> doesn't require that typeinfo carry a readable name. It's only required t=
o be=20
> unique per type (the portable C++ ABI carries the mangled name).
The standard also requires no attributes on namespaces.
I already mentioned that the attribute could otherwise be a conforming exte=
nsion.
Actually, to be thorough, it's the mangled name that should be replaced wit=
h a hash. Object and function names still get exposed by shared libraries. =
This wouldn't work well on implementations that require shared library expo=
rts to be specified as a list of mangled names, but that's poor QOI anyway.
On 2014-08-20, at 4:57 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> The name isn't required to be unique per type. An implementation may ret=
urn the empty string for all types for example, provided this behavior was =
documented. (See 18.7.1 [type.info])
Perhaps, but an implementation providing for hashes of user-specified lengt=
h could allow the length to be zero and then emit empty strings. I suppose =
it depends on how the RTTI implementation uses the strings, for example for=
type_info::before. If it really can tolerate absence of string data, then =
that would be an optimal solution.
Anything besides the common ABI is a no-go without some way to opt in. On s=
econd thought, extern "C++ obfuscated" would also do the trick, but I think=
attributes are preferable.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_F210B3A5-38C8-4E7C-9B7F-671AD68BED9E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–20, at 3:27 PM, Thiago Macieira <<a href=3D"mailto:thiago=
@macieira.org">thiago@macieira.org</a>> wrote:</div><br class=3D"Apple-i=
nterchange-newline"><blockquote type=3D"cite">This doesn't look like it nee=
ds to be standardised at all. The standard <br>doesn't require that typeinf=
o carry a readable name. It's only required to be <br>unique per type (the =
portable C++ ABI carries the mangled name).<br></blockquote></div><div><br>=
</div>The standard also requires no attributes on namespaces.<div><br><div>=
I already mentioned that the attribute could otherwise be a conforming=
extension.</div></div><div><br></div><div>Actually, to be thorough, it&rsq=
uo;s the mangled name that should be replaced with a hash. Object and funct=
ion names still get exposed by shared libraries. This wouldn’t work w=
ell on implementations that require shared library exports to be specified =
as a list of mangled names, but that’s poor QOI anyway.</div><div><br=
></div><div><br></div><div><div>On 2014–08–20, at 4:57 PM, Andr=
ew Tomazos <<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gma=
il.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockqu=
ote type=3D"cite"><div dir=3D"ltr">The name isn't required to be unique per=
type. An implementation may return the empty string for all types fo=
r example, provided this behavior was documented. (See 18.7.1 [<a hre=
f=3D"http://type.info/">type.info</a>])<br><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"></div></div></div></blockquote></div><div><div dir=3D=
"ltr"><br></div></div><div dir=3D"ltr">Perhaps, but an implementation provi=
ding for hashes of user-specified length could allow the length to be zero =
and then emit empty strings. I suppose it depends on how the RTTI implement=
ation uses the strings, for example for <font face=3D"Courier">type_info::b=
efore</font>. If it really can tolerate absence of string data, then that w=
ould be an optimal solution.</div><div dir=3D"ltr"><br></div><div dir=3D"lt=
r">Anything besides the common ABI is a no-go without some way to opt in. O=
n second thought, <font face=3D"Courier">extern "C++ obfuscated"</font> wou=
ld also do the trick, but I think attributes are preferable.</div><div dir=
=3D"ltr"><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_F210B3A5-38C8-4E7C-9B7F-671AD68BED9E--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Aug 2014 08:38:03 -0500
Raw View
On Wednesday 20 August 2014 18:01:14 David Krauss wrote:
> On 2014-08-20, at 3:27 PM, Thiago Macieira <thiago@macieira.org> wrote:
> > This doesn't look like it needs to be standardised at all. The standard
> > doesn't require that typeinfo carry a readable name. It's only required to
> > be unique per type (the portable C++ ABI carries the mangled name).
>
> The standard also requires no attributes on namespaces.
>
> I already mentioned that the attribute could otherwise be a conforming
> extension.
>
> Actually, to be thorough, it's the mangled name that should be replaced with
> a hash. Object and function names still get exposed by shared libraries.
> This wouldn't work well on implementations that require shared library
> exports to be specified as a list of mangled names, but that's poor QOI
> anyway.
> On 2014-08-20, at 4:57 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> > The name isn't required to be unique per type. An implementation may
> > return the empty string for all types for example, provided this behavior
> > was documented. (See 18.7.1 [type.info])
> Perhaps, but an implementation providing for hashes of user-specified length
> could allow the length to be zero and then emit empty strings. I suppose it
> depends on how the RTTI implementation uses the strings, for example for
> type_info::before. If it really can tolerate absence of string data, then
> that would be an optimal solution.
>
> Anything besides the common ABI is a no-go without some way to opt in. On
> second thought, extern "C++ obfuscated" would also do the trick, but I
> think attributes are preferable.
External names are not part of the C++ standard. So let's forget everything
about symbols here.
I think the only thing we can take out of your proposal here is that
attributes should be allowed on namespaces.
Everything else is going to be compiler- and ABI-specific.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 21 Aug 2014 06:53:40 +0800
Raw View
--Apple-Mail=_0ACED293-FCCB-40BB-9E9F-B464D163DBEE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-20, at 6:01 PM, David Krauss <potswa@gmail.com> wrote:
> Anything besides the common ABI is a no-go without some way to opt in. On=
second thought, extern "C++ obfuscated" would also do the trick, but I thi=
nk attributes are preferable.
On third thought, namespace attributes are little better than linkage speci=
fication in this case. If only the original-namespace-definition is adjuste=
d, then the user needs to ensure that the namespace is always initially int=
roduced by a particular header. This is different from current usage of nam=
espaces and headers. The problem that occurs if the user doesn't do so, and=
never mentions the attribute in one TU, would be an additional case for th=
e ODR which currently doesn't mention namespaces.
On the other hand, linkage specifications cause implementation-defined beha=
vior and apply to all enclosed declarations. Applying differently in one TU=
would violate the ODR, but you would just bracket all the headers with the=
linkage-specification anyway, just inside the include guard and the namesp=
ace.
They might have a bad rep, and use of the extern keyword is somewhat unfort=
unate, but it's the best semantic match. The biggest real problem with link=
age specification is the implication of language linkage in function types,=
which creates pointer incompatibility. However, there's no need for that i=
n this case, and identical language linkage between "C++" and "C++ obfuscat=
ed" is within the latitude of implementation-defined behavior.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_0ACED293-FCCB-40BB-9E9F-B464D163DBEE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–20, at 6:01 PM, David Krauss <<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>> wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;">Anything besides the common ABI is a no-go with=
out some way to opt in. On second thought,<span class=3D"Apple-converted-sp=
ace"> </span></span><font face=3D"Courier" style=3D"font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px;">extern "C++ obfuscated"</font><s=
pan style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px; float: none; display: inline !important;"><span class=
=3D"Apple-converted-space"> </span>would also do the trick, but I thin=
k attributes are preferable.</span></blockquote></div><br><div>On third tho=
ught, namespace attributes are little better than linkage specification in =
this case. If only the <i>original-namespace-definition</i> is adjusted, th=
en the user needs to ensure that the namespace is always initially introduc=
ed by a particular header. This is different from current usage of namespac=
es and headers. The problem that occurs if the user doesn’t do so, an=
d never mentions the attribute in one TU, would be an additional case for t=
he ODR which currently doesn’t mention namespaces.</div><div><br></di=
v><div>On the other hand, linkage specifications cause implementation-defin=
ed behavior and apply to all enclosed declarations. Applying differently in=
one TU would violate the ODR, but you would just bracket all the headers w=
ith the <i>linkage-specification</i> anyway, just inside the include guard =
and the namespace.</div><div><br></div><div>They might have a bad rep, and =
use of the extern keyword is somewhat unfortunate, but it’s the best =
semantic match. The biggest real problem with linkage specification is the =
implication of language linkage in function types, which creates pointer in=
compatibility. However, there’s no need for that in this case, and id=
entical language linkage between <font face=3D"Courier">"C++"</font> and <f=
ont face=3D"Courier">"C++ obfuscated"</font> is within the latitude of impl=
ementation-defined behavior.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_0ACED293-FCCB-40BB-9E9F-B464D163DBEE--
.
Author: sairony@gmail.com
Date: Tue, 26 Aug 2014 01:35:26 -0700 (PDT)
Raw View
------=_Part_1096_754632152.1409042127076
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Den onsdagen den 20:e augusti 2014 kl. 09:18:39 UTC+2 skrev David Krauss:
>
> std::typeinfo::name strings tend to carry a lot of potentially secret=20
> information about a program=E2=80=99s implementation, and they can bloat =
an=20
> executable as well. I don=E2=80=99t know of any way to strip them, but th=
ey=E2=80=99re=20
> easily accessible by the Unix strings command or just by grepping a binar=
y=20
> file for alphanumeric sequences. It would be nice to opt to replace them=
=20
> with SHA hashes or the like, on a per-class or namespace basis.
>
> namespace [[obfuscate]] {
> class [[obfuscate]] secret_sauce {
> =E2=80=A6
> };
> }
>
> The attribute itself might not need standardization, it would just be nic=
e=20
> to see in an implementation. It could be a killer feature.
>
> However, there is currently no *attribute-specifier-seq* in the namespace=
=20
> grammar. I think it should go into *original-namespace-definition*. Has=
=20
> this already been considered, or is a DR appropriate?
>
>
I've always missed a flag for stripping the strings out. Some generic=20
techniques tends to really bloat the executable with all these non portable=
=20
strings which seems to mostly be used for debugging anyway. Although this=
=20
is more an issue with toolchains rather than the standard.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_1096_754632152.1409042127076
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Den onsdagen den 20:e augusti 2014 kl. 09:18:39 UT=
C+2 skrev David Krauss:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div st=
yle=3D"word-wrap:break-word"><div><font face=3D"Courier">std::typeinfo::nam=
e</font> strings tend to carry a lot of potentially secret information abou=
t a program=E2=80=99s implementation, and they can bloat an executable as w=
ell. I don=E2=80=99t know of any way to strip them, but they=E2=80=99re eas=
ily accessible by the Unix strings command or just by grepping a binary fil=
e for alphanumeric sequences. It would be nice to opt to replace them with =
SHA hashes or the like, on a per-class or namespace basis.<br><div><div><br=
></div><div><font face=3D"Courier">namespace </font><span style=3D"fon=
t-family:Courier">[[obfuscate]]</span><span style=3D"font-family:Courier">&=
nbsp;</span><span style=3D"font-family:Courier">{</span></div></div></div><=
div><font face=3D"Courier"> class [[obfuscate]] secret_sauce {=
</font></div><div><font face=3D"Courier"> =E2=80=
=A6</font></div><div><font face=3D"Courier"> };</font></div><d=
iv><font face=3D"Courier">}</font></div><div><br></div><div>The attribute i=
tself might not need standardization, it would just be nice to see in an im=
plementation. It could be a killer feature.</div><div><br></div><div>Howeve=
r, there is currently no <i>attribute-specifier-seq</i> in the namespace gr=
ammar. I think it should go into <i>original-namespace-definition</i>. Has =
this already been considered, or is a DR appropriate?</div><div><br></div><=
/div></blockquote><div><br></div><div>I've always missed a flag for strippi=
ng the strings out. Some generic techniques tends to really bloat the execu=
table with all these non portable strings which seems to mostly be used for=
debugging anyway. Although this is more an issue with toolchains rather th=
an the standard.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1096_754632152.1409042127076--
.