I'd say that depends on which languages you already know. Go is a smaller language in terms of syntax. No generics, not OO in the sense that it doesn't have classes and inheritance etc. But if you're familiar with the Java ecosystem and languages like Scala, or something like Swift or Rust, Kotlin should be easy to pick up.
I ran my own mail server using OpenSMTPD and Dovecot for a little over a year, and found OpenSMTPD to be very easy to set up and configure. I needed something light, that I could easily tweak to fit my needs. I mostly got things working reading the man files, and asking for help in the IRC channel (thanks Gilles). I also looked into Postfix, and I'm sure it's great, but the amount of configuration options were a bit daunting.
I think the project deserves more contributors and more eyes to look at the code. A fantastic foundation has been laid, but we can't expect Gilles to be able to do it all alone. This is a diamond in the making!
"we can't expect Gilles to be able to do it all alone"
Just like with GPG. In FOSS circles, there's all kinds of people that want to take the code but few to create it. So, people gripe about the state it's in while putting no effort in to improve it. At least the author contributes significantly. However, gotta wonder how many users it has vs how many are contributing code/audit.
Bet the difference has an impact on the situation. It's why I spend time here and there investigating proprietary, open-source models that require money or contributions to use the software. Doesn't even have be a lot: at least enough for a significant product to support at least one developer. That way the users are always investing into it and esp bug fixes happen.
gilles operates in a community where problems like this are taken very seriously, and where enough developer resources exist to sweep the smtp code base several times over.
I expect a lot of fixes coming up over the next few weeks.
The real problem is that the OpenBSD community didn't realise the state of things internally, because gilles and eric were trusted to not fuck up. This happens, since not everybody has time to follow every corner of the tree all the time. But when focus on a particular area is needed we can do it.
It's good that Jason pointed out these problems, however the manner in which this was done creates huge public exposure which puts pressure on all of us (especially gilles and eric) to produce results very quickly while we prefer moving slowly and being careful because that produces better results in the long term.
To be clear, I wasn't smearing any developers or the project relative to others. Just noting a common problem in OSS development that probably hurts their project to some degree.
Appreciate you adding detail on the project's situation. Also on how you all view the post and its effects. As HN gets exposure, do you a specific, alternative approach for anyone reading that might end up Jason's shoes to get the OpenBSD team focused on a particular project and digging into it? I'm guessing he didn't make an attempt outside the public disclosure or made an ineffective one.
Find out who's been involved with the area of the code base recently, and mail all their @openbsd.org addresses directly in one mail.
If they don't reply after a few attempts, or give unsatisfactory answers, try mailing Theo. He acts as arbitrator in such situations.
If even that doesn't help, your last option is to write good fixes yourself, and keep submitting them as diffs to tech@ until you're either banned from posting to the list (at which point you should just give up) or your diffs end up being commited.
That's crystal clear: now anyone reading knows the best approach. Makes sense, too. Except that last part.
I agree it's the best option to rollup the sleeves and just fix the problem you're griping about. However, a write-up like Jason's is a valid option, too, if person doesn't have time/resources/skill for that option. Because, at that point, known issues would've been ignored by everyone up to Theo despite it being in default install and under OpenBSD's quality image. A write-up drawing attention to the issue would be justified to prevent users from placing unjustified trust in that component. Being informed lets them take action either on improving the component themselves, limiting damage it could do, or just avoiding it altogether.
Still agree that the gripe should go to the developers and Theo first.
But Jason did send diffs, and we are discussing his situation as an example.
Anyway, like it or not, in the OpenBSD community, working diffs, especially ones that fix a security issue, are the best way of winning an argument. You can try to blog about it but you probably won't be taken as seriously. So if you really care to convince the community from the outside and everything else has failed, and you can't code C youself, find a friend who can and ask for help.
I tried OpenSMTPD / Dovecot for an environment with about 120 e-mail accounts (even promised to write it up afterwards). It just didn't quite work out. Filtering was a pain and it crashed a couple of times. I switched back to Postfix since I know its configuration pretty well.
On the other hand, as shipped, I have had no problems with it on non-mail server. I will probably try again next time I need to revise my mail server.
I like the concept and some attributes of it. Some good ideas might come out of those projects. The thing I can't overemphasize here, though, is that this kind of application might be attacked or just fail in many ways. So, whatever people do, they need to keep the main functionality simple for human and/or machine analysis. Python helps with readable logic but obscures how it's actually implemented (attacker's focus). A similar project in Go might be a better idea as it's easier to see what assembler comes out of it and Go is often the replacement for Python in server apps.
Regardless, the main worry areas are parsing, protocol handling, formats, and limiting effects of any given external action on system's state. Making sure those are correct should knock out most issues. Not that it will be simple or easy. ;)
I was first banned back in 2010 a few days before the payout date. After that I made numerous attempts at getting the account reopened, via their support forms. Then in the fall of 2013, it was reopened, after yet another support "ticket". I didn't start using it again immediately as I had to prepare my sites to at least partially go back to Adsense, after years of using other services. Guess what? A month after I was back on Adsense, the account was shut down again, without warning, and my money was gone.
I would not be surprised if yesterday's "leak" is indeed true.
Edit: I should add that I had been using Adsense since ~2006, when I was first banned. No big changes had been made to my website (one at the time), in the time before the ban. I never got an explanation other than the standard "illegal activity" message everyone seem to get.
All it takes is someone who has 5 minutes to lose to writes a shitty bash script that will curl your ads in an infinite loop. That may be the 'illegal activity' reported.
As for the bans occuring a few day before payout, I'd be prone to think that the automated checks for such activity are not run in real time, but at a scheduled time close to a payout. That would explain why so much bans happens before payout (well, excluding malice from google)
Thanks for that; I had ignored the Adobe leak, because why would I have created an Adobe account? Turns out I did at some point, so I guess I'm the goat there.
Often you need to create an account or somehow register your email at sites, just to get something very basic, like a free download, or use a feedback form.
I entered my address out of curiosity and it told me I had an Adobe account. I can't remember ever creating one so I tried the password reset process. Adobe tells me there doesn't exist an account under that address.
How is this possible? How did Adobe leak my address if I don't even have an account?
This actually makes me less willing to contribute. The worst outcome here is that they hit 15% of their funding goal and get stuck there, which means that there's enough money to do some work and to raise expectations of results from the funders, but not enough to produce a commercial (or near-commercial) quality game at the end of it.
With a Kickstarter all-or-nothing approach I can be quite generous (I'd probably go for the $100+ option here), safe in the knowledge that if nobody else offers any funding then I won't be the only one chipping in.
