doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_6_f5eba98543b320773c334a0f39e2faa1._comment

   1 [[!comment format=mdwn
   2  username="smcv"
   3  avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b"
   4  subject="comment 6"
   5  date="2018-03-21T09:30:41Z"
   6  content="""
   7 > the \"source\" directory still have those broken symlinks, and those shadow the underlay
   8
   9 Oh, you're using git-annex for the srcdir? The approach I'd vaguely had in mind was to
  10 have an ordinary git repository with the Markdown/smaller assets/etc. as the srcdir,
  11 and a parallel (no common commits) git-annex with larger assets (photos) as an underlay.
  12
  13 I feel as though broken symlinks in the srcdir probably *should* shadow the underlay,
  14 because otherwise there's nothing we can use as a \"white-out\" to suppress files from
  15 the underlay. (But perhaps the canonical white-out should be a symlink to /dev/null,
  16 as used in systemd.)
  17
  18 In an ideal world, symlinks in the srcdir would be treated as the content that they
  19 point to, if and only if the symlink is somehow \"safe\", with symlinks to non-pruned
  20 files in the srcdir and symlinks to non-pruned files in .git/annex/objects/
  21 specifically being considered \"safe\". This is not yet that ideal world, because my
  22 to-do list for ikiwiki is a lot longer than the time I can justify spending on it.
  23
  24 I think this mechanism would need to be in terms of \"for page/attachment X (a
  25 symlink), read file Y (the target of the symlink) instead of X\" determined
  26 during scanning, rather than removing the `-l` check from `readfile()`, because
  27 that `-l` check is a good safety-catch against implementation mistakes that
  28 could lead to private file disclosure.
  29
  30 > I wrote a patch to work around that issue, to make sure that security checks properly fallback to the underlay when there's a broken symlink
  31
  32 Sorry, I am not going to review patches that relax the symlink security check unless I can
  33 concentrate on them enough to be confident that I'm not introducing security vulnerabilities.
  34 I realise this means that review has taken too long, but delays (even long ones) seem better
  35 than CVEs.
  36 """]]