Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files

[Michał Górny]

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