> On Sep 18, 2026, at 10:26 PM, Brian Brombacher <[email protected]> wrote:
>
> Moving to misc@
>
>> On Sep 18, 2026, at 9:26 PM, Zack Newman <[email protected]> wrote:
>>
>>>
>>> Claiming that the OpenBSD implementation is “abandoned”, especially over a
>>> single commit that actually fixes a severe memory corruption bug, is a
>>> massive breach of basic mailing list etiquette. As I said, the driver has
>>> received over 40 commits since its initial implementation. The WireGuard
>>> reference implementation and protocol have been frozen from before the
>>> OpenBSD implementation was completed. This means we are 100% up-to-date
>>> and actively maintained.
>>
>> I’ll let Jason and the team reject my proposal and even ban me then for
>> “breaching” mailing etiquette, but I’m not going to let you make that
>> decision for them. If you’re right, then they won’t listen. I wasn’t super
>> passionate about it and was fairly polite.
>
> You violated bugs@ mailing list etiquette by trying to “escalate to the
> manager” at upstream for a simple bug that doesn’t need to involve anyone
> else. You lied about the repo being 5 years out of date.
I need to clear something up. Zack was referencing a 5 year old private Git
repo that WireGuard used during the initial implementation. He didn’t lie
about the code being 5 years out of date. He didn’t report the entire OpenBSD
in-tree implementation as Abandoned. I failed to follow his footnote and
assumed the worse.
I still stand by the fact that involving Jason for a passive audit instead of
trusting the OpenBSD developers is a waste of peoples time.
>
>>
>>> Did you even test any of the proposed patches?
>>
>> I proposed one patch, and no I didn’t test it because I don’t trust it at
>> all seeing how I don’t know C well. I was transparent in that regard.
>> Perhaps I should have been more explicit with “_seems_ fine”. It seems fine
>> on glancing at it but not actually testing it because I’m not going to trust
>> an LLM without being competent enough to have a good idea
>> if it’s correct.
>
> Both Bjorn and Claudio proposed patches. You even asked Bjorn if he tested
> his own code. I replied to your previous email almost simultaneously as your
> vibe coded patch showed up in my inbox. No, I do not want you to test your
> vibe coded patch. It introduced out of scope behavior (dropping packets) for
> absolutely no reason. I want you to test Claudio’s patch which “_seems_
> fine” to me and everyone else watching. Did you not see his email for some
> reason?
>
> Why did an AI agents vibe coded patch “_seem_ fine” but Claudio’s patch did
> not?
>
>>
>>> No, you didn’t. Your repro steps for IPv4 were also fundamentally flawed.
>>> You are trying to prove there is some other hidden ghosts but there aren’t
>>> any.
>>
>> Not at all. I didn’t want to assume that a padding bug was the only issue
>> since it didn’t seem to explain what I was seeing. I wanted to actually test
>> further before coming to an incorrect conclusion which is what I did. The
>> fact you are upset that I took more time to ensure the bug was isolated to
>> padding is suggestive you’re in a heightened emotional state, and I don’t
>> care to engage further.
>
> It didn’t seem to explain what you were seeing TO YOU. You tested further,
> in a flawed manner, and still came to an incorrect conclusion. You admitted
> your VPS provider was dropping IPv6 UDP fragments. You disregarded and
> specifically did not trust two OpenBSD developers for some reason. You are
> not the one to assume it’s a simple padding bug or not, the developers are
> responsible for determining the root cause and they did and they provided
> patches. They even told you it’s likely IPv6 UDP fragmentation that is the
> issue and some hypervisors drop those packets.
>
> I’m upset because you are wasting everyone’s time and then you have the
> absolute gall to “escalate to the manager” at upstream because you cannot
> trust the OpenBSD developers and you want to waste even more people’s time.
>
>>
>>> Either test the patch and return the results or tell us you cannot test it
>>> and someone else will.
>>
>> As stated above, I was transparent in that I let an LLM generate the code.
>> I’d hope you wouldn’t just trust that, but I should have been clearer that I
>> didn’t test it and am not willing to either since I’m not in a habit of
>> blindly trusting LLM-generated code. Should I have not even suggested a
>> commit at all then? Perhaps.
>
> No, you absolutely should not have vibe coded a patch. You should have
> tested the proposed patches you received, one of which you explicitly asked
> the developer if he tested his own code.
>
>>
>> Instead of letting @bugs get spammed with your rants, feel free to direct
>> the e-mail to me directly seeing how we are talking about “etiquette”. Do
>> you have a proposed patch for this bug?
>
> I’m not taking it private. I’m putting it on misc@ so you can be ashamed of
> your behavior.
>
> Go back in the mailing list archives and find Claudio’s email with the final,
> correct patch. You must have lost that email somehow in your inbox. Test
> the patch and return the results. If you cannot test, let us know so someone
> else can test it.
