From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Falk Dayaram Newsgroups: gmane.emacs.devel Subject: Re: Unifying network stream Date: Sat, 02 Jul 2011 12:49:13 +0200 Message-ID: <20110702104912.CAA1711BC6D@karen.lavabit.com> References: <64435.199.48.147.39.1309559515.squirrel@lavabit.com> <87pqlt5asw.fsf@keller.adm.naquadah.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1309603787 15166 80.91.229.12 (2 Jul 2011 10:49:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 2 Jul 2011 10:49:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 02 12:49:43 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qcxld-0005d4-Bk for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2011 12:49:41 +0200 Original-Received: from localhost ([::1]:38040 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qcxlb-0006PZ-RR for ged-emacs-devel@m.gmane.org; Sat, 02 Jul 2011 06:49:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:46845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcxlE-0006Od-Pu for emacs-devel@gnu.org; Sat, 02 Jul 2011 06:49:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcxlD-0003fI-2j for emacs-devel@gnu.org; Sat, 02 Jul 2011 06:49:16 -0400 Original-Received: from karen.lavabit.com ([72.249.41.33]:35256) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcxlC-0003fC-JL for emacs-devel@gnu.org; Sat, 02 Jul 2011 06:49:14 -0400 Original-Received: from e.earth.lavabit.com (e.earth.lavabit.com [192.168.111.14]) by karen.lavabit.com (Postfix) with ESMTP id CAA1711BC6D for ; Sat, 2 Jul 2011 05:49:12 -0500 (CDT) Original-Received: from 192.168.0.1 (iamthepants.net [193.110.157.152]) by lavabit.com with ESMTP id J0MGZ2RW0R7G for ; Sat, 02 Jul 2011 05:49:12 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=5p8y8D7nqfE16kY+7RnX2pJ2jZr41aNo/LTORUQ4pe77a+k9zu41RZ3Hah0P55rCMjMZxWxnMzrwo1kySdsOoqA9WBYuUVxWciI4kAle5RLWFxdhsCR3ZE0NK4ujJ0qPNuyQfSJtyC2/LbUlGN7FIsXyiP1f2Vpo5jIsJ8F9T4M=; h=From:To:Subject:In-Reply-To:References:iGcc:Mail-Followup-To:Date:MIME-Version:Content-Type; In-Reply-To: <87pqlt5asw.fsf@keller.adm.naquadah.org> (Julien Danjou's message of "Sat, 02 Jul 2011 10:47:11 +0200") iGcc: nnfolder+archive:sent-to-lists Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 72.249.41.33 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:141426 Archived-At: Julien Danjou writes: > On Sat, Jul 02 2011, falkdayaram@lavabit.com wrote: > >> Is there any chance this could be implemented in emacs 24? I am >> probably not the only one out here who uses an own network backend. > > Could you be more specific about what your patches do? Basically what they do is to create a real network process that is used for the actual communication (nc or gnutls-cli); and then setting up specific iptables rules for that process to forward the actual communcation to inhoise-specific exit nodes. In reality it is a lot more complicated, but thats out of the scope of this post ;) What I would like to see implemented in emacs 24 is that there is only one or two functions that may be used to open network streams. In particular, those functions are already there; open-network-stream and make-network-process. Unfortunately there is lots of lisp code which rather uses the actual backend interface functions (e.g. starttls-open-stream) rather than these neat high level function. Therefore I'd like to deprecate all these backend functions. Ultimately such a change allows easy management of emacs network stream by advising only those two high level functions. This is useful for redirecting connection like I do, but there are also tons of other usecases that may benefit from such a change; e.g. an inbuilt emacs firewall or central OCSP validation of tls connections, etc.