From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/72320 Path: news.gmane.org!not-for-mail From: Lars Magne Ingebrigtsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Password protection Date: Thu, 30 Sep 2010 19:17:46 +0200 Organization: Programmerer Ingebrigtsen Message-ID: References: <87sk0t3oxm.fsf@lifelogs.com> <87fwwszd1i.fsf@lifelogs.com> <87wrq4wcpc.fsf@lifelogs.com> <87tyl8xp7u.fsf@gmx.de> <87eiccw9ku.fsf@lifelogs.com> <87vd5nx5wa.fsf@gmx.de> <87tyl76v2k.fsf@lifelogs.com> <87d3rv6tya.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1285867084 6343 80.91.229.12 (30 Sep 2010 17:18:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 30 Sep 2010 17:18:04 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M20693@lists.math.uh.edu Thu Sep 30 19:18:03 2010 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1P1Mle-0004fr-SR for ding-account@gmane.org; Thu, 30 Sep 2010 19:18:03 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1P1Mld-00054R-SN; Thu, 30 Sep 2010 12:18:01 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P1Mlb-000542-KF for ding@lists.math.uh.edu; Thu, 30 Sep 2010 12:17:59 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P1MlX-0003Qp-Ay for ding@lists.math.uh.edu; Thu, 30 Sep 2010 12:17:59 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P1MlW-0001fL-00 for ; Thu, 30 Sep 2010 19:17:54 +0200 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1P1MlV-0004d7-Vk for ding@gnus.org; Thu, 30 Sep 2010 19:17:53 +0200 Original-Received: from cm-84.215.34.171.getinternet.no ([84.215.34.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Sep 2010 19:17:53 +0200 Original-Received: from larsi by cm-84.215.34.171.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 30 Sep 2010 19:17:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 53 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.215.34.171.getinternet.no Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEVLIARmJwoqFAAkEACd diQ0CQExFwE9GwInEwBOHQXb9tWfAAACUElEQVQ4jWWUsW7bMBCG6aKIkU0sDLvZ0ktBqFtrDVE3 KyDsB+gL2KxxymijhtiOlYCCYwx00dv2P1KOneZgyOJ94s/j8ZeUvoii+GJtZSfW2gcliWPK90Xx +QyK/yIQMTORgG8vQEuGjaPXM1qK8QqUIUCNDEDoTg8jKUOZxKrANRL8G6I2CAgAJCVIcAqiEEfK YOBi3iOaOIhSGAOZlD+RAfha0vsbpUZ25pMeK+9/pWf/Wq0tQHMCe1shveuPtprYSo1907AzAGhZ Nr5GD6V3FX5xDgCGN3jcxqZKzBLYRdBre4pq7C9AEkqxEK06rhGVziE7A/DHp+vJCyB78UpKHdkL JW1XwwzvDygrHXumVDVaYZE6tmTn/aLv+yeF8IdxWkNKq/1+lrhcV7KPBLg++Gbobe0nfAac8Tm2 S5aqnNzfTqVvOAo5GK4ikLOjjzianJJxHG3jzgnPuiwPXdmVba7FCGY6AF4/kICQh/tlgHk2EUBr 68RQYrbidwf33l6hu7JGRV0yXUgmNRE43ixpcGP8K4NZA6C0Q0PPUvFKmCKGWzDAJrswvFFiUSjR RmffkUqCJdHaQ+rg8nCVcoMicb0CWLm8SwW1ca2yhLxWvH1HuWTnoeU6kvAHnVQ8gVIXZdqZ7uVe ZqxVvXSUR0BG75dvcI+mYB9buP4ZbLNpPry4KsspxDW61ui3emruElHv8Zam8ufR1dpmoYYn1Af0 7x7OhUkBKtVw+RgCN+rTXdHdO/auKL4e9bTe/VyPlV08Xn4A5tT/eB68+jKc4h8qGFCeoM4P9QAA AABJRU5ErkJggg== Mail-Copies-To: never X-Now-Playing: Zazou, Bikaye & Cy1's _Noir et Blanc_: "Mangungu" User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:BB5ntMS68k8ZY2N2RHOmRKVb/Qk= X-Spam-Score: -1.9 (-) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:72320 Archived-At: Ted Zlatanov writes: > But then you won't be able to pass the secret tokens around or examine > their hashes. Those are valuable tools for debugging and building more > functionality around the secret tokens. Generally I'd rather > encapsulate secrets safely than make them inaccessible. It has debugging value, but since you're not going to be able to ever actually see their real value in the Lisp layer, but have to write special C functions to do anything with them, I think it has low value otherwise. So it mainly has all the drawbacks connected with introducing a new type. If you wish to have some debuggability, you can just have a function like `(secret-credential-hash "imap.gmail.com" "imaps" "password")' to return a hash of the "password" secret that's stashed, and you don't need any new type. > Your example would not change. I think it could be: > > (let ((password (make-secret "hello"))) > (format "%s" password) ; #SECRET#abc123 is the unique one-way hash > (process-send-string ... password) ; sends the password > (process-send-string ... #SECRET#abc123) ; sends the password also > (process-send-string ... (format "%s" #SECRET#abc123)) ; sends the externally useless hash > (debug password)) ; shows #SECRET#abc123 > > So only process-send-string and C code would be able to look inside a > secret token. It will complicate the example code a tiny bit. No, I don't think that'd actually work. To take an example: Passwords in IMAP needs to be utf7-imap-encoded and quote-treated. (I think.) So if you have the password "hello "&" goodbye", you need to do the following transform: (format "%S" (utf7-encode password) t) and what gets sent will be "hello \"&utf7-thing\" goodbye" Oh. Hm. But that won't work with my simpler process-send-password thing either. I had thought of the transform (because if you send basic auth, you need to base64-encode the stuff first), but Fbase64_encode_string is a C string, so I though you could just send a transform down, too. But here you have Lisp-level functions like utf7-encode being called... I don't think this is as simple as any of us thought. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen