urosm
/
ikiwiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Added a comment: some clarifications

master
anarcat 2018-03-21 09:41:19 -04:00 committed by admin
parent 282dd87f2e
commit eef51ab593
1 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
doc/forum/An_assets_directory_for_my_wiki_with_git_lfs_or_annex__63__/comment_7_79007506e4b771100c524e604e10bac7._comment 100644
View File

@ -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...
"""]]