From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19085 invoked by alias); 10 Apr 2010 08:52:54 -0000 Received: (qmail 19075 invoked by uid 22791); 10 Apr 2010 08:52:54 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_00,SARE_WEOFFER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 10 Apr 2010 08:52:49 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id o3A8oBXC011427; Sat, 10 Apr 2010 10:50:11 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id o3A8oAq8009927; Sat, 10 Apr 2010 10:50:10 +0200 (CEST) Date: Sat, 10 Apr 2010 08:52:00 -0000 Message-Id: <201004100850.o3A8oAq8009927@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: stan@codesourcery.com CC: gdb-patches@sourceware.org In-reply-to: <4BBFA9E1.1020609@codesourcery.com> (message from Stan Shebs on Fri, 09 Apr 2010 15:27:45 -0700) Subject: Re: [RFC] Add login to remote protocol References: <4BBFA9E1.1020609@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00299.txt.bz2 > Date: Fri, 09 Apr 2010 15:27:45 -0700 > From: Stan Shebs > > This patch is somewhat more specialized than the tracepoint stuff, but > may be of wider interest, so we offer it for your consideration. It > adds a login capability to the remote protocol; the user sets a username > and password in GDB, then upon connection to a target that requires > them, GDB supplies the two. It is completely up to the target what do > with them, for instance it could simply close the connection in response > to a bad login. > > The design is simple, and not especially secure, as the password is sent > in the clear - it's mostly appropriate for direct connections or secured > intranets. We don't do anything to conceal the password from the > console, but one could add a non-echoing reader, and write a password > show that kept it concealed. Sorry, but I think that an authentication protocol that sends passwords in cleartext is worse than no authentication at all.