Lourenço

@lvales
1 Followers
10 Following
32 Posts
Hi there, this is Lourenço. I'm an economist by training, farmer by trade, nerd by passion. Here's a quick fact: the kiwifruit has one of the highest contents of vitamin C of all known fruits - even more than an orange!
Githubhttps://github.com/lourencovales
Excipiohttps://excipio.tech/
hey at least I already paid for a full year a few days ago
It's kind of wild to see the price of an existing VPS contract rise because "[f]or several months, the global memory shortage has been driving up hardware costs across the entire hosting industry." The economics of this make very little sense.
I'm tired. Really tired of this. They're turning a potential useful tool into a weapon of mass bullshit. This is dangerous, and we're all just smiling and waving, celebrating these morons who are "red pilling". This isn't going to end well.
This is the exact same thing that happened with cURL, and has led them to close their bug bounty program: https://curl.se/docs/bugbounty.html . It became infested with AI slop reports that follow this exact pattern: the AI spots some potential problem, claims CRITICAL VULNERABILITY!!!11, and the idiot at the wheel just goes along.
curl - Bug Bounty

But all this just goes to show what the actual problem here: this is just AI slop. Shame on the poster, a Google employee no less, that goes and uses a false report, that he didn't bother to check, to create a perception - in this case, how the AI-generated code is actually better than code that has been written by humans, and is production tested for several years.

Now, is this a _potential_ bug? Yes, if e.g. the goldmark package ever changes the way it processes its input and creates the possibility of the conversion erroring out, then it's possible for an attacker to craft a payload that could trigger this code path and exploit this XSS vulnerability.

And should the devs just have used `return template.HTML(escapedText)` in that code path? Also yes. Why they didn't, I'm not really sure. But it's besides the point.

The return inside the error checking is for the unescaped text, and ideally should use escapedText. But is it possible to even reach this situation? For that, the function utils.MarkdownToHTML() would need to error out.

And can it? No. Turns out the error checking is actually *dead code*. If you check how the goldmark package handles input, you could see that that it's not possible for this path to ever be reachable.

The problematic code is this:

```
func prepareTextForEmail(text, siteURL string) template.HTML {
escapedText := html.EscapeString(text)
markdownText, err := utils.MarkdownToHTML(escapedText, siteURL)
if err != nil {
mlog.Warn("Encountered error while converting markdown to HTML", mlog.Err(err))
return template.HTML(text)
}
return template.HTML(markdownText)
}
```

I saw this post on my feed, and caught my eye because I self-host a Mattermost instance. The fact that it has possible critical security issues is a concern for me. So I checked the github issue with the details: https://github.com/ncvgl/slawk/issues/107

Of course, it's fully LLM generated, but that's to be expected. So I opened the first issue described there, a *CRITICAL VULNERABILITY*, a possibility for XSS in email templates. Ok, sure, let's dig deeper.

The first week of our Open Letter to Keep Android Open has been a resounding success! Our signatories list has grown to nearly 50 organizations from 20 countries around the world, including the
@eff, @OpenMediaOrg, @brave, @Vivaldi, and many more!

https://keepandroidopen.org/open-letter/#signatories

An Open Letter to Google regarding Mandatory Developer Registration for Android App Distribution

Open Letter to Google Regarding Mandatory Developer Registration for Third-Party App Distribution