From 03ee1c15fab6c734d0ce9e9e364f7e7ebea6774d Mon Sep 17 00:00:00 2001 From: smcv Date: Wed, 21 Mar 2018 05:30:41 -0400 Subject: [PATCH] Added a comment --- ..._f5eba98543b320773c334a0f39e2faa1._comment | 36 +++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_6_f5eba98543b320773c334a0f39e2faa1._comment diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_6_f5eba98543b320773c334a0f39e2faa1._comment b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_6_f5eba98543b320773c334a0f39e2faa1._comment new file mode 100644 index 000000000..b01b4f4c4 --- /dev/null +++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_6_f5eba98543b320773c334a0f39e2faa1._comment @@ -0,0 +1,36 @@ +[[!comment format=mdwn + username="smcv" + avatar="http://cdn.libravatar.org/avatar/0ee943fe632ff995f6f0f25b7167d03b" + subject="comment 6" + date="2018-03-21T09:30:41Z" + content=""" +> the \"source\" directory still have those broken symlinks, and those shadow the underlay + +Oh, you're using git-annex for the srcdir? The approach I'd vaguely had in mind was to +have an ordinary git repository with the Markdown/smaller assets/etc. as the srcdir, +and a parallel (no common commits) git-annex with larger assets (photos) as an underlay. + +I feel as though broken symlinks in the srcdir probably *should* shadow the underlay, +because otherwise there's nothing we can use as a \"white-out\" to suppress files from +the underlay. (But perhaps the canonical white-out should be a symlink to /dev/null, +as used in systemd.) + +In an ideal world, symlinks in the srcdir would be treated as the content that they +point to, if and only if the symlink is somehow \"safe\", with symlinks to non-pruned +files in the srcdir and symlinks to non-pruned files in .git/annex/objects/ +specifically being considered \"safe\". This is not yet that ideal world, because my +to-do list for ikiwiki is a lot longer than the time I can justify spending on it. + +I think this mechanism would need to be in terms of \"for page/attachment X (a +symlink), read file Y (the target of the symlink) instead of X\" determined +during scanning, rather than removing the `-l` check from `readfile()`, because +that `-l` check is a good safety-catch against implementation mistakes that +could lead to private file disclosure. + +> 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 + +Sorry, I am not going to review patches that relax the symlink security check unless I can +concentrate on them enough to be confident that I'm not introducing security vulnerabilities. +I realise this means that review has taken too long, but delays (even long ones) seem better +than CVEs. +"""]]