| Wow, thank you for taking the time to write such a detailed and in-depth critique. First, let me address the bugs you found, because you were 100% right.
The wget user-agent issue revealed a significant and regrettable flaw in the server-side logic. Thanks to your report, a fix has already been merged and deployed. The installer also had a conceptual flaw in its security recommendation, as you and others pointed out.
The documentation has been updated to recommend a two-step "download, then execute" process and now includes a direct link to the GitHub release asset for maximum transparency—no more "cute" domain magic as the primary method. Your trap DEBUG suggestion is a really powerful technique, and it highlights a core philosophical difference in how to approach this problem: Your approach is an "In-Flight Monitor"—it steps through an executing script and asks for permission at each step. It's fantastic for deep, real-time analysis. vet's approach is a "Pre-Flight Check"—its goal is to let a human review and approve a complete, static snapshot of a script before a single line of it ever executes. I chose the "pre-flight" path because diffing and shellcheck are central to the idea. They answer the questions: "I trusted this script last month, but has it changed at all since then?" and "Does this static code contain any obvious red flags?" The trap DEBUG method is powerful, but it can't answer that "what's changed?" question upfront and runs the risk of "prompt fatigue" on large installers, where a user might just start hitting 'y' to get through it. You've given me a lot to think about, especially on how to better articulate this philosophy. I sincerely appreciate you taking the time to teach and challenge the project. This is the kind of tough, expert feedback that makes open source better, and you've already had a direct, positive impact on it. |