From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B6D601396D9 for ; Sat, 28 Oct 2017 20:56:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B0C20E0E98; Sat, 28 Oct 2017 20:55:28 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5C5A1E0E90 for ; Sat, 28 Oct 2017 20:55:28 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 0340733BF55; Sat, 28 Oct 2017 20:55:26 +0000 (UTC) Message-ID: <1509224123.17801.9.camel@gentoo.org> Subject: Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Sat, 28 Oct 2017 22:55:23 +0200 In-Reply-To: <23028.35393.310123.502062@a1i15.kph.uni-mainz.de> References: <1509048745.18656.6.camel@gentoo.org> <1509191446.1791.24.camel@gentoo.org> <23028.31950.417448.748747@a1i15.kph.uni-mainz.de> <1509197019.1791.27.camel@gentoo.org> <23028.35393.310123.502062@a1i15.kph.uni-mainz.de> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: bb69bc7a-106a-48af-b72a-f8635b077aaf X-Archives-Hash: 3171cdbf11355f9ba2abe2f660daa25d W dniu sob, 28.10.2017 o godzinie 15∶46 +0200, użytkownik Ulrich Mueller napisał: > > > > > > On Sat, 28 Oct 2017, Michał Górny wrote: > > W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller > > napisał: > > > Other tools like "find" don't special-case dot-prefixed files > > > though (in fact, "ls" may well be the exception there). > > > > > > Implicit ignores only create an unnecessary attack surface. Better > > > make them explicit, even if this will require adding some entries > > > for common cases (like .git in the top-level dir). > > I dare say it's not an attack surface if tools are explicitly > > directed not to use those files. > > For example, an ebuild can apply all patches from a given directory. > We certainly don't want any unaccounted dot-prefixed files being > injected there. (And yes, globbing shouldn't normally match such > files, but there's at least one eclass setting the dotglob option.) I think that's a really poor argument. Firstly, the mentioned eclass does it for one command call, and it doesn't go anywhere near the repository. So no, that doesn't count. Secondly, someone being able to theoretically cut himself with a spoon if he only sharpened its edge is no reason to forbid people from having spoons without explicitly written permission. > > The problem is, you can't predict all possible dotfiles and even if > > you do, you're effectively blocking the user from creating any files > > for his own use. > > Create files for their own use in random locations in the Gentoo > repository? Why would anyone want to do that? .DS_Store? ;-) > > Say, if user wanted to use git on top of rsync for his own purposes, > > why would you prevent him from doing that? > > As I said before, top-level .git should have an explicit IGNORE entry. Are we going to supply explicit IGNORE entries for any VCS anyone might choose to use? Or backup software and any other weird thing? > IMHO we should rather stay on the safe side there, unless someone will > speak up who has a concrete workflow where such dot-prefixed files > with unpredictable names are needed. I've already mentioned two. The first one were cheap union filesystems based on FUSE where I'm pretty sure I've seen random dotfiles. -- Best regards, Michał Górny