> Putting my security hat on, I think that local DOS impact > is in the eye's of the beholder. For single user systems, > what you do to yourself is between the three of you. For > sites that support communities of which you have to > presume at least a few compromised credentials, even > a local DOS might be significant, or require actions. As > with all else, details matter (if anyone can do it with > a `/bin/ls` it is much more potentially impactful to a site > than if it requires a full moon, high tide, and a leap second > to reproduce). > > So I would suggest that even local DOS deserves advisories > (with any possible mitigations/workarounds), but not a > software release/patch (i.e. "addressed in a future release").
A variation of this comment: much of the complexity of deploying a fix is related to packaging. Investment in simplifying and automating the process of creating and deploying a new package would probably help somewhat with the pain level of creating a new release. The current build system is not helpful at all in that area. If you could trigger a new package generation and placement in a repository in various forms, I'd think that providing a patch would be more feasible. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
