220 12526 <57defb73-7b74-4acc-9764-c4a3dc317976@isocpp.org> article Path: news.gmane.org!not-for-mail From: sairony@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Crypto-hash obfuscated namespaces Date: Tue, 26 Aug 2014 01:35:26 -0700 (PDT) Lines: 104 Approved: news@gmane.org Message-ID: <57defb73-7b74-4acc-9764-c4a3dc317976@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1096_754632152.1409042127076" X-Trace: ger.gmane.org 1409042139 21918 80.91.229.3 (26 Aug 2014 08:35:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Aug 2014 08:35:39 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD2MR2WMYUKBBT4N6GPQKGQESMJAZYY@isocpp.org Tue Aug 26 10:35:32 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XMCDx-0008Vt-E0 for gclcip-std-proposals@m.gmane.org; Tue, 26 Aug 2014 10:35:29 +0200 Original-Received: by mail-pa0-f70.google.com with SMTP id lf10sf126142212pab.9 for ; Tue, 26 Aug 2014 01:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=XFENHpuRTditTh19pfMUYLZ6xbB71YSklTyS+mEt4MA=; b=Wr9NO+cIlsfbAppYw71MFDYy0cMjw9TCJ5LZ7+fQP4p7Dnoj3akMpHKzFxkbP5h49V L/Y20avqa8RLlhNmU4v8XN2EA5y0Kx86aVbLwqkH+Ars7siVbKllQDZdysfe6OYisbkz SApDWvW/AXzLMkA7Tlo0yD9kStCj5Pnj323Q5HZo3pkQFoy1M92gHcJLjFQawIJv+QG1 k38utgAYfsVGWRIuUDm3SBHV7lANtt2d5WdWSbcVXVNe8rBPpFf2GN3zYnuDoXctJ21d nw/vv9oKS+LL76rOkWdiqUZW4V77A7bjihy7VdVUq+WCpBLXC0i1MMUe2cicy8dmK016 jrMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=XFENHpuRTditTh19pfMUYLZ6xbB71YSklTyS+mEt4MA=; b=ljvC0YcW85ABDlwdRXUS8KCSJ1GdYmIKHkxoYlm4QcAzTCNdzesnmsdH9YtRzf3zfl N7HCM9zU/J5qZtUPR/cpBeh2LbPUUjkJvIbor8uP7OxZnU7VZlM3ve/LMIVTA5AtMfIk qtlVyhZLgqL7MMBUABpvtHJPnZ9OGOZDYKkNMH7MmoyWnaVtoJdziLhCgqIJYo7zLKDW VSwQv+TRQxiZcc0OcWe5uQ8TU+9lS6LbTob4XvNa6Wqt3T5qWnCjMgPc8fFzvu2uiP1B oFpv1Hv8qRnDDzGJBZUO/f1cn0R1fV4JPbpPbc/OvVN6w5V47G32MAHULDbCnbBnxpSC dMDw== X-Gm-Message-State: ALoCoQlzrBwYJ6Vki/a62fSs8jGZjKYmv7qpKBn0LXmogs2S+IWuxRazGUY/DWbOLosrnv92LBrC X-Received: by 10.66.66.170 with SMTP id g10mr15512315pat.12.1409042128351; Tue, 26 Aug 2014 01:35:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.27.242 with SMTP id 105ls1008619qgx.17.gmail; Tue, 26 Aug 2014 01:35:27 -0700 (PDT) X-Received: by 10.140.93.181 with SMTP id d50mr497171qge.0.1409042127600; Tue, 26 Aug 2014 01:35:27 -0700 (PDT) In-Reply-To: X-Original-Sender: Sairony@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:12526 Archived-At: ------=_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


Den onsdagen den 20:e augusti 2014 kl. 09:18:39 UT= C+2 skrev David Krauss:
std::typeinfo::nam= e 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.
namespace [[obfuscate]]&= nbsp;{
<= div>    class [[obfuscate]] secret_sauce {=
       =E2=80= =A6
    };
}

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.

Howeve= r, there is currently no attribute-specifier-seq in the namespace gr= ammar. I think it should go into original-namespace-definition. Has = this already been considered, or is a DR appropriate?

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

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_1096_754632152.1409042127076-- .