From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id C2A1F1F453 for ; Thu, 8 Nov 2018 14:43:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726897AbeKIATj (ORCPT ); Thu, 8 Nov 2018 19:19:39 -0500 Received: from mail-wm1-f68.google.com ([209.85.128.68]:52529 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726541AbeKIATj (ORCPT ); Thu, 8 Nov 2018 19:19:39 -0500 Received: by mail-wm1-f68.google.com with SMTP id r11-v6so1520684wmb.2 for ; Thu, 08 Nov 2018 06:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version; bh=FeOUSfzSh/qYLXznVMPRk1H9ab9r4bZwN8Dclhmrkx0=; b=hNQqD5FHgwrnOzKHckdJxYHTJ9pSRID6WjyyTDSAuBP+FzR1BeADEKjFpNBrIZz1mi PPZYuTfHdaNnaWxElz2isMPuSJ0TKxODr1H/uHSMrJ8i8SBL03SbaDRUtFlbmFYWjTol uQLR5vIhyVWGI7ShBaMGN5gcKAHMPelhweRptKgRnJVTYcT7cT5rmZy3zdVWyOld0cbh lXoOSYlu07uJ6vxmCAT0hRLoj0cGPwe9SvlP2Ow5o6XfuagE1Z36IOJ0Aq398K6b9d4f WWpnDDUX9OpmQqZ/9wRjqHYnsC7JAToHIzIOS6gWOWOrJVgFtN6RvKSjfQ1f250ozmtF 1V3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version; bh=FeOUSfzSh/qYLXznVMPRk1H9ab9r4bZwN8Dclhmrkx0=; b=DKuWW/6TZsfYYCeFXrv9Bz75aBvUtVb+dkB3f5s95bSSh2ArONcewOR7l2E3CSMVgU CNUjBeH4IDoTtmFA6ooXdDtzgu5dKLfQfiL8CypIqE5Fh31HrB9ZP4PJxMMCdt2nrdOT D5/0OUGL8A6t6lIMniVGMrLDkhJvEDW/3W9eM8GoWbuw/9jIoA5kptIXy7ahAtji/RxD rjk5DUvmcWIrAatRDGlCdkZ+sol8KFrESqxZBbfoXipVmmq7GKaDkWJm8VivZ3jnEra2 TNUCHckk2dTgjCiUR201SAGbUjr6+neF6KYRr00Vo0WD9v8b465JtRN00jFZ1AuJbV/F nviw== X-Gm-Message-State: AGRZ1gKbCWRB+EG3FWYxsll+h35vOhtIs5jdLlQ8tJGTGzxh30/Wyf4Q Gp7YCosE54RvlL5LixkJVGADvnkTEO4= X-Google-Smtp-Source: AJdET5dOYkAcYDxiZKDZMZdiEWqbJH/fuIs+Otc+OOFTly7KbihlSF07EcRkSOZpo69QOce4gHjcZA== X-Received: by 2002:a1c:e355:: with SMTP id a82-v6mr1502341wmh.74.1541688229347; Thu, 08 Nov 2018 06:43:49 -0800 (PST) Received: from localhost (168.50.187.35.bc.googleusercontent.com. [35.187.50.168]) by smtp.gmail.com with ESMTPSA id m13-v6sm5139379wrw.14.2018.11.08.06.43.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 08 Nov 2018 06:43:48 -0800 (PST) From: Junio C Hamano To: Johannes Schindelin Cc: Ramsay Jones , Johannes Schindelin via GitGitGadget , git@vger.kernel.org Subject: Re: [PATCH 1/1] mingw: handle absolute paths in expand_user_path() In-Reply-To: (Johannes Schindelin's message of "Thu, 8 Nov 2018 14:04:17 +0100 (STD)") References: <2287dd96cf0b9e9e250fdf92a32dcf666510e67d.1541515994.git.gitgitgadget@gmail.com> <9174a750-3498-c2fc-d7fa-29c1926c95fc@ramsayjones.plus.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Date: Thu, 08 Nov 2018 23:43:47 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Johannes Schindelin writes: > Hi, > > On Thu, 8 Nov 2018, Junio C Hamano wrote: > >> I am tempted to say "///" might also be such a >> way, even in the POSIX world, but am not brave enough to do so, as I >> suspect that may have a fallout in the Windows world X-<. > > It does. //server/share is the way we refer to UNC paths (AKA network > drives). Shucks. That would mean the patch that started this thread would not be a good idea, as an end-user could already be writing "//server/share/some/path" and the code with the patch would see '/' that begins it, and start treating it differently than the code before the patch X-<. > Granted, this is a highly unlikely scenario, but I would feel a bit more > comfortable with something like > > /ssl/certs/ca-bundle.crt > > Of course, `` is *also* a perfectly valid directory name, > but I would argue that it is even less likely to exist than > `$RUNTIME_PREFIX` because the user would have to escape *two* characters > rather than one. Yes, and it is naturally extensible by allowing inside the special bra-ket pair (just like $OTHER_THINGS can be a way to extend the system if we used a special variable syntax). >> Are there security implications if we started allowing references to >> environment varibables in strings we pass expand_user_path()? > > Probably. But then, the runtime prefix is not even available as > environment variable... Ah, sorry. I thought it was clear that I would next be suggesting to add an environmet variable for it, _if_ the approach to allow env references turns out to be viable.