Added a comment: some clarifications

diff --git a/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_7_79007506e4b771100c524e604e10bac7._comment b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_7_79007506e4b771100c524e604e10bac7._comment
new file mode 100644 (file)
index 0000000..158247f
--- /dev/null
+++ b/doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_7_79007506e4b771100c524e604e10bac7._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/825d3c30cb96a053b5335e51b8d0bd49"
+ subject="some clarifications"
+ date="2018-03-21T13:41:18Z"
+ content="""
+> 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.
+
+Yeah well, here I am using ikiwiki-hosting which sets up a standard set of repositories to push to. Here I push to `ssh://user@host/` and everything is magic after. So adding another repo would be quite clunky.
+
+> 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 understand I agree with that general design.
+
+> 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 do not believe I'm removing the -l check from readfile() in the latest patch. It *is* removed from `find_src_files`, but only as a strong armed measure: some more clever checks should be implemented there to check the targets... 
+
+> 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.
+
+Agreed. :) I don't mind the delay so much anymore, TBH... As I said, I've mostly given up and I assume something will either pop up by magic in the future or this will never happen. It's not like *I* have the time to \"concentrate on them enough to be confident that I'm not introducing security vulnerabilities\" as you so clearly put it: I probably don't have your grasp on the ikiwiki source so it makes my job even harder, but I should be able to figure out a better patch than `1 || -l` at this point. :p
+
+Anyways, I just wanted to provide a slight clarification on the workflow here...
+"""]]