ElGamal says he uses them interchangeably. He says TLS exists for historical reasons, but the essence of the technology is the same. I got into the habit of using SSL/TLS.
> If that person found another problem with Caddy, I think they are less likely to report it to you because of this.
Given they're aware of previous discussion and the stance on the feature request, I don't think they're deterred by the discussion here. Your addition of fuel to fire here is the very thing that's not helping.
> If they did report it, I would think you are very likely to dismiss it because of who they are, not the contents of the bug report.
This is being blown out of proportion. You're discounting an entire project and your experience of the software over a person expressing exasperation over an inconsequential feature (not a bug) that even the author of curl had his run through and frustration. The request was not dismissed, rather it was discussed at length on our issue tracker. The OP knows it was discussed at length because they linked to the discussion thread in the earlier times they brought this up. Moreover, the way they presented it this time is snide, agree or not. To quote Matt's statement of the project being "stable and mature" just to say "except you didn't implement my niche feature" (yes, editorialized) is not criticism nor a feature request. It's veiled instigation hiding behind plausible deniability.
Anyways, on the feature request, Caddy is not the only software who disagrees with it being valid, and curl had their back-and-forth on it. There's no legitimate bug being dismissed, and you can go through the issue tracker to audit it. Equating this discussion with 37signals or Signal is false equivalence.
It's a repeat complaint from the same person who admits bringing it up before. The way they framed their complaint is, again, snide.
> That’s a long way beyond exasperation, that’s a massive overreaction.
Your reaction to Francis is _the_ overreaction. Francis simply said to OP to put their money where their mouth is. The "slander" comment comes later as a general statement on why this subject has become annoying.
Stop being hung up on Francis' response. The niche feature was discussed at length multiple times. You're welcome to search the web for all the conversations we had on the subject. Caddy has been around for 11 years. We've seen this subject more than you've seen it brought up. Again, OP referenced the discussion on the issue tracker in one of the earlier times they brought it up. They _admit_ it's niche. What's the point of continuously bringing it up?
Okay, so the last time was 18 months ago not two years. But do you really think that mentioning it three times in 3.5 years can fairly be described as a grudge?
> Stop being hung up on Francis' response.
This is the only thing that matters to me in this thread. The bug itself is not that interesting. It’s a big deal to me that your team seems to take even the mildest mention of a bug as some kind of harassment. I’ve seen that kind of attitude before, and it’s dangerous.
Yes calling it a grudge is kneejerk, but no I won't apologize for it because of how intensely frustrating the prior discussions (and today's, no help to you) were to deal with (take today's, multiply it by two for the intensity, then multiply it by ten for the amount of times it happened). You aren't me, you don't know what I've experienced and you don't know all the details, so please stop making assumptions.
I imagine a pipeline between Calibre-Web[0] and audiobookshelf[1] going through Abogen, where Calibre-Web supplies the books, Abogen generates the audio version of it, and Audiobookshelf serves them. Great solution for the hearing impaired.
I'm not actively working on it daily, as I have shortage of free time and helping hands, but the HTTP Spec Test Suite is my Moby-Dick. I wrote about it here: https://www.caffeinatedwonders.com/2024/12/18/towards-valida..., I also discussed it on the HTTP WG mailing list and presented it at the HTTP WG Workshop last year.
They are both sort of an obsession and itches of mine, but between dayjob and school, I barely have a chance to have the clear mind to give them the attention they require.
That isn't true representative of Supabase. Tables respect RLS by default, unless turned off. This is how Supabase works. Views are not, and that is due to multiple reasons which Supabase documents. Supabase also warns the user of this and asks them to configure RLS properly for views by first changing the invoker. They also report the same issue to the user on their Security Advisor. The fix is as easy as running the SQL statement in the SQL Editor. Supabase also offers "Autofix" next to the warning, which tells the user exactly how to modify the CREATE VIEW statement to enable RLS.
It is a problem with Supabase as it's a problem inherent to RLS, and Supabase pushes very hard for RLS to increase adoption by non-technical users like the person who this article is about. You're right that they give lots of warnings to mitigate the issue but the people who they're targeting with RLS are exactly those who ignore them - see this post. This is nothing new and not a consequence of vibe coding. It's the contradiction between RLS being a technology that requires much more discipline to use securely compared to its alternative (a layer inbetween client and DB), yet is marketed and most used by beginners who lack the ability to maintain this.
> pushes very hard for RLS to increase adoption by non-technical users
We are tailoring what we're doing for this audience. The challenge is that they appeared out of nowhere about 6 months ago and the LLMs that are used by this audience is trained on 5 years of content tailored for developers
this is not an excuse, I'm just adding color. We've made a lot of changes with tools, alerts, email warnings etc. We are in planning-mode for changing defaults and working with the AI Builder platforms. We will likely change the schema configuration and advocate for Edge Functions (serverside Typescript) where appropriate.
I always wonder who/what checks if CAs respect CAA. I know some browsers now check the certificate transparency log, but are there any that check the CAA record against the issuer of the certificate?
I cannot find the source, but I saved this quote by Douglas Hofstadter about the process of writing, rewriting, and revising:
"It is the intensity of this process of global tightening and smoothing of a huge structure that was once implicit in one's mind but is now external and has its own unanticipated shape, life, and momentum, it is the power of this process of converting a set of once-intangible intuitions into a very tangible network of interconnected crystals, that I had forgotten."
Does it terminate existing connections and re-handshake when renewing the cert then? Or does it potentially hold many keys in memory for existing sessions? IIRC a TLS session can potentially last for a long time and 0-RTT depends on it being the same key, right? Couldn't find any answers in the docs: https://caddyserver.com/docs/caddyfile/directives/tls#reuse_...
The renewal of the key does not affect existing connections/sessions because they (the sessions) don't use the key directly. The private key is only used in the beginning to agree on the symmetric key, then the symmetric key is used from there onwards.
