1 |
W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller |
2 |
napisał: |
3 |
> > > > > > On Sat, 28 Oct 2017, Michał Górny wrote: |
4 |
> > > > The Manifest files can also specify ``IGNORE`` entries to skip |
5 |
> > > > Manifest verification of subdirectories and/or files. Files and |
6 |
> > > > directories starting with a dot are always implicitly ignored. |
7 |
> > > > All files that are not ignored must be covered by at least one |
8 |
> > > > of the Manifests. |
9 |
> > > |
10 |
> > > Do we need to keep that implicit ignore rule? Rather, convert it |
11 |
> > > to being always explicit. |
12 |
> > > |
13 |
> > > There is only one such file in the rsync checkout presently: |
14 |
> > > metadata/.checksum-test-marker (see bug #572168, it is used to |
15 |
> > > detect mis-configured mirrors). |
16 |
> > > |
17 |
> > > A SVN or Git repo might also have dot-named directories. |
18 |
> > I like the implicit idea better as it is more consistent with normal |
19 |
> > tool behavior, like 'ls' not listing the files. Dotfiles can be |
20 |
> > created by many random tools or even the filesystem (especially in |
21 |
> > some cases of overlay filesystems). |
22 |
> |
23 |
> Other tools like "find" don't special-case dot-prefixed files though |
24 |
> (in fact, "ls" may well be the exception there). |
25 |
> |
26 |
> Implicit ignores only create an unnecessary attack surface. Better |
27 |
> make them explicit, even if this will require adding some entries for |
28 |
> common cases (like .git in the top-level dir). |
29 |
> |
30 |
|
31 |
I dare say it's not an attack surface if tools are explicitly directed |
32 |
not to use those files. The problem is, you can't predict all possible |
33 |
dotfiles and even if you do, you're effectively blocking the user from |
34 |
creating any files for his own use. |
35 |
|
36 |
Say, if user wanted to use git on top of rsync for his own purposes, why |
37 |
would you prevent him from doing that? |
38 |
|
39 |
-- |
40 |
Best regards, |
41 |
Michał Górny |