Den tis 8 sep. 2026 kl 21:43 skrev C. Michael Pilato <[email protected]>:
> Or, we can read further up this thread to find the single organization > that made use of the XSLT stuff at all and warn them individually. 😂 > I'm sure someone can vibe code an AI agent that will automatically reply to any AI generated bug/security reports concerning this feature. But jokes aside, I Mike's suggestion make sense. Just need to move to Mars to get a few hours more per day. Thanks for bringing it up again! /Daniel > > On Tue, Sep 8, 2026 at 3:35 PM Branko Čibej <[email protected]> wrote: > >> On 8. 9. 2026 20:13, C. Michael Pilato wrote: >> >> So, perhaps `SVNIndexHeadInclude` (to indicate where this include is >> getting injected), and yes I think it sufficient to just replicate the >> option value inside the <head> element as-is. That, combined with the >> aforementioned <div> wrapper and meaningful classes/ids, would let someone >> source a CSS file or JS script or whatever, make stuff pretty, futz with >> the DOM, etc. >> >> >> As long as we add a big fat red flashing notice that all the bugs and >> vulnerabilities arising from slurping JS into a plain ol' directory listing >> are not our problem. I mean, it's a given that someone, somewhere is going >> to inject supply-chained malware into their private closed-source repo. >> Right? >> >> -- Brane >> >> >> On Thu, Jul 23, 2026 at 8:42 AM Daniel Sahlberg < >> [email protected]> wrote: >> >>> Den tors 23 juli 2026 kl 13:56 skrev C. Michael Pilato < >>> [email protected]>: >>> >>>> On Thu, Jul 23, 2026 at 3:07 AM Daniel Sahlberg < >>>> [email protected]> wrote: >>>> >>>>> Just from skimming through the docs it looks promising. If you can >>>>> make it work, I'd really love to put that into the FAQ (and probably as a >>>>> news item as well). >>>>> >>>>> >>>> I still think we should at least entertain the most low-hanging of the >>>> requested fruit. I mean, it would probably take less time and effort than >>>> this conversation has to add some decoration to mod_dav_svn's HTML output >>>> that would have no effect on the visual representation of the directory >>>> listing, but provide better "hooks" into the DOM for folks to tap into. >>>> Consulting the list previously requested, these two are the least >>>> disruptive in my opinion: >>>> >>>> - class/id on list, class on list items preserving whether item is >>>> dir/file/repository >>>> - wrap list in div (would allow a flex layout without JS DOM >>>> manipulation, easy to insert a sibling to the list using HTMX) >>>> >>>> I again suggest that a simple SVNIndexCSS directive which optionally >>>> injects a stylesheet reference to the <head> of the output would be >>>> low-hanging enough to allow folks to make the list prettier. But I'm also >>>> not particularly keen to add esoteric features nobody has asked for. :-) >>>> >>> >>> I agree, except that I'd prefer naming it SVNIndexInclude to allow the >>> end user to insert whatever they want (<script>, <meta>, <style>, ...). >>> SVNIndexCSS seems a bit too limited, especially if it would only contain >>> the name of the CSS file (much like to SVNIndexXSLT) and just output the >>> URL in a <style> element. >>> >>> Is it enough to just dump the content of SVNIndexInclude into the HTML >>> output or do we also need the ability to load the content from a file? That >>> would make it an order of magnitude more complicated though (and I'm not >>> even suggesting being able to load the content from a repository URL...). >>> >>> Let's get 1.15.0 out of the box first and I can try to take a look. >>> >>> Cheers, >>> Daniel >>> >>> >>> >> >>
