| 1 |
>>>>> On Sat, 28 Oct 2017, Michał Górny wrote: |
| 2 |
|
| 3 |
> W dniu sob, 28.10.2017 o godzinie 14∶49 +0200, użytkownik Ulrich Mueller |
| 4 |
> napisał: |
| 5 |
>> Other tools like "find" don't special-case dot-prefixed files |
| 6 |
>> though (in fact, "ls" may well be the exception there). |
| 7 |
>> |
| 8 |
>> Implicit ignores only create an unnecessary attack surface. Better |
| 9 |
>> make them explicit, even if this will require adding some entries |
| 10 |
>> for common cases (like .git in the top-level dir). |
| 11 |
|
| 12 |
> I dare say it's not an attack surface if tools are explicitly |
| 13 |
> directed not to use those files. |
| 14 |
|
| 15 |
For example, an ebuild can apply all patches from a given directory. |
| 16 |
We certainly don't want any unaccounted dot-prefixed files being |
| 17 |
injected there. (And yes, globbing shouldn't normally match such |
| 18 |
files, but there's at least one eclass setting the dotglob option.) |
| 19 |
|
| 20 |
> The problem is, you can't predict all possible dotfiles and even if |
| 21 |
> you do, you're effectively blocking the user from creating any files |
| 22 |
> for his own use. |
| 23 |
|
| 24 |
Create files for their own use in random locations in the Gentoo |
| 25 |
repository? Why would anyone want to do that? |
| 26 |
|
| 27 |
> Say, if user wanted to use git on top of rsync for his own purposes, |
| 28 |
> why would you prevent him from doing that? |
| 29 |
|
| 30 |
As I said before, top-level .git should have an explicit IGNORE entry. |
| 31 |
|
| 32 |
IMHO we should rather stay on the safe side there, unless someone will |
| 33 |
speak up who has a concrete workflow where such dot-prefixed files |
| 34 |
with unpredictable names are needed. |
| 35 |
|
| 36 |
Ulrich |
Archives