bear454
commented
1 year ago Well, rambulance is a bad example to hang your hat on, there, as the main class is just 100 LOC and well documented - and I did read through it all myself. Secondly, we're using dependabot to analyze & report upstream security dependencies (I've been actively merging fixes into next and hope to have a better process for main after the current round of releases. Keep in mind as well that we actively limit the dependencies that are included in the distribution (nothing used exclusively for development or testing is included). IMO this is overall a good security policy, and yes it's what-about-ism, but this is better than the go projects that include source directly from github and compile them in. I hear you, though, and yes I agree that keeping the dependency stack small is a benefit; I don't add production gems on a whim.
HTTP error pages are now handled via rambulance, which is injected into the Rack stack well above most of the Rails content. By keeping things thin, we can present error pages that fit in much more effectively with our application, but with some limited dynamic content.
In order to resolve #119, in the event of a 500 error, a streamlined supportconfig is generated and offered for download as a static file (generated to the
/publicdir, so nginx can serve directly). The light supportconfig takes < 30s to run even on a t3.nano, so this is run synchronously instead of using a background job. If anything falls over during supportconfig generation, we generate a generic error page with the exception class & message, and a link to github issues for reporting.