Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We fixed f-string typos in popular Python repos

highertier.com

Post reply on HN
Print view View original

111–120 of 154 posts

Re: We fixed f-string typos in popular Python repos

#111

Post by oefrha »

colejohnson66 wrote: post #97
IshKebab wrote: post #72

Earlier quoted context omitted.

I feel the same way about those bots that tell you about insignificant security vulnerabilities in some project you abandoned. It's basically spam. That said, this does seem like it is a bit more useful. As long as they actually read the changes and make sure they aren't false positives. Which I'm guessing they didn't do for 666 repos.

> I feel the same way about those bots that tell you about insignificant security vulnerabilities in some project you abandoned. It's basically spam. If you "archive" your repos, dependabot and friends won’t bother you. Or, you could just disable security alerts in your repo's settings.

Dependabot isn’t the only source of vulnerability fatigue, there are plenty of “researchers” who would spam your active projects about pointless “vulnerabilities”. For instance, I recently got one about a parsing issue in gmp from a human user, who probably found it by scanning PyPI. I’m not touching anything adjacent to the supposedly vulnerable codepath, and the fix isn’t even in a gmp release, meaning I would have to carry a patch if I were to “fix” it. I still responded amicably, but I was not happy.

Re: We fixed f-string typos in popular Python repos

#112

Post by dataflow »

tus666 wrote: post #110
mhils wrote: post #69

We've been one of 666 repos, and I'm not too happy of having our repo used as advertising space. Some thoughts: - I'm happy to receive fix-a-typo PRs from human users. In this case the other side demonstrated that they care by putting in a bit of manual effort, and a small PR often paves the way towards larger contributions. I also know that open source beginners get really excited about their first small contributio…

Isn't having a public github repo consent?

Is having a publicly reachable email address consent to receiving unsolicited emails? Is having a public postal address consent to receiving mailed advertisements? Legally, yeah; morally, less so.

Re: We fixed f-string typos in popular Python repos

#113

Post by SquareWheel »

rglullis wrote: post #106
mschuster91 wrote: post #20

Earlier quoted context omitted.

So what? Raise a deprecation notice, treat it as a fatal error in two or three years and that's it. PHP has been doing this for years now.

PHP has also been responsible for the majority of exploited servers and misconfigured applications. Whatever they are doing it, I take it as a strong negative signal.

That's not unreasonable considering that PHP is by far the most popular server-side language. It's not like we have many hackers targeting Erlang instead.

Re: We fixed f-string typos in popular Python repos

#114

Post by dataflow »

mhils wrote: post #69

We've been one of 666 repos, and I'm not too happy of having our repo used as advertising space. Some thoughts: - I'm happy to receive fix-a-typo PRs from human users. In this case the other side demonstrated that they care by putting in a bit of manual effort, and a small PR often paves the way towards larger contributions. I also know that open source beginners get really excited about their first small contributio…

Sounds like we need a robots.txt for GitHub repos.

Re: We fixed f-string typos in popular Python repos

#115

Post by rglullis »

SquareWheel wrote: post #113
rglullis wrote: post #106

Earlier quoted context omitted.

PHP has also been responsible for the majority of exploited servers and misconfigured applications. Whatever they are doing it, I take it as a strong negative signal.

That's not unreasonable considering that PHP is by far the most popular server-side language. It's not like we have many hackers targeting Erlang instead.

It's out of proportion. Take as many Django/Rails/ASP.Net exploited sites that you find and it won't hold a candle to PHP.

Also, want to talk Java? Let's not forget that log4j was exploited precisely because of implicit string conversions.

Implicit f-strings are a really bad idea.

Re: We fixed f-string typos in popular Python repos

#116

Post by nomel »

fareesh wrote: post #24

I like python although I don't use it too often. Would it be unfairly critical of me to say that this is the outcome of a bad design choice? Ideally languages should be designed in a way that a bug like this which is so widespread and easy to create, should be caught via some mechanism, either linting or some part of the process.

To play devils advocate, that's a matter of perspective. There's nothing special about "{text}". It's just characters. One could claim that the default analysis should be "that's fine", with the option to make it special available with the "f". ;)

But, perhaps you're right, and the total number of bugs would be reduced with f-strings, but that would require making them default back in python 1.0.

The linter I use has warnings for things-that-look-like-f-strings on by default. But, some of my projects have f-string like text, so special text to tell the linter to ignore them are required all over the place.

Re: We fixed f-string typos in popular Python repos

#117

Post by minitech »

boxed wrote: post #67
MauranKilom wrote: post #23

Earlier quoted context omitted.

I don't think this makes sense. Plain strings and format strings are not interchangeable, and using one where the other was meant is probably a bug. Would you expect that a user input like "{secret} please" is interpolated? If so, we hopefully agree that this would blow major security holes into any python script processing untrusted user input. And if not... Why not?

Look up how this works in Swift. They only have one string. No raw strings or f strings. Yet they have all the power of all three python string types and less syntax. It's very nice.

Swift does have raw strings (the #"extended delimiter"# syntax).

Re: We fixed f-string typos in popular Python repos

#119

Post by jhardy54 »

Sebb767 wrote: post #109
TameAntelope wrote: post #91

Earlier quoted context omitted.

I just... think you should reconsider your stance on this. If you made a mistake in a public repo and someone else caught it (via scan of your repo or otherwise), it's a pretty bad look to be anything but grateful at that point, PR benefits for the bot aside.

The problem with scanners is that they usually have a pretty high false positive rate. When automatically opening the PR, they are basically putting the human review part on the maintainer (burdening them with additional and possibly useless work) while also using their repo as advertising space without consent. When the scan goes wrong and has a lot of false positives or it looks like they just got lucky, it's easy…

> The problem with scanners is that they usually have a pretty high false positive rate.

Did that happen in the example being discussed in this thread?

Re: We fixed f-string typos in popular Python repos

#120

Post by charlieyu1 »

Sebb767 wrote: post #109
TameAntelope wrote: post #91

Earlier quoted context omitted.

I just... think you should reconsider your stance on this. If you made a mistake in a public repo and someone else caught it (via scan of your repo or otherwise), it's a pretty bad look to be anything but grateful at that point, PR benefits for the bot aside.

The problem with scanners is that they usually have a pretty high false positive rate. When automatically opening the PR, they are basically putting the human review part on the maintainer (burdening them with additional and possibly useless work) while also using their repo as advertising space without consent. When the scan goes wrong and has a lot of false positives or it looks like they just got lucky, it's easy…

How high is the false positive rate? I would say even at 80%, the bots at least have found enough possible bugs that worth attentions that wouldn’t be found by human review only
Post reply on HN