From eef51ab593845f232ec5cc120e3fe0eccc4741ed Mon Sep 17 00:00:00 2001 From: anarcat Date: Wed, 21 Mar 2018 09:41:19 -0400 Subject: [PATCH] Added a comment: some clarifications --- ..._79007506e4b771100c524e604e10bac7._comment | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_7_79007506e4b771100c524e604e10bac7._comment 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 index 000000000..158247f93 --- /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... +"""]]