From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Bengt Richter Newsgroups: gmane.lisp.guile.bugs Subject: bug#44186: Recursive mkdir Date: Sun, 25 Oct 2020 05:13:50 +0100 Message-ID: <20201025041350.GA14747@LionPure> References: <6ff632f5c1e378647cecc7177b7018fb8a0ee6d4.camel@divoplade.fr> <86sga420pw.fsf@gmail.com> <21802e695ea4472c8aba0a686e6bf025890c64d6.camel@divoplade.fr> <20201023233214.GA13637@LionPure> <1a7ae91ae083eecc3ab1043e8ed571bfe972c3a4.camel@divoplade.fr> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25949"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 44186@debbugs.gnu.org, zimoun To: divoplade Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Sun Oct 25 05:15:08 2020 Return-path: Envelope-to: guile-bugs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kWXQy-0006dW-1G for guile-bugs@m.gmane-mx.org; Sun, 25 Oct 2020 05:15:08 +0100 Original-Received: from localhost ([::1]:50394 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWXQw-0006v9-Hc for guile-bugs@m.gmane-mx.org; Sun, 25 Oct 2020 00:15:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34370) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWXQs-0006uz-LR for bug-guile@gnu.org; Sun, 25 Oct 2020 00:15:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52274) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kWXQs-0008Ti-CA for bug-guile@gnu.org; Sun, 25 Oct 2020 00:15:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kWXQs-0006Lq-6v for bug-guile@gnu.org; Sun, 25 Oct 2020 00:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bengt Richter Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 25 Oct 2020 04:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44186 X-GNU-PR-Package: guile Original-Received: via spool by 44186-submit@debbugs.gnu.org id=B44186.160359924724336 (code B ref 44186); Sun, 25 Oct 2020 04:15:02 +0000 Original-Received: (at 44186) by debbugs.gnu.org; 25 Oct 2020 04:14:07 +0000 Original-Received: from localhost ([127.0.0.1]:35587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWXPz-0006KS-Ep for submit@debbugs.gnu.org; Sun, 25 Oct 2020 00:14:07 -0400 Original-Received: from imta-37.everyone.net ([216.200.145.37]:47844 helo=imta-38.everyone.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kWXPw-0006KI-8X for 44186@debbugs.gnu.org; Sun, 25 Oct 2020 00:14:05 -0400 Original-Received: from pps.filterd (m0004962.ppops.net [127.0.0.1]) by imta-38.everyone.net (8.16.0.43/8.16.0.43) with SMTP id 09P48eZD021220; Sat, 24 Oct 2020 21:14:03 -0700 X-Eon-Originating-Account: lxIZI5taveL1L0P42vEY_6JXoxe3CU_AHdc_--ScGmg X-Eon-Dm: m0116953.ppops.net Original-Received: by m0116953.mta.everyone.net (EON-AUTHRELAY2 - 5a81c5ee) id m0116953.5f8a0276.9ad5e; Sat, 24 Oct 2020 21:14:00 -0700 X-Eon-Sig: AQMHrIJflPuIf4yaDwIAAAAD,be32293ee8e7769daf761c1a80a749c3 X-Eip: vJ9giD9QENz6dWi1QJrEsJTHwT2GbNBED835tvKLUug Content-Disposition: inline In-Reply-To: <1a7ae91ae083eecc3ab1043e8ed571bfe972c3a4.camel@divoplade.fr> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-25_01:2020-10-23, 2020-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 suspectscore=0 bulkscore=0 clxscore=1034 lowpriorityscore=0 mlxlogscore=884 spamscore=0 adultscore=0 priorityscore=1501 mlxscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010250029 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9908 Archived-At: Hi divoplade, On +2020-10-24 08:17:47 +0200, divoplade wrote: > Hello, > > Le samedi 24 octobre 2020 à 01:32 +0200, Bengt Richter a écrit : > > An alternate solution could be programmed using ffi, as documented in > > [1], n'est-ce pas? > To be clear, you would rather have that function as guile code rather > than extending the C function? I'm OK with that, but in which file > should I put that function? My instinct was to put the code near the > mkdir function, and that happened to be in a C file, so I went C. > Seems logical, and probably where I'd go, but please be careful! Don't make a C version of this hack: ┌───────────────────────────────────────────────────────────────────────────────┐ │ (define (my-mkdir-p path . ignore) (system (string-append "mkdir -p " path))) │ └───────────────────────────────────────────────────────────────────────────────┘ You can then write (my-mkdir-p "foo-dir/bar-dir") and it'll do the job. But it's definitely safer to skip the hack and write ┌─────────────────────────────────────┐ │ (system "mkdir -p foo-dir/bar-dir") │ └─────────────────────────────────────┘ and not give anything a chance to inject something bad via unsanitized parameters. E.g., ┌─────────────────────────────────────┐ │ (my-mkdir-p "here/below;tree here") │ │ here │ │ └── below │ └─────────────────────────────────────┘ It does the intended, so no suspicous change in that part, and my-mkdir-p looks innocent enough. (Did you notice the danger? ;) Well, introducing something like this, but more subtle, could be the first move by a mole working for to compromise or disrupt/discredit GNU FLOSS competition. Is that unhappy thought too paranoid? I hope so, but I'm not convinced ;/ > > What would guix best-practice guidance say about that? > I'm not sure to follow, now this is a guile matter, guix has nothing to > do about it. I'm sorry I messed a few things up with the mailing lists > (I should have listened to them, "don't cross the streams"). Could you > elaborate? > Sorry, you are right: it does become a guile matter, but... ... it also becomes part of guix if it's part of the guile version a guix version depends on, so thereby it becomes a guix quality/security item to be careful about. So I was wondering whether guix architects have preferences for where and how a function should be implemented, all things considered. > Best regards, > > divoplade > -- Regards, Bengt Richter