On 8 Sep 2026, at 21:48, Daniel Sahlberg <[email protected]> wrote: > > Den tis 8 sep. 2026 kl 21:43 skrev C. Michael Pilato <[email protected] > <mailto:[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. 😂 >
Noted! Thanks! > 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! As an update from Simonsoft's perspective, I went far down the LUA rabbit hole. In a good way. We needed a solution that could ship this November on an existing fleet of instances and I believe we will meet that requirement with the LUA approach. So there is no pressure from our side. We are now invested in the LUA path forward. The implementation is open-source but I have no time to announce it right now. It relies on the XML directory listing from mod_dav_svn (it must never be removed...), stream-parses the XML and outputs an HTML response (highly customizable with a set of mustache templates). >> >> On Tue, Sep 8, 2026 at 3:35 PM Branko Čibej <[email protected] >> <mailto:[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. >>> I entirely agree with 'SVNIndexHeadInclude' as described. I have a couple of additional class suggestions based on recent work. Highest priority (as earlier in thread): - 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) Medium priority: - class on body element, one of: svn-collectionofrepositories / svn-repositoryroot / svn-repository (or something like that, useful to know when listing is at the root of the repo) - class to indicate if the request was for a specific revision vs head (in order to easily hide / display revision indicator etc using plain CSS) >>> 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? The XSLT feature can do the same harm so the same type of disclaimer makes sense. >>> >>>> On Thu, Jul 23, 2026 at 8:42 AM Daniel Sahlberg >>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> Den tors 23 juli 2026 kl 13:56 skrev C. Michael Pilato >>>>> <[email protected] <mailto:[email protected]>>: >>>>>> On Thu, Jul 23, 2026 at 3:07 AM Daniel Sahlberg >>>>>> <[email protected] <mailto:[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 >>>>> >>>>> >>>
